Re: Fw: missed itimer signals in 2.6

Re: Fw: missed itimer signals in 2.6

[George Anzinger]

[-- Attachment #1: Type: text/plain, Size: 6911 bytes --]

Here is a modified test.  (If you look at the code, please pay 
attention to the variable g_resolution.)  By setting the itimer twice, 
the second time with an address for what it was, we get the actual 
value used by the kernel for the interval time.  We now print this 
value and use it to modify the expected number of ticks (which we 
print after the old value with the label real).  Here is what I see:

[george@zap bug]$ ./itimertest
resolution: asked for 10000us, got 10998us
i=10, ticks=455 (expected 500 ,real 454), elapsed=5.004475, 
drift=-0.000365
resolution: asked for 20000us, got 20996us
i=20, ticks=239 (expected 250 ,real 238), elapsed=5.019538, 
drift=-0.001491
resolution: asked for 30000us, got 30995us
i=30, ticks=162 (expected 166 ,real 161), elapsed=5.021564, 
drift=-0.000369
resolution: asked for 40000us, got 40993us
i=40, ticks=122 (expected 125 ,real 121), elapsed=5.002560, 
drift=-0.001409
resolution: asked for 50000us, got 50992us
i=50, ticks=99 (expected 100 ,real 98), elapsed=5.048553, drift=-0.000341
[george@zap bug]$ uname -a
Linux zap.mvista.com 2.6.0-test5 #22 SMP Thu Sep 18 14:27:08 PDT 2003 
i686 unknown

Since the actual interval used by the system is a bit larger than what 
was asked for, there will be fewer ticks.

Maybe you could save this code if it is part of a test suite....

george

ps. Comments on my machine/directory name are...:)

Andrew Morton wrote:
> You saw this?
> 
> Begin forwarded message:
> 
> Date: Mon, 13 Oct 2003 14:46:49 -0700
> From: Tom Marshall <tmarshall@real.com>
> To: linux-kernel@vger.kernel.org
> Subject: missed itimer signals in 2.6
> 
> 
> It seems that with the 2.6 kernel, ITIMER_REAL becomes inaccurate when the
> interval is set under about 50ms.  Using a 10ms interval, I get 455 signals
> in five seconds (about 9% loss).  The test machine has virtually no load and
> this is reproducible across machines of varying speeds.  The test
> application is attached.
> 
> Typical output under 2.4.22:
> 
>   i=10, ticks=501 (expected 500), elapsed=5.008537, drift=+0.001468
>   i=20, ticks=251 (expected 250), elapsed=5.019925, drift=+0.000076
>   i=30, ticks=167 (expected 166), elapsed=5.009974, drift=+0.000027
>   i=40, ticks=126 (expected 125), elapsed=5.039981, drift=+0.000020
>   i=50, ticks=101 (expected 100), elapsed=5.049980, drift=+0.000021
> 
> Typical output under 2.6.0-test7:
> 
>   i=10, ticks=455 (expected 500), elapsed=5.003323, drift=-0.453316
>   i=20, ticks=239 (expected 250), elapsed=5.018035, drift=-0.238033
>   i=30, ticks=162 (expected 166), elapsed=5.021115, drift=-0.161113
>   i=40, ticks=122 (expected 125), elapsed=5.001113, drift=-0.121111
>   i=50, ticks=99 (expected 100), elapsed=5.048102, drift=-0.098101
> 
> 
> 
> ------------------------------------------------------------------------
> 
> It seems that with the 2.6 kernel, ITIMER_REAL becomes inaccurate when the
> interval is set under about 50ms.  Using a 10ms interval, I get 455 signals
> in five seconds (about 9% loss).  The test machine has virtually no load and
> this is reproducible across machines of varying speeds.  The test
> application is attached.
> 
> Typical output under 2.4.22:
> 
>   i=10, ticks=501 (expected 500), elapsed=5.008537, drift=+0.001468
>   i=20, ticks=251 (expected 250), elapsed=5.019925, drift=+0.000076
>   i=30, ticks=167 (expected 166), elapsed=5.009974, drift=+0.000027
>   i=40, ticks=126 (expected 125), elapsed=5.039981, drift=+0.000020
>   i=50, ticks=101 (expected 100), elapsed=5.049980, drift=+0.000021
> 
> Typical output under 2.6.0-test7:
> 
>   i=10, ticks=455 (expected 500), elapsed=5.003323, drift=-0.453316
>   i=20, ticks=239 (expected 250), elapsed=5.018035, drift=-0.238033
>   i=30, ticks=162 (expected 166), elapsed=5.021115, drift=-0.161113
>   i=40, ticks=122 (expected 125), elapsed=5.001113, drift=-0.121111
>   i=50, ticks=99 (expected 100), elapsed=5.048102, drift=-0.098101
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /*
>  * test itimer
>  */
> 
> #include <stdlib.h>
> #include <stdio.h>
> 
> #include <unistd.h>
> #include <signal.h>
> #include <sys/time.h>
> #include <time.h>
> 
> #define TEST_INTERVAL_SEC 5
> 
> static inline void
> tv_sub(struct timeval* ptv1, struct timeval* ptv2)
> {
>     ptv1->tv_sec  -= ptv2->tv_sec;
>     ptv1->tv_usec -= ptv2->tv_usec;
>     while (ptv1->tv_usec < 0)
>     {
>         ptv1->tv_sec--;
>         ptv1->tv_usec += 1000*1000;
>     }
> }
> 
> static uint             g_ticks;
> static uint             g_interval;
> static struct timeval   g_now;
> 
> void
> itimer_handler(int sig)
> {
>     g_ticks++;
>     g_now.tv_usec += g_interval*1000;
>     while (g_now.tv_usec > 1000*1000)
>     {
>         g_now.tv_usec -= 1000*1000;
>         g_now.tv_sec++;
>     }
> }
> 
> void
> start_itimer(uint ms)
> {
>     struct timeval tv;
>     struct itimerval val;
> 
>     tv.tv_sec = ms/1000;
>     tv.tv_usec = (ms%1000)*1000;
> 
>     val.it_interval = tv;
>     val.it_value = tv;
> 
>     signal(SIGALRM, itimer_handler);
>     g_ticks = 0;
>     g_interval = ms;
>     gettimeofday(&g_now, NULL);
>     setitimer(ITIMER_REAL, &val, NULL);
> }
> 
> void
> stop_itimer(void)
> {
>     struct timeval tv;
>     struct itimerval val;
> 
>     tv.tv_sec = tv.tv_usec = 0;
>     val.it_interval = tv;
>     val.it_value = tv;
> 
>     setitimer(ITIMER_REAL, &val, NULL);
>     signal(SIGALRM, SIG_DFL);
> }
> 
> int
> main(void)
> {
>     int i;
>     struct timeval tv_start;
>     struct timeval tv_now;
> 
>     char drift_sign;
>     struct timeval tv_drift;
>     struct timeval tv_elapsed;
> 
>     for (i = 10; i <= 50; i += 10)
>     {
>         gettimeofday(&tv_start, NULL);
>         start_itimer(i);
>         do
>         {
>             usleep(1000*1000);
>             gettimeofday(&tv_now, NULL);
>             tv_elapsed = tv_now;
>             tv_sub(&tv_elapsed, &tv_start);
>         } while (tv_elapsed.tv_sec < TEST_INTERVAL_SEC);
>         stop_itimer();
> 
>         if (g_now.tv_sec > tv_now.tv_sec ||
>             (g_now.tv_sec == tv_now.tv_sec &&
>              g_now.tv_usec > tv_now.tv_usec))
>         {
>             drift_sign = '+';
>             tv_drift = g_now;
>             tv_sub(&tv_drift, &tv_now);
>         }
>         else
>         {
>             drift_sign='-';
>             tv_drift = tv_now;
>             tv_sub(&tv_drift, &g_now);
>         }
>         printf("i=%d, ticks=%u (expected %u), elapsed=%ld.%06ld, drift=%c%ld.%06ld\n",
>                 i, g_ticks, (TEST_INTERVAL_SEC*1000/i),
>                 tv_elapsed.tv_sec, tv_elapsed.tv_usec,
>                 drift_sign, tv_drift.tv_sec, tv_drift.tv_usec);
>     }
>     return 0;
> }
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

[-- Attachment #2: itimertest.c --]
[-- Type: text/plain, Size: 2819 bytes --]

/*
 * test itimer
 */

#include <stdlib.h>
#include <stdio.h>

#include <unistd.h>
#include <signal.h>
#include <sys/time.h>
#include <time.h>

#define TEST_INTERVAL_SEC 5

static inline void
tv_sub(struct timeval* ptv1, struct timeval* ptv2)
{
    ptv1->tv_sec  -= ptv2->tv_sec;
    ptv1->tv_usec -= ptv2->tv_usec;
    while (ptv1->tv_usec < 0)
    {
        ptv1->tv_sec--;
        ptv1->tv_usec += 1000*1000;
    }
}

static uint             g_ticks;
static uint             g_interval;
static struct timeval   g_now;
static struct itimerval g_resolution;

void
itimer_handler(int sig)
{
    g_ticks++;
    // g_now.tv_usec += g_interval*1000;
    g_now.tv_usec += g_resolution.it_interval.tv_usec;
    while (g_now.tv_usec > 1000*1000)
    {
        g_now.tv_usec -= 1000*1000;
        g_now.tv_sec++;
    }
}

void
start_itimer(uint ms)
{
    struct timeval tv;
    struct itimerval val;

    tv.tv_sec = ms/1000;
    tv.tv_usec = (ms%1000)*1000;

    val.it_interval = tv;
    val.it_value = tv;

    signal(SIGALRM, itimer_handler);
    g_ticks = 0;
    g_interval = ms;
    gettimeofday(&g_now, NULL);
    setitimer(ITIMER_REAL, &val, NULL);
    setitimer(ITIMER_REAL, &val, &g_resolution);
}

void
stop_itimer(void)
{
    struct timeval tv;
    struct itimerval val;

    tv.tv_sec = tv.tv_usec = 0;
    val.it_interval = tv;
    val.it_value = tv;

    setitimer(ITIMER_REAL, &val, NULL);
    signal(SIGALRM, SIG_DFL);
}

int
main(void)
{
    int i;
    struct timeval tv_start;
    struct timeval tv_now;

    char drift_sign;
    struct timeval tv_drift;
    struct timeval tv_elapsed;

    for (i = 10; i <= 50; i += 10)
    {
        gettimeofday(&tv_start, NULL);
        start_itimer(i);
	printf("resolution: asked for %dus, got %dus\n", i * 1000, 
	       (int)g_resolution.it_interval.tv_usec);
        do
        {
            usleep(1000*1000);
            gettimeofday(&tv_now, NULL);
            tv_elapsed = tv_now;
            tv_sub(&tv_elapsed, &tv_start);
        } while (tv_elapsed.tv_sec < TEST_INTERVAL_SEC);
        stop_itimer();

        if (g_now.tv_sec > tv_now.tv_sec ||
            (g_now.tv_sec == tv_now.tv_sec &&
             g_now.tv_usec > tv_now.tv_usec))
        {
            drift_sign = '+';
            tv_drift = g_now;
            tv_sub(&tv_drift, &tv_now);
        }
        else
        {
            drift_sign='-';
            tv_drift = tv_now;
            tv_sub(&tv_drift, &g_now);
        }
        printf("i=%d, ticks=%u (expected %u ,real %u), elapsed=%ld.%06ld, drift=%c%ld.%06ld\n",
	       i, g_ticks, (TEST_INTERVAL_SEC*1000/i),
	       (TEST_INTERVAL_SEC*1000*1000 / 
		(int)g_resolution.it_interval.tv_usec),
                tv_elapsed.tv_sec, tv_elapsed.tv_usec,
                drift_sign, tv_drift.tv_sec, tv_drift.tv_usec);
    }
    return 0;
}

Re: Fw: missed itimer signals in 2.6

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

> Since the actual interval used by the system is a bit larger than what 
> was asked for, there will be fewer ticks.

I understand what happens and why.  I admit that I'm not familiar with the
POSIX standard on this issue.  Questions:

 * I've heard that the kernel's timer resolution has increased from 10ms to
   1ms in 2.6.  Why does the itimer have such a large granularity?  I
   expected it to be highly accurate in this range.

 * Is this how the timer is supposed to work?  It seems to me that an
   algorithm which kept running track of the difference in requested and
   actual times (a la Bresenham) could make the itimer behave closer to what
   the user requested.

> Maybe you could save this code if it is part of a test suite....

This code is part of a "timer calibration" routine used by the RealNetworks
Helix Server.  I just noticed that the timer calibration failed on a machine
that had 2.6.0-test7 installed (we have not officially looked at supporting
2.6 yet).  The test runs on many different flavors of *nix (probably a dozen
or so).  I can check to see what the behavior is on the other platforms if
that would be useful.  If this is the Right Way to do timers, we'll probably
end up changing our "calibration" routine to read back the actual timer
interval as you suggest.

-- 
One good reason why computers can do more work than people is that they
never have to stop and answer the phone.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fw: missed itimer signals in 2.6

[George Anzinger]

Tom Marshall wrote:
>>Since the actual interval used by the system is a bit larger than what 
>>was asked for, there will be fewer ticks.
> 
> 
> I understand what happens and why.  I admit that I'm not familiar with the
> POSIX standard on this issue.  Questions:
> 
>  * I've heard that the kernel's timer resolution has increased from 10ms to
>    1ms in 2.6.  Why does the itimer have such a large granularity?  I
>    expected it to be highly accurate in this range.

I think it is.  The missing understanding is, I think, that you expect the 
resolution to be exactly 1/HZ or 1ms.  It is actually not exactly that because 
the PIC can not generate 1ms interrupts (close but not close enough for NTP). 
So the kernel figures out what the true PIC rate is and sets up the resolution 
for that.  This results in a resolution of ~999,849 nanoseconds (i.e. instead of 
1,000,000 nano seconds per tick).  Now there is some errors in converting this 
to micro seconds..., but the actual math is done with more precision with the 
conversion after (which is why the various times the program tries don't come 
out being exact multiples of each other, or of anything expressed as only 
microseconds).
> 
>  * Is this how the timer is supposed to work?  It seems to me that an
>    algorithm which kept running track of the difference in requested and
>    actual times (a la Bresenham) could make the itimer behave closer to what
>    the user requested.

I THINK you are suggesting that a different increment be used each timer expiry 
to get closer to the desired rate.  Sorry, not only is this a LOT more overhead, 
it is not the way the standard is written.  The standard says all these times 
are to be rounded up to the resolution, which is what the system does.  It is 
just that the resolution is not what you expect.

For what its worth, the POSIX clocks and timers (accessed through timer_settime, 
etc.) compute time to the nanosecond, so they will have less rounding error and 
will be a tad closer to the requested.  Still, we are dealing with an underlying 
ticker that only has 999,849 nanosecond resolution.

Hope this helps

George
> 
> 
>>Maybe you could save this code if it is part of a test suite....
> 
> 
> This code is part of a "timer calibration" routine used by the RealNetworks
> Helix Server.  I just noticed that the timer calibration failed on a machine
> that had 2.6.0-test7 installed (we have not officially looked at supporting
> 2.6 yet).  The test runs on many different flavors of *nix (probably a dozen
> or so).  I can check to see what the behavior is on the other platforms if
> that would be useful.  If this is the Right Way to do timers, we'll probably
> end up changing our "calibration" routine to read back the actual timer
> interval as you suggest.
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: Fw: missed itimer signals in 2.6

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

> >I understand what happens and why.  I admit that I'm not familiar with the
> >POSIX standard on this issue.  Questions:
> >
> > * I've heard that the kernel's timer resolution has increased from 10ms to
> >   1ms in 2.6.  Why does the itimer have such a large granularity?  I
> >   expected it to be highly accurate in this range.
> 
> I think it is.  The missing understanding is, I think, that you expect the 
> resolution to be exactly 1/HZ or 1ms.  It is actually not exactly that 
> because the PIC can not generate 1ms interrupts (close but not close enough 
> for NTP). So the kernel figures out what the true PIC rate is and sets up 
> the resolution for that.  This results in a resolution of ~999,849 
> nanoseconds (i.e. instead of 1,000,000 nano seconds per tick).  Now there 
> is some errors in converting this to micro seconds..., but the actual math 
> is done with more precision with the conversion after (which is why the 
> various times the program tries don't come out being exact multiples of 
> each other, or of anything expressed as only microseconds).

I expect there are at least a few applications that will misbehave because
the developers did not expect a timer to behave this way (regardless of
whether it's proper according to the spec).

Is it possible to choose a timer resolution that errs on the high side of
1ms instead of the low side? [*]  It seems to me that would result in the
application getting very close to the expected number of alarm signals.  I
am not at all familiar with the kernel design so I don't know if this would
be feasible or not.

[*] If this is the 8254 timer, using 1192 as a divisor should result in a
resolution of ~1,000,686 nanoseconds.

-- 
I mean, if 10 years from now, when you are doing something quick and dirty,
you suddenly visualize that I am looking over your shoulders and say to
yourself, "Dijkstra would not have liked this", well that would be enough
immortality for me.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fw: missed itimer signals in 2.6

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

> [*] If this is the 8254 timer, using 1192 as a divisor should result in a
> resolution of ~1,000,686 nanoseconds.

Sorry, I meant to say 1194 as a divisor.

-- 
Meekness:  Uncommon patience in planning a revenge that is worth while.
        -- Ambrose Bierce

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fw: missed itimer signals in 2.6

[George Anzinger]

Tom Marshall wrote:
>>>I understand what happens and why.  I admit that I'm not familiar with the
>>>POSIX standard on this issue.  Questions:
>>>
>>>* I've heard that the kernel's timer resolution has increased from 10ms to
>>>  1ms in 2.6.  Why does the itimer have such a large granularity?  I
>>>  expected it to be highly accurate in this range.
>>
>>I think it is.  The missing understanding is, I think, that you expect the 
>>resolution to be exactly 1/HZ or 1ms.  It is actually not exactly that 
>>because the PIC can not generate 1ms interrupts (close but not close enough 
>>for NTP). So the kernel figures out what the true PIC rate is and sets up 
>>the resolution for that.  This results in a resolution of ~999,849 
>>nanoseconds (i.e. instead of 1,000,000 nano seconds per tick).  Now there 
>>is some errors in converting this to micro seconds..., but the actual math 
>>is done with more precision with the conversion after (which is why the 
>>various times the program tries don't come out being exact multiples of 
>>each other, or of anything expressed as only microseconds).
> 
> 
> I expect there are at least a few applications that will misbehave because
> the developers did not expect a timer to behave this way (regardless of
> whether it's proper according to the spec).
> 
> Is it possible to choose a timer resolution that errs on the high side of
> 1ms instead of the low side? [*]  It seems to me that would result in the
> application getting very close to the expected number of alarm signals.  I
> am not at all familiar with the kernel design so I don't know if this would
> be feasible or not.
> 
> [*] If this is the 8254 timer, using 1192 as a divisor should result in a
> resolution of ~1,000,686 nanoseconds.

Well here is the rub.  Your high side give an error of 686 PPM while the low 
side has an error of only 152 PPM.  This assumes, of course, that you are trying 
to hit exactly 1,000,000 nano seconds per tick.

On the other hand, since we do correct for this error, I suspect one could use 
the high side number.

Still, if an application depends on the count rather than just reading the 
clock, I suspect that some would consider it broken.  Timer signals can be 
delayed and may, in fact overrun with out notice (unlike POSIX timers which tell 
you when they overrun).

What you really need is a higher resolution timer.  Funny, there seems to be a 
reference to such a thing in my signature :)
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: Fw: missed itimer signals in 2.6

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]

> >I expect there are at least a few applications that will misbehave because
> >the developers did not expect a timer to behave this way (regardless of
> >whether it's proper according to the spec).
> >
> >Is it possible to choose a timer resolution that errs on the high side of
> >1ms instead of the low side? [*]  It seems to me that would result in the
> >application getting very close to the expected number of alarm signals.  I
> >am not at all familiar with the kernel design so I don't know if this would
> >be feasible or not.
> >
> >[*] If this is the 8254 timer, using 1192 as a divisor should result in a
> >resolution of ~1,000,686 nanoseconds.
> 
> Well here is the rub.  Your high side give an error of 686 PPM while the 
> low side has an error of only 152 PPM.  This assumes, of course, that you 
> are trying to hit exactly 1,000,000 nano seconds per tick.
> 
> On the other hand, since we do correct for this error, I suspect one could 
> use the high side number.

It doesn't really matter to me, as an application developer, what the actual
numbers are.  What matters is that when I ask for a timer in the 1..50ms
range, I get a reasonably close number of SIGALRMs to what I requested. 
Having to adjust the resolution by 9% at 10ms when I know the system clock
is ticking at 10x that rate seems to be a bit broken from that perspective
(not technically, but perceptually).

> Still, if an application depends on the count rather than just reading the 
> clock, I suspect that some would consider it broken.  Timer signals can be 
> delayed and may, in fact overrun with out notice (unlike POSIX timers which 
> tell you when they overrun).

Our code does not depend solely on the delivery of SIGALRM.  It resyncs
periodically using gettimeofday().

> What you really need is a higher resolution timer.  Funny, there seems to 
> be a reference to such a thing in my signature :)

I have rewritten our timer code to take the information learned in this
thread into account.  It turns out that at least one other *nix platform has
problems with the magical 10ms number and, unlike the 2.6 kernel, does not
seem to fill in the actual interval for getitimer().

Thanks again for taking the time to explain the timer system to me.

-- 
Never argue with an idiot.  They drag you down to their level, then beat you
with experience.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fw: missed itimer signals in 2.6

[George Anzinger]

Tom Marshall wrote:
>>>I expect there are at least a few applications that will misbehave because
>>>the developers did not expect a timer to behave this way (regardless of
>>>whether it's proper according to the spec).
>>>
>>>Is it possible to choose a timer resolution that errs on the high side of
>>>1ms instead of the low side? [*]  It seems to me that would result in the
>>>application getting very close to the expected number of alarm signals.  I
>>>am not at all familiar with the kernel design so I don't know if this would
>>>be feasible or not.
>>>
>>>[*] If this is the 8254 timer, using 1192 as a divisor should result in a
>>>resolution of ~1,000,686 nanoseconds.
>>
>>Well here is the rub.  Your high side give an error of 686 PPM while the 
>>low side has an error of only 152 PPM.  This assumes, of course, that you 
>>are trying to hit exactly 1,000,000 nano seconds per tick.
>>
>>On the other hand, since we do correct for this error, I suspect one could 
>>use the high side number.
> 
> 
> It doesn't really matter to me, as an application developer, what the actual
> numbers are.  What matters is that when I ask for a timer in the 1..50ms
> range, I get a reasonably close number of SIGALRMs to what I requested. 
> Having to adjust the resolution by 9% at 10ms when I know the system clock
> is ticking at 10x that rate seems to be a bit broken from that perspective
> (not technically, but perceptually).
> 
> 
>>Still, if an application depends on the count rather than just reading the 
>>clock, I suspect that some would consider it broken.  Timer signals can be 
>>delayed and may, in fact overrun with out notice (unlike POSIX timers which 
>>tell you when they overrun).
> 
> 
> Our code does not depend solely on the delivery of SIGALRM.  It resyncs
> periodically using gettimeofday().
> 
> 
>>What you really need is a higher resolution timer.  Funny, there seems to 
>>be a reference to such a thing in my signature :)
> 
> 
> I have rewritten our timer code to take the information learned in this
> thread into account.  It turns out that at least one other *nix platform has
> problems with the magical 10ms number and, unlike the 2.6 kernel, does not
> seem to fill in the actual interval for getitimer().

That is the standard.  They must be broken :(
> 
> Thanks again for taking the time to explain the timer system to me.
> 
You are very welcome.
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml