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/
