Hello all,

I am starting to learn signal handling in Linux and have been trying out some simple codes to deal with SIGALRM. The code shown below sets a timer to count down. When the timer is finished a SIGALRM is produced. The handler for the signal just increments a variable called count. This is repeated until the user hits ‘q’ in the keyboard. The code is shown below:

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

void my_action(int);

int count = 0;

int main(int argc, char** argv)
{
struct sigaction sigalrm_action;
struct itimerval timer;

timer.it_interval.tv_sec = 0; //Deal only in usec
timer.it_interval.tv_usec = 1000;
timer.it_value.tv_sec = 0; //Deal only in usec
timer.it_value.tv_usec = 1000;

sigalrm_action.sa_handler = my_action;
sigemptyset(&sigalrm_action.sa_mask);
sigalrm_action.sa_flags = 0;

sigaction(SIGALRM, &sigalrm_action, 0);

printf("Hit any key to start, q to exit\n");
getchar();

if(setitimer(ITIMER_REAL, &timer,NULL) != 0){
perror("Error starting timer");
exit(1);
}
while(getchar()!= 'q');
printf("Bye bye\n");
return 0;
}

void my_action(int signum)
{
count++;
printf("Count is %d\n", count);
}
----------------------------------------------------------

The problem I am facing is this, when I set the timer for 1000000usec it works fine (i.e 1sec). However if I keep reducing the usec time to 100000, 10000, 1000 etc the timing seems to be too slow. The count variable is not being incremented as fast as it should be. Why is this? I have a hunch I am doing some silly mistake here but I am not sure what it is.

Any help would be greatly appreciated.

Read the manual for 'setitimer'. From the manual:

"Timers will never expire before the requested time, but may expire some (short) time afterwards, which depends on the system timer resolution and on the system load."

There is still more useful information in the man page, but why quote the whole man page.

What i gather from the man pages is that any time function (sleep(), usleep(), settimer etc) will never expire precisely at the specified point, it will expire slightly afterwards.

I ran some test code using usleep and found some interesting results.
When i put usleep to 0.1secs, the actual sleeping time varies from the set point (0.1secs) with an error of about +5%. The same error percentage jumps to about +40% when i put usleep to 0.01sec and the same error jumps to about +300%(!!!!) when i put usleep to 0.001sec.

Looks like as the timer resolution is brought down the error keeps increasing. Could be due to system timer resolution as mentioned. This could explain why settimer was behaving strangely for low values of time.

or perhaps there is some other reason??????????

Yep, "system timer resolution" is what you need to check. Also remember other progs are running, so can affect the elapsed or 'wallclock' resolution observed .

"or perhaps there is some other reason"

Of course there is another reason.

The kernel's timer is updated via an interrupt and perhaps a 'tasklet' is set to send signals to processes waiting for SIGALM. Alternatively, the tasklets are set when the scheduler is running - I don't know what the case is and I don't want to look at the source.

The scheduler is also run at regular intervals via an interrupt - this rate may vary from 100 times per second to 1000 times per second on a typical x86 kernel. It is the job of the scheduler to deliver interrupts to processes (since the processes need to respond to the interrupt within a process context). So even if the internal timer had very good resolution (like 1ns resolution), two remaining issues are: how often is the timer updated and how often is the scheduler invoked. There's the other catch - your timer can have nanosecond resolution (make it picosecond even, if you wish) but if it is only updated every 0.01s then the resolution is rather pointless. In addition to all this, the scheduler may delay the execution of your process, which means it won't see the signal until the scheduler runs it again - whenever that may be. You can see the effect of scheduling delays by running a dummy program with high priority and then running your SIGALM program with fairly low priority. This is the "and CPU load" delay mentioned in the man pages.