[Guy Harris <gharris@xxxxxxxxx>]

On Fri, Mar 14, 2003 at 02:46:13AM -0500, Ian Schorr wrote:
> "tethereal --version" still reports using 0.6 after installing the 
> latest cvs libpcap, and I did't know how to update this

You need to rebuild Ethereal to link it with the installed libpcap -
the version you have was probably linked either statically or
dynamically with the version that came with your OS, and tcpdump.org's
libpcap doesn't install a new dynamic library, so even if Ethereal (and
Tethereal) is dynamically linked, it still wouldn't get the new version.

> - I'm bottlenecking on my disk when doing to-disk writes since it looks 
> like my disk controller driver is putting all my drives in PIO modes, so 
> I was dropping a lot during my save-to-disk tests at least partly for 
> this reason

I *think* there might be some kernel option (probably some boot-time
option for the IDE driver) to enable DMA mode (unless I'm thinking of
FreeBSD there).

> - While running "tcpdump -s 9000 -w /dev/null" I was able to 
> receive/process packets at no more than about a 1-2% drop rate until I 
> threw about 80MB/s (80,000 1000byte frames) at the system and the CPU 
> started maxing out.

Using the memory-mapped "turbopacket" mechanism in the 2.4[.x] kernel
might help, by avoiding copies.  There's a patched libpcap to use that
here:

	http://public.lanl.gov/cpw/

I think you have to set an environment variable to enable it; as I
remember, Phil Wood (the guy who did the patches) said that
memory-mapped capture streams don't work across forks the way some
applications would expect capture streams to work, so you can't just
unconditionally enable it.  (At some point I want to add a new API to
libpcap, which will take some additional flag bits, one of which would
be a "I expect this to work across forks" flag; if that flag is *not*
set, it'd use the turbopacket mechanism on Linux, otherwise it wouldn't.)

> - Similarly, with tethereal it appeared that I was seeing the same drop 
> rates while capturing data flowing at up to 40MB/s (again, sending to 
> /dev/null).

Were you using the "-q" flag to tcpdump?  If not, try that - it might be
that the captured packet count updates are slowing things down.

> - However, when I enabled ring-buffer capture (at anywhere between 2-10 
> files), drop rates skyrocketed to 30-70%, at rates anywhere between 
> 1MB/s-12MB/s (1000-12,000 frames per second).  This was true even when 
> waiting at least 30 seconds after starting capture to begin generating 
> traffic, and even if the total amount of traffic would be saved in only 
> one file.

"Would be saved in only one file" meaning that you have a really large
maximum file size?

> - I also noticed that specifying -a filesize:5000000 (without ring 
> buffer mode) seems to cause tethereal to stop capturing after 700M data 
> has been received.  This doesn't happen if I set filesize to 1000000 or 
> 2000000.  This is yet another quirk that probably confused my testing 
> yesterday.  Perhaps a bug?

Yup, it's probably a bug.

> - Ethereal (GUI) capture rates are fairly bad regardless of whether I'm 
> writing packets to a file or to RAM - I tend to lose at least 20% even 
> at reasonably low rates (10MB/s),

Ethereal's updating the display and checking for input from the user,
which consumes extra CPU time (even if there's no input).

> The problem that's worrying me at the moment is the ring buffer issue - 
> I suppose my disk speed limits may be making the problem worse, but the 
> drop rate seems unreasonably high considering the load.  It's similar to 
> a problem I had with ring buffer in Windows - I found that while I could 
> write files in ring buffer at rates of up to about 45MB/s (and 
> potentially more - I haven't tested higher rates) with drop rates of 
> 0.005%-0.1%, but once I started wrapping files, drop rates jumped to 
> about 50%.

How often was it wrapping files?  Wrapping files involves a fair bit of
file system work, which consumes CPU time and disk bandwidth, so if it's
doing it a lot (i.e., small file sizes), that could increase the drop
rates.

However, there might be some problem with the ring buffer code as well.