`Ok, first of all I want to show you the output of my programrunning on my arm device.TIMER_INTERVAL          =1000msCOUNTER                 =1expected elapsed time   =1000mselapsed time            =1010ms and 14nsTIMER_INTERVAL          =1000msCOUNTER                 =1expected elapsed time   =1000mselapsed time            =1009ms and 981nsTIMER_INTERVAL          =1000msCOUNTER                 =1expected elapsed time   =1000mselapsed time            =1010ms and 12nsAs you can see, it is always about 10ms late. The 14ns, -19ns and12ns difference are because of latency.TIMER_INTERVAL          =100msCOUNTER                 =10expected elapsed time   =1000mselapsed time            =1100ms and 9nsTIMER_INTERVAL          =100msCOUNTER                 =10expected elapsed time   =1000mselapsed time            =1099ms and 994nsTIMER_INTERVAL          =100msCOUNTER                 =10expected elapsed time   =1000mselapsed time            =1100ms and 8nsMuch more interesting is the output for 10ms timers.TIMER_INTERVAL          =10msCOUNTER                 =100expected elapsed time   =1000mselapsed time            =2000ms and 0nsTIMER_INTERVAL          =10msCOUNTER                 =100expected elapsed time   =1000mselapsed time            =1999ms and 998nsTIMER_INTERVAL          =10msCOUNTER                 =100expected elapsed time   =1000mselapsed time            =2000ms and 3nsNow, you can maybe see my problem. If I want to write a programwhich should just send something every 10ms with the current 2.6implementation, it will only send something every 20ms. I don'tcare about the time between timers that much. But for 10msinterval timers, I want to have 100 triggered timers within onesecond.The precision of timers can never be better than the size ofone jiffie. But with the old 2.4 solution the maximum deviationis +/- 10ms, with your solution (the current 2.6 approach) itis +20ms (for arm platform, where a jiffie size is 10ms).The bad thing is, that the average deviation for 2.4 kernels is0ms and for 2.6 kernels 10ms.I see the problem for x86 architecture, where the size of onejiffie is 999849ns. That means, that jiffie: 0 s0ms 0nsjiffie: 1 s0ms 999849nsjiffie: 2 s1ms 999698nsjiffie: 3 s2ms 999547nsjiffie: 4 s3ms 999396nsjiffie: 5 s4ms 999245nsjiffie: 6 s5ms 999094nsjiffie: 7 s6ms 998943nsjiffie: 8 s7ms 998792nsjiffie: 9 s8ms 998641nsjiffie: 10 s9ms 998490nsRight? But for arm, with a jiffie size of 10000000, it is muchmore easier. And that is why I don't understand why an one secondinterval is converted to 101 jiffies (on arm).On Thu, 16 Sep 2004 13:19:58 -0700George Anzinger <george@mvista.com> wrote:> [...] However, the standard seems to> say that what you should measure is the expected arrival time> (i.e. assume zero latency).  In this case the standard calls> for timers NEVER to be early.I agree. But then, why adding one jiffie to every interval? Ifthere is no latency, the timer should appear right at thebeginning of a jiffie. For x86 you are right, because 10 jiffiesare less then 10ms. But for arm, 1 jiffie is precisely 10ms. > > So, what about adding this rounding value just to it_value to> > guarantee that the first occurrence is in it least this time?> > The it_value and the it_interval are, indeed, computed> differently.  The it_value needs to have 1 additional> resolution size period added to it to account for the initial> time starting between ticks.  The it_interval does not have> this additional period added to it.  Both values, however, are> first rounded up to the next resolution size value.Ok, I will have a closer look to the rounding. Maybe it is justnot working for arm.Please, can you send me your test application?Best regards,Henry-- Hi! I'm a .signature virus! Copy me into your~/.signature to help me spread!-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`