Re: Packet rate limiting

On Mon, Jul 14, 2003 at 11:24:42PM +0200, alessandro salvatori wrote:
> yes, it works even with packets bigger than the buffer ;)
> i inserted a 1048 bytes payload into the ECHO REQUEST

[snip]

Cool. Although I'm still not convinced this helps or makes libnet_write() send packets more "accurately". I ran my own tests which I repeated 5 times each:

Send 100,000 packets w/ 1400byte payload w/ 1024 buffer Send 100,000 packets w/ 1400byte payload w/ 32K (default) buffer

Both cases used the following loop:

   for (i = 0; i < 100000 ; i++) {

	c = libnet_write(l);
	if (c == -1)
	    {
		fprintf(stderr, "Write error: %s\n", libnet_geterror(l));
		goto bad;
	    }
	

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

    }

and were compiled thusly:

gcc -DHAVE_CONFIG_H -I. -I../include -O2 -Wall -o smurftest smurftest.c ../src/libnet.a

Interestingly, using the smaller buffer resulted in a .20 to .40 second INCREASE in run time and CPU utilization went from 2-4% to 8-9%. Other then that, I couldn't detect any real differences.

I also ran some other tests using a 64K buffer (no real difference to a 32K buff) as well as small packets (44 bytes of data). Buffer size seemed to have no difference w/ small packets. However, performance was over 2x w/ 100bytes of data between 1024 and 64K buffers.

Interestingly, I never got an error complaining the send buffers being full like I'm accustomed to w/ tcpreplay, though perhaps that's the difference between a 2Ghz P4 and 450Mhz P3 :).

So, the real question is, does this prove anything? No not really. These "tests" are hardly scientific, but they do illustrate something that that I feel is intuitive: buffers make things run faster. And if you're trying to be "accurate" faster is often better. At least in the case of tcpreplay, the less time I'm waiting around for things to happen, the sooner I can calcualate the amount of time I should nanosleep() for the next packet to be sent. If things take too long, then I might find myself in the case of "shit, I should of already sent the packet!" which means I'm playing catch up which is never good.

Unless you're running a RTOS or a have a schedular which you have a lot of control over, the best any app can do is give the kernel the packet at the "correct time" and hope and pray that the kernel deals with it in a reasonable fasion. Hence your goal should be to make your send loop as tight as possible so that you never fall behind. That or upgrade your P3 450Mhz to a 2Ghz P4. :)

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Personally though, I'm not convinced that the libnet_write() or the underlying socket write is blocking in either case. I'm with Matt in saying I can't find any documentation, code, or comment which indicates that this might ever occur. If you know of some, I'd love to read it.  

> I think i should make some more tests with the link layer interface...
> to know what is the minimum amount the Linux kernel allows... (Linux
> is so different from all the other implementation of BSD sockets...)

Just look in /usr/src/linux/net/core/sock.h

It also explains why things seem to be 2x what they should.

-Aaron