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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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   [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux