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

[Con Kolivas]

On Thu, 14 Jul 2005 05:10, 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.

That may be the case but when I've measured the actual delay of schedule 
timeout when using nanosleep from userspace, the average at 1000Hz was 1.4ms 
+/- 1.5 sd . When we're expecting a sleep of "up to 1ms" we're getting 50% 
longer than the longest expected. Purely mathematically the accuracy of 
changing HZ from 1000 -> 864 will not bring with it any significant change to 
the accuracy. This can easily be measured as well to confirm. 

Using schedule timeout as an argument against it doesn't hold for me. 
Vojtech's comment of :
> "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." 
is probably the most valid argument against such a funky number. 

Cheers,
Con

Attachment: pgp00000.pgp
Description: PGP signature