Initial performance data
Peter Van Epp
vanepp at sfu.ca
Wed Sep 27 19:05:46 EDT 2000
> >From your file I'm somewhat confused, as the timestamp problem
> is not what I thought. The records have wildly negative numbers
> in the source tv_sec and tv_usec fields, where I was thinking
> that it was the last time value that was wrong. My fix in
> argus-2.0.0j simply reverts back to the 1.8.1 strategy by
> having full timeval structs for both the start and last times.
>
> So the fix may not solve the problem after all. If it doesn't
> then I've got to worry about libpcap but I won't do that for a
> while still.
And indeed it doesn't appear to. I still see it in j:
27 Sep 00 15:04:56.708152 icmp 142.58.181.170 -> 142.58.241.202
2 0 72 0 URP
27 Sep 00 15:12:26.470146 tcp 142.58.245.31.1489 <?> 205.242.216.170.80
2 1 52 26 RST
31 Aug 45 05:13:36.982255616 unkn 0:30:65:7c:2f:4c <-> 8:0:86:15:eb:c7
12 218 552 10028 TIM
27 Sep 00 15:07:07.652428 tcp 142.58.232.82.2081 -> 209.167.51.241.80
6 6 1508 2388 FIN
27 Sep 00 15:07:07.704512 tcp 142.58.24.58.1288 -> 142.58.181.41.80
13 15 979 14433 FIN
>
> Performance numbers are very interesting. Did I understand that
> argus is not counting 12 packets at some point? Hmmmm, , ,.
Initially (looking at no more than the number of packets ra reported
seeing) that appears to be so. I have to process out the counts from the
sniffer by flow so I know the counts that ra should be reporting to see if
that is true in practice, but the sniffer and tcpdump both agree they saw
5002 packets on the wire and ra is reporting seeing less. This may be something
tripping a response from the FreeBSD stack back on to the wire that ra didn't
see. Signal handling seems to have improved, though I haven't yet seen any
more instances where one thread stops and the other two continue.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
More information about the argus
mailing list