Re: Is there a problem in timeval_to_jiffies?

[Henry Margies <henry.margies@gmx.de>]

Hello,

Thank you for your answers.

> You, I think, send a bug report.  I replied via bugz.  The open
> question is what value your particular arm platform is using
> for CLOCK_TICK_RATE.  See below.

That is right, but I did not send the bug report, I just answered
to your reply. The requested values are:

HZ: 100
LATCH: 600000
USEC_ROUND: 4294967295                                          
CLOCK_TICK_RATE: 60000000                 
TICK_NSEC: 10000000

> Timers are constrained by the standard to NEVER finish early. 

That is why I wrote to this mailing list, to determine if it
is a bug or a feature :)

But, especially for my arm device, the timers seem to be more or
less accurate. They appear every 20ms with a average deviation of
less than 20ns (without any load of course). The only bad thing
is, that I requested timers for 10ms. I understand your
statement, that timers should not finish early, but for my case,
they just appear exactly 10ms late.

> This means that, in order to account for the timer starting
> between two jiffies, an extra jiffie needs to be added to the
> value.  This will cause a timer to expire sometime between the
> value asked for and that value + the resolution.

In my case, that means, that most of my timers will appear at
least 9980ns too late. And! it is not possible to have 10ms
timers.

But if itimers have to act like this, the current implementation
is right. But anyway, on my board, I have to pay a high price
for that.

Just another comment, 2.4 kernels don't have this feature. So, is
there really a need to have this?


Best regards,
Henry

-- 

Hi! I'm a .signature virus! Copy me into your
~/.signature to help me spread!