[lkml]   [2005]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: itimer oddness in 2.6.12
Tom Marshall wrote:
> The patch to fix "setitimer timer expires too early" is causing issues for
> the Helix server. We have a timer processs that updates the server's
> timestamp on an itimer and it expects the signal to be delivered at roughly
> the interval retrieved from getitimer. This is very consistent on every
> platform, including Linux up to 2.6.11, but breaks on 2.6.12. On 2.6.12,
> setting the itimer to 10ms and retrieving the actual interval from getitimer
> reports 10.998ms, but the timer interrupts are consistently delivered at
> roughly 11.998ms.

Unfortunately, this is not so clear cut as it seems :(

I tested this on my system again, and if I set the timer to 9900us and
put the system to some load I get intervals as low as 10022us with a
vanilla kernel. Removing this patch would cause the system to
give me 9022us intervals which is just unnacceptable.

The reason this misbehaves in your case is that 10ms is converted into
11 jiffies. I'm not really an expert in the time subsystem, but I guess
this happens because 1000HZ aren't _exactly_ 1000HZ, they're probably a
little more, so to guarantee 10 ms, we need 11 jiffies (or there is a
bug in the timeval->jiffies conversions).

If HZ is slightly greater than 1000, this means that each tick will come
in slightly less than 1 ms. Lets assume we want 2 ms intervals:

^ ^ ^ ^
0 1 2 3

If you place your request at instant "1" and the time between ticks is
slightly less than 1 ms, at instant "2" there is no guarantee that the
time has ellapsed, only at instant "3" that is 4 ticks away. If you
place that request at instant "0", you'll get almost 4ms.

So, the fact that 10 ms are converted to 11 jiffies explains why
getitimer returns 10.998ms.

The fact that you are getting consistently 11.998ms just means that
either your system is pretty idle, or the process that is requesting
this timer has a very high priority so that it is able to request the
timer again right after the timer tick (like in instant "0").

If this process is delayed for some reason and just requests the timer
in the middle of the tick you would start seing values like 11.5ms.

If 10ms in jiffies would be just 10, then you would see 11ms between
alarms, and getitimer would report 10ms.

The only way this could be better was if we knew "where" inside the tick
we were when we set the timer (as discussed in the thread you
mentioned), but in your case, even this wouldn't help because you're
requesting a 10ms timer and to absolutely conform to the setitimer
specification we can't just give you a 9.9ms interval.

Anyway, making the software depend on the time a timer takes to expire
when the man page states "Timers will never expire before the requested
time, ... the delivery will be offset by a small time dependent on the
system loading" doesn't seem like a very robust software design to me...

Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-22 21:25    [W:0.044 / U:1.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site