2

I am calculating time elapsed in milli seconds for each successive call to handler function using the code below. When i use usleep(1000) i.e. 1 ms time difference between each call is 10 ms and when i use usleep(1000000) i.e. 1 sec surprisingly time interval between each call falls down to less than 1 ms. Following is the code snippet :

    #include<stdio.h>
    #include<stdlib.h>
    #include<sys/time.h>
    #include<unistd.h>

    struct timeval start_time;
    void handler(int);

    int main()
    {
            struct timeval current_time;
            int i=0;
            gettimeofday(&start_time,0);
            gettimeofday(&current_time,0);
            printf("%012.3fms: emulationbegins\n",((current_time.tv_usec-start_time.tv_usec)/1000.0));

            while(i++<5)
            {
                    usleep(1000); // compare with usleep(1000000)
                    handler(i);
            }

            return 0;
    }

    void handler(int i)
    {
            printf("In Handler %d\n",i);
            struct timeval current_time;
            gettimeofday(&current_time,0);
            printf("%012.3fms: Handler Called\n",((current_time.tv_usec-start_time.tv_usec)/1000.0));
            return;
    }
vikas_2kx
  • 37
  • 6

2 Answers2

3

Remember that the tv_usec field of the timeval structure never goes to (or over) one million, instead the number of seconds is increased.

You have to use the tv_sec field as well in your calculation.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • Ya I missed that... Thanks !! – vikas_2kx Feb 13 '13 at 11:38
  • I have an additional related question. After rectifying mistake usleep(1000) and usleep(1000000) shows reasonable difference but usleep(1000) and usleep(5000) are almost same. Why ?? – vikas_2kx Feb 13 '13 at 11:49
  • @vikas_2kx The `usleep` function sleeps _at least_ the amount given, it may actually sleep for longer if the timer resolution is not high enough. – Some programmer dude Feb 13 '13 at 11:52
2

usleep is specified to sleep at least the amount you give it, but it can sleep much longer. There's almost no upper bound on how long it will sleep because the operating system doesn't have to run your process if it has more important processes to run.

In practice the resolution of how long usleep will sleep is decided by the clocks the operating system uses. Up until a few years ago most unix-like systems used a static 100Hz timer (or 1024Hz in some rarer cases) to drive timers like this, so your usleep would always get rounded up to the nearest 10ms.

There has been some work done recently on some systems to remove the static clock, although this hasn't been driven as much by the need for higher resolution sleeps, but rather by the fact that constantly waking up the cpu for a static clock tick is bad for power consumption. It can have a side effect of improving the timer resolution, but that in turn exposes bugs in applications that used very short sleeps and appeared to behave correctly. Suddenly with a higher resolution of timeouts in usleep/nanosleep/poll/select those short sleeps lead to applications spinning on the cpu rescheduling their sleeps all the time.

I'm not sure what the state of this is today, but from your 10ms it looks like your system still uses a 100Hz clock for its internal timers or that it deliberately slows down timeouts to a 10ms resolution to prevent applications from breaking.

Art
  • 19,807
  • 1
  • 34
  • 60