Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[George Anzinger <george@mvista.com>]

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.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.

Uh, WAIT A NANOSECOND!  Look at what we are doing today in that department.  The 
key is not the ability to convert based on the value of HZ but on the implied 
value of jiffie given CLOCK_TICK_RATE.  Today the value we use for jiffie is 
999849 nanoseconds which is what the given CLOCK_TICK_RATE and HZ end up getting 
from the PIT.

By the time the user comes along we have TICK_NSEC and the current conversion 
routines which are not exactly simple but they are correct.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/