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