On Mon, 2005-07-11 at 17:38 -0700, George Anzinger wrote:
> Martin J. Bligh wrote:
> >>>Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact in
> >>>stability, AFAIK. (I only remember some weird warning about HZ with debian woody's
> >>>ps).
> >>>
> >>
> >>Yes, that's called "progress" so no one complained. Going back is
> >>called a "regression". People don't like those as much.
> >
> >
> > That's a very subjective viewpoint. Realize that this is a balancing
> > act between latency and overhead ... and you're firmly only looking
> > at one side of the argument, instead of taking a compromise in the
> > middle ...
> >
> > If I start arguing for 100HZ on the grounds that it's much more efficient,
> > will that make 250/300 look much better to you? ;-)
>
> I would like to interject an addition data point, and I will NOT be subjective.
> The nature of the PIT is that it can _hit_ some frequencies better than
> others. We have had complaints about repeating timers not keeping good time.
> These are not jitter issues, but drift issues. The standard says we may not
> return early from a timer so any timer will either be on time or late. The
> amount of lateness depends very much on the HZ value. Here is what the values
> are for the standard CLOCK_TICK_RATE:
>
> HZ TICK RATE jiffie(ns) second(ns) error (ppbillion)
> 100 1193180 10000000 1000000000 0
> 200 1193180 5000098 1000019600 19600
> 250 1193180 4000250 1000062500 62500
> 500 1193180 1999703 1001851203 1851203
> 1000 1193180 999848 1000847848 847848
>
> The jiffie values here are exactly what the kernel uses and are based on the
> best one can do with the PIT hardware.
>
> I am not suggesting any given default HZ, but rather an argumentation of the
> help text that goes with it. For those who want timers to repeat at one second
> (or multiples there of) this is useful info.
>
> For you enjoyment I have attached the program used to print this. It allows you
> to try additional values...
If I recall, 1001 was a decent choice and is relatively close the the
expected frequency. Also I think the error is positive instead of
negative, so it avoids the "jiffies are shorter then I expected!"
issues.
>From your program's output:
HZ TICK RATE jiffie(ns) second(ns) error (ppbillion)
1001 1193180 999013 1000012013 12013
thanks
-john
-
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]
| |
 |