with 2.6.7 setitimer called in sequence returns strange values on i686

Hello!

Sorry if I'm taking your time away but to me it looks like I have kernel problem, so I hoped to find some help in this list. I'm not subscribed so please CC me on replies.

I'm using setitimer(ITIMER_REAL...) to measure time intervals. Everything was working fine untill I've installed 2.6.7 kernel.

bash$ uname -a
Linux avorop 2.6.7 #5 Thu Aug 19 11:53:33 CEST 2004 i686 unknown

Here's little piece of code that reproduces problem on my machine.

===========================================
#include <pthread.h>
#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>
#include <errno.h>
#include <error.h>
#include <time.h>

void
set_timer(int arg)

{
    struct itimerval n, o;
    struct timespec per;

    n.it_interval.tv_sec = 0;
    n.it_interval.tv_usec = 0;
    n.it_value.tv_sec = arg;
    n.it_value.tv_usec = 0;
    // init timer
    if(setitimer(ITIMER_REAL, &n, &o) != 0) 
       error(EXIT_FAILURE, errno, "Can't set timer");
    printf("Previous value of %d timer is %ld.%ld\n", arg, 
            o.it_value.tv_sec, o.it_value.tv_usec);
    per.tv_sec = arg / 2;
    per.tv_nsec = 0;
    // sleep for half a timer time
    nanosleep(&per, NULL);
    n.it_value.tv_sec = arg;
    n.it_value.tv_usec = 0;
    // check how much time is left and restart it at the same time
    if(setitimer(ITIMER_REAL, &n, &o) != 0) 
       error(EXIT_FAILURE, errno, "Can't set timer");
    printf("Previous value of %d timer is %ld.%ld\n", arg, 
             o.it_value.tv_sec, o.it_value.tv_usec);
    n.it_value.tv_sec = 0;
    n.it_value.tv_usec = 0;
    // check how much time is left. 
    if(setitimer(ITIMER_REAL, &n, &o) != 0) 
        error(EXIT_FAILURE, errno, "Can't set timer");
    printf("Previous value of %d timer is %ld.%ld\n", arg, 
        o.it_value.tv_sec, o.it_value.tv_usec);
}

int
main(void)

{
    pthread_t thr1, thr2;

    pthread_create(&thr1, NULL, (void*)set_timer, (void*)10);

// pthread_create(&thr2, NULL, (void*)set_timer, (void*)12);

    pthread_join(thr1, NULL);
    pthread_join(thr2, NULL);
    return 0;
}

======================================================
On my machine this program produces

Previous value of 10 timer is 0.0
Previous value of 10 timer is 4.999240
Previous value of 10 timer is 10.479

Note the last line. I've reset timer to 10 seconds and setitimer tells me that there are 10.479 seconds left.

As I said this code works fine with 2.4.21 kernel. It produces Previous value of 10 timer is 0.0
Previous value of 10 timer is 4.980000
Previous value of 10 timer is 10.0

I have one more machine with 2.6.7 kernel. But that machine is Athlon64 and runs 64-bit kernel. There the program also runs correctly.

Any hints on where to look for the problem?

TIA.

Andrei

Hello Andrei,

There's a little problem with your code. You're not displaying microseconds correctly. That "10.479" below should really be "10.000479". I suspect that that sort of small rounding error (smaller than HZ) is probably acceptable, but someone else might have some input on this point.

Cheers,

Michael

PS The use of pthreads in this program has no relevance to the behaviour you are seeing -- I removed the pthread stuff and saw the same results.

NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail

Yep. You are right. I just had some old testing program that I used with 2.4.21 and there I wanted to make sure that things work in pthread. So I just reused it without removing pthread stuff.

This "small rounding error" crashes my application pretty nice. Because my application assumes that when I call setitimer second time, then the timer will be either the same or smaller, not bigger. And definetely no man page mentions this sudden growth. Quite opposit, man page says that the value is decremented.

At least now I know that it's reproduceble on other machines.

Andrei

On Tue, Aug 24, 2004 at 04:42:41PM +0200, Andrei Voropaev wrote:
[...]

[...]

I'm not sure if it is of particular importance. After checking the sources it appears that the problem lies with mathematic. New math makes sure than during conversion of timeval to jiffies bigger number of jiffies is allocated to force the requirement that timer expires not earlier than requested. But during conversion from jiffies back to timeval no reverse adjustment is done, so resulting timeval can be more than original. From my standpoint this violates the requirement that the timer is only decremented (thus reduces its value) and not incremented.

That is why I believe that the following patch would be correct.

@@ -239,7 +239,7 @@
         * Convert jiffies to nanoseconds and separate with
         * one divide.
         */
-       u64 nsec = (u64)jiffies * TICK_NSEC; 
+       u64 nsec = (u64)jiffies * TICK_NSEC - (TICK_NSEC / 2); 
        value->tv_sec = div_long_long_rem(nsec, NSEC_PER_SEC, &value->tv_nsec);
 }
 

Well, this might be minor issue since normally nobody should call getitimer immidiately after setitimer, but still...

The above is not true. The problem appears on 64-bit kernel as well. Just for different numbers :)

Andrei