Tuesday I performed some more performance testing with Ethereal.
I finally got various NICs working on my Redhat Linux test machine
(dual-booting Redhat 8 with kernel 2.4.18-14 and Redhat 7.3 with kernel
2.4.18-3), but I'm seeing capture performance much lower than I expect.
Using a gigabit packet generator, I've been generating various loads for
the box. I'm finding, however, that even at relatively low rates
(7MB/s), and for short times (send 150MB total), Ethereal/tethereal
either doesn't capture, or isn't passed 30% of the packets I send. At
higher rates (but still low), Ethereal only manages to capture 40% of
the packets on the wire. The adapter is seeing the packets, as netstat
-i counters are increasing by the exact number of frames that I send.
Let me describe my setup. The capture device is running dual Athlon XP
1800+ processors, 512MB DDR RAM, SysKonnect SK-9844 or SK-9843 64-bit,
66mhz GigEth NICs. I'm generating 1000byte frames only. I'm performing
no frame slicing, and have been capturing either with tethereal (and
writing directly to a disk file), or with Ethereal (and capturing to
RAM). I've tested a wide variety of settings, from high data rates
(45MB/s), low (7MB/s), "bursty", long tests (20 minutes and quite a few
gigabytes of data), and short ones (as low as 100MB of data sent).
CPU doesn't seem to be sweating at all during most of my tests (20% used
or below), and at no disk paging is occurring. I've also tried turning
SMP off, but I saw no noticable difference.
Tethereal is reporting only seeing a certain number of frames (again,
30-70% or so), and reports 0 dropped. I'm not 100% sure whether the
kernel is compiled to allow drop reporting, so I'm not sure what this
symptom is telling me.
Any suggestions on what might be happening here? I get MUCH better
rates in Windows with the exact same system configuration. I'm going to
try eliminating the cards/driver by using a NetGear GA620, and check
TCPDump to see if I get similar results, but otherwise I'm open to
suggestions on what to check/try...
Thanks,
Ian
