On Tue, Feb 11, 2003 at 03:40:04PM +1100, Shaun wrote: > That's the bit that bothers me, on a decent system I could easily motor > through processing gobs of data in a second, it's the syscall and sleep > overhead that will kill me.
Are you certain that the system call and sleep overhead will *definitely* make it impossible? If so, then, unless you can coax AIX into giving you a bigger buffer, you might be out of luck. > > All that > > a bigger buffer does is reduce the amount of time spent doing wakeups > > and per-system-call overhead for reads, by letting you do fewer reads. > > And allow you to go off and do something else for a short time as long as > you come back reasonably soon and process quickly when you do. I.e., it leaves you more able to handle bursts and temporary slowdowns in processing - you obviously still have to be able to retire buffers at the same rate that they're supplied in the steady state. > Do the other libpcap platforms typically provide similarly limited buffer > space for packets? NetBSD, as noted, currently has a 32K limit. Other BSDs raised the limit; perhaps libpcap should try bigger limits, although I don't know whether using the 512K that current FreeBSD, for example, offers would be considered sufficiently anti-social that it shouldn't be the default. Linux and IRIX use sockets for capturing - I don't know how big you could make a socket buffer. Linux also gives you *one* packet per read; IRIX might do so as well. Recent Linux kernels support a memory-mapped buffer for capturing, but the standard libpcap doesn't yet support that. Solaris and HP/UX use DLPI (and AIX can be configured to do so); the "chunk size" on Solaris, which is the maximum amount of data you get per read, is limited to 64K, but I don't know what the stream head limit is, so I don't know how many chunks can be stored at the stream head. HP-UX and AIX's DLPIs do no chunking, so you get one packet per read; I don't know what they set the stream head limit to. I don't know offhand what the buffer size is for Windows or Digital UNIX. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
