On Wed, 13 Jul 2005, Vojtech Pavlik wrote:
No, but 1/1000Hz = 1000000ns, while 1/864Hz = 1157407.407ns. If you have
a counter that counts the ticks in nanoseconds (xtime ...), the first
will be exact, the second will be accumulating an error.
It's not even that we have a counter like that, it's the simple fact that
we have a standard interface to user space that is based on milli-, micro-
and nanoseconds.
(For "poll()", "struct timeval" and "struct timespec" respectively).
It's totally pointless saying that we can do 864 Hz "exactly", when the
fact is that all the timeouts we ever get from user space aren't in that
format. So the only thing that matters is how close to a millisecond we
can get, not how close to some random number.
So we do a lot of conversions from "struct timeval" to "jiffies", and if
you don't take the error in that conversion into account, then you're
ignoring what is likely a _bigger_ error.
Long-term time drift is a known issue, and is unavoidable since you don't
even know the exact frequency of the crystal, since that is not only not
that exact in the first place, it depends on temperature etc. So long-term
time drift is something that we inevitably have to use things like NTP to
handle, if you want an exact clock.
And in short-term things, the timeval/jiffie conversion is likely to be a
_bigger_ issue than the crystal frequency conversion.
So we should aim for a HZ value that makes it easy to convert to and from
the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
good values for that reason. 864 is not.Linus Torvalds wrote:
On Wed, 13 Jul 2005, Vojtech Pavlik wrote:
No, but 1/1000Hz = 1000000ns, while 1/864Hz = 1157407.407ns. If you have
a counter that counts the ticks in nanoseconds (xtime ...), the first
will be exact, the second will be accumulating an error.
It's not even that we have a counter like that, it's the simple fact that
we have a standard interface to user space that is based on milli-, micro-
and nanoseconds.
(For "poll()", "struct timeval" and "struct timespec" respectively).
It's totally pointless saying that we can do 864 Hz "exactly", when the
fact is that all the timeouts we ever get from user space aren't in that
format. So the only thing that matters is how close to a millisecond we
can get, not how close to some random number.
So we do a lot of conversions from "struct timeval" to "jiffies", and if
you don't take the error in that conversion into account, then you're
ignoring what is likely a _bigger_ error.
Long-term time drift is a known issue, and is unavoidable since you don't
even know the exact frequency of the crystal, since that is not only not
that exact in the first place, it depends on temperature etc. So long-term
time drift is something that we inevitably have to use things like NTP to
handle, if you want an exact clock.
And in short-term things, the timeval/jiffie conversion is likely to be a
_bigger_ issue than the crystal frequency conversion.
So we should aim for a HZ value that makes it easy to convert to and from
the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
good values for that reason. 864 is not.
