Re: Packet rate limiting

OK since I just suffered through the RTOS issue, let me explain:

Lets say I want to send 100K per second.

That's 102400 bytes in a second.

Now, I can't send less than 64 bytes at a time, according to the Ethernet spec. So, that's 1600 bytes per second.

That's a 0.625ms delay in between each packet I wish to send.

Linux has a 10hz clock. That means, every time I usleep, I ain't coming back for 100ms.

So, if I try to sleep 625 microseconds, the kernel is going to go off, do some other things, and come back approximately really f*cking late.

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

Now, there are alternatives. I could use another Unix (freebsd and solaris wipe the floor with linux when it comes to scanrand 1.1). I could use nanosleep, which throws the processor in a busy loop so I get my precise, non-context-switching sleep. Or I could switch to a RTOS, which lets me say, "You do what you want, but in 625 microseconds, you WILL SEND THIS PACKET." That's what an RTOS gets you -- a guarantee that a specifically scheduled event _will be executed in time_.

Not to say a RTOS is necessary. Just shifting the delay mechanism to a batch architecture -- with large delays between large byte drops (which is what you're doing no matter what, because 64 byte packets are atomic)
-- works well enough.

--Dan

P.S. I might be a bit off on the numbers -- but scanrand 1.1 bandwidth limiting remains quite broken for the reasons described.