usleep() function

Hi,

I was writing/upgrading a network program that sends a synflood ( Series of TCP SYN packets). This is being used for the testing. Now I send a series of SYN packets without any delay from a linux machine. It sends it at approx 14-150000 packets per seconds. This I have implemented using setitimer() by setting alarm for 1 sec and counted the total packets sent for the whole time, till i hit Control+C to stop it, where I used SIGINT and a interrupt handler to avg them out.

Now my question is when I add a user configurable delay between 2 successive sendto() calls using usleep(),the rate drops to 50 packets per seconds. Well I am not sure if this is right. How can a delay of microseconds, drop the rate so much.? Morover whatever delay I provide, rate remains the same 50 pps.

Here is snippet of this code where I call usleep().

Code:

---

send_syn(so, pPkt, sip, sport, dip, dport, pktid, seq);
pktcount++;
if((lmt != 0) && (pktcount == lmt)) goto done;
signal(SIGINT,exit_handler);
if(usl) {usleep(usl);} /* If delay is provided in command, add delay */

---

Can someone clarify this for me ?

Thanks,

All sleep functions are a MINIMUM guarantee, not an absolute request.
usleep(1); which returns a day later would meet it's requirements, the rest is down to the vagaries of whatever else your OS is up to, and the granularity of the scheduler.

Quote:

---

Originally Posted by Salem

All sleep functions are a MINIMUM guarantee, not an absolute request.
usleep(1); which returns a day later would meet it's requirements, the rest is down to the vagaries of whatever else your OS is up to, and the granularity of the scheduler.

---

My OS is Linux with gcc complier. Do you have/know any code samples that shows how to add delay on Linux platforms.

Thanks,

As Salem said, sleep functions are a minimum guarantee. The reason for it being such a dramatic delay compared to your expected 1 microsecond is because a sleep function is a signal to the kernel that it can context switch to another process. So, no matter what argument to usleep, you'll trigger a context switch to another process that is waiting to run.

For more information on accurate, short delays under Linux, see http://www.linux.com/howtos/IO-Port-Programming-4.shtml

If the delay length is critical, you might want to consider "real time linux" at http://www.fsmlabs.com/

Quote:

---

Originally Posted by cwr

As Salem said, sleep functions are a minimum guarantee. The reason for it being such a dramatic delay compared to your expected 1 microsecond is because a sleep function is a signal to the kernel that it can context switch to another process. So, no matter what argument to usleep, you'll trigger a context switch to another process that is waiting to run.

For more information on accurate, short delays under Linux, see http://www.linux.com/howtos/IO-Port-Programming-4.shtml

If the delay length is critical, you might want to consider "real time linux" at http://www.fsmlabs.com/

---

Thanks for your reply. I read the link. Is it possible to find out the CPU frequency at runtime using any API ?

Thanks,

Under Linux, you could take the cpu MHz line from /proc/cpuinfo, but what does knowing the CPU frequency buy you? Not much.

Why don't you use the nanosleep function in combination with sched_setscheduler() as the article says?