[lkml]   [2001]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectdropping UDP packets on send
I'm trying to get some rough figures for the sort of performance
I could expect from a load-balancing application whose job would
be to re-direct incomming UDP packets to a set of target systems
(and handle fail-over etc).

To test this I wrote a very simple application that sends UDP packets
out as fast as possible, one which reads them as fast as possible but
does noting except the copy to user space and one which distributes
them reading a packet then sending it on to a destination, doing a round-
robin allocation of destinations.

The sender is as follows

memset(buf, '\0', blocksize);
while (--count >= 0) {
*(unsigned short *)buf = ++seq;
*(unsigned short *)(buf+2) = (unsigned short)lrand48();

if ((r = write(sock, buf, blocksize)) != blocksize)

blocksize is 64

Up to about 1-2,000,000 packets I get about 100,000 packets per second
sent, the reader can keep up, the fowarding application can't - it tops
out at 34,000 packets per second or so (but it's simplistic as I only
want approximate figures - I can think of a couple of ways to improve

If I try to send more than 2,000,000 packets something odd happens
the sender competes faster than expected but it doesn't send all of
the packets as seen by looking at the TX packet count. I don't see
any write failures (i.e write always returns 64 and write_errs is
always zero after the run).

Is this "expected" behaviour or is there a problem?

sender/distributer are running 2.4.1-pre7 on dual-processor PIII 866s
with 1G of PC-133 SDRAM and 3c905b/c ethernet cards (sender has
the "b" but if I swap over and send using the "c" I get the same result).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.036 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site