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

[George Anzinger <george@mvista.com>]

Con Kolivas wrote:
> 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. 

No, that doesn't hold water either.  We already jigger jiffie to be _close_ to 
1/HZ and closer still to what we can get from the PIT as its true period (for 
example, today the jiffie is 999849 nanoseconds) and this too is only accurate 
to the nanosecond.  Here are the jiffie values for several HZ values using the 
formulas in the code which use the TICK_RATE as given by the hardware.  Note the 
error here is the difference between an asked for repeating timer of 1 second 
and what the system clock on the same system says, NOT what real time is in 
either case, just relative between the two.  In otherwords, if you set up an 
itimer to signal every second and looked at the long term drift between the 
signals it gives and the system clock you would see the itimer drifting by 
~914ppm (with HZ = 846).

HZ  	TICK RATE	jiffie(ns)	second(ns)	 error (ppbillion)
 100	 1193182	10000000	1000000000	       0
 200	 1193182	 5000098	1000019600	   19600
 250	 1193182	 4000250	1000062500	   62500
 500	 1193182	 1999688	1001843688	 1843688
1000	 1193182	  999848	1000847848	  847848
 846	 1193182	 1181717	1000914299	  914299

> Cheers,
> Con

--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/