Thanks, your data is very interesting.
Do you have any plans to do measurements on a box that is dedicated for
sniffing?
that does not also run the traffic generator?
Testing sustained disk sequential write throughput
say using dd from /dev/zero to ???
Im thinking of a test using a good disk subsystem (4 or 8 disk striped)
which is dedicated to store
the capture, only. OS tools and apps sitting on a separate dedicated disk.
the tool shoulkd run in a shell where memlock(all|future) is set so we will
never have the app or its data
put in swapspace.
doing sequential writes through either ext2/ext3/reiserfs or to the raw
disk.
Tuning the BIO scheduler for extreme sequential write throughput and which
i/o scheduler is fastest.
Testing with or with out high-memory enabled.
And just get a number for a certain cpu config and disksystem.
documenting throughput number and cpu utilization.
testing tcpdump capturing speed to the optimized disk system:
using a good gbe card in a dedicated pci slot.
using the zerocopy libpcap patch for linux.
removeing all services from the linux box so that tcpdump is essentially the
only app running.
measuring the highest capture speed you can generate
measuring the amount of data captured to disk per second in sustained
captures.
measuring the cpu utilization when doing so.
this would be a great whitepaper.
i belive very few people know that it should be possible with a fine tuned
linux system to do captures
of saturated gbe links. Sustained captures to disk, not to memory.
It would be very nice if we had a real whitepaper that shoved these kind of
numbers since it would
stop certain other vendors from spreading fud about capturing speed.
From: Alistair.McGlinchy
Sent: Friday, July 11, 2003 3:49 AM
Subject: RE: [Ethereal-users] Throughput with Gigabit Ethernet
> Martin,
>
> The answer is (of course).... it depends. Here's what I've found from my
> testing.
>
> 1) Getting more than 40Mbit/s over any medium with NT/Win2K/XP with
> negligible packet loss is impossible. I'm not sure what the limitation is
> but it can't be libpcap as Windump is better than tethereal at this .
Here's
> an example tracing the same UDP stream with WinDump and tethereal.
>
> d:\>WinDump -n -s 0 -i
\Device\NPF_{C0BD2FFE-AB2B-4F7E-B9A7-25B6B232EA29} -B
> 10000 -w test.cap
> WinDump: listening on \Device\NPF_{C0BD2FFE-AB2B-4F7E-B9A7-25B6B232EA29}
>
> 1435240 packets received by filter
> 0 packets dropped by kernel
>
> d:\>tethereal -i
\Device\NPF_{C0BD2FFE-AB2B-4F7E-B9A7-25B6B232EA29} -n -q -w
> test.cap
> Capturing on \Device\NPF_{C0BD2FFE-AB2B-4F7E-B9A7-25B6B232EA29}
> 416784 packets dropped
> 159952 packets captured
>
> 2) I have captured more than 2.4 Gbit/s over the loopback address on
Linux.
> I needed to write to a RAMdisk to achieve this but it worked fine until
the
> 2GB RAM disk filled up. [Then things went very bad :-)]
>
> 3) I have captured at 250Mbit/s for 3 minutes over Gbit, but this was
> limited by the CPU of the capturing box which was also running the
> application generating the traffic.
>
> Hence I believe (but have not tested) that ethereal will, on Linux, with
the
> right CPU and fast enough disk, capture at wire speed 1Gbit/s.
>
> YMMV on Windows
>
> Alistair
>