On 12.07.2005 [10:50:23 -0700], john stultz wrote: > On Tue, 2005-07-12 at 08:26 -0700, Martin J. Bligh wrote: > > >> > The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, > > >> > ...) > > >> > and is divided by 12 to get PIT tick rate > > >> > > > >> > 14.3181818 MHz / 12 = 1193182 Hz > > >> > > > >> > The reality is that the crystal is usually off by 50-100 ppm from the > > >> > standard value, depending on temperature. > > >> > > > >> > HZ ticks/jiffie 1 second error (ppm) > > >> > --------------------------------------------------- > > >> > 100 11932 1.000015238 15.2 > > >> > 200 5966 1.000015238 15.2 > > >> > 250 4773 1.000057143 57.1 > > >> > 300 3977 0.999931429 -68.6 > > >> > 333 3583 0.999964114 -35.9 > > >> > 500 2386 0.999847619 -152.4 > > >> > 1000 1193 0.999847619 -152.4 > > >> > > > >> > Some HZ values indeed fit the tick frequency better than others, up to > > >> > 333 the error is lost in the physical error of the crystal, for 500 and > > >> > 1000, it definitely is larger, and thus noticeable. > > >> > > > >> > Some (less round and nice) values of HZ would fit even better: > > >> > > > >> > HZ ticks/jiffie 1 second error (ppm) > > >> > --------------------------------------------------- > > >> > 82 14551 1.000000152 0.2 > > >> > > >> > > >> Most interesting... Would 838 Hz be a much better choice than 1000 then? > > >> (apart from the ugliness). > > > > > > No, 838 isn't significantly better. 864 and 627 would be better > > > candidates: > > > > > > HZ ticks/jiffie 1 second error (ppm) > > > --------------------------------------------------- > > > 627 1903 0.999999314 -0.7 > > > 838 1424 1.000109105 109.1 > > > 864 1381 1.000001829 1.8 > > > > > > A good HZ value would make ntpd significantly happier, if the crystal is > > > of reasonable quality. > > > > > > 152ppm (1000Hz) is 13 seconds a day, > > > 0.7 ppm (627Hz) is 22 seconds a year. > > > > Does positive vs negative error make a difference to the timer subsystem? > > Nish was telling me they had to add 1 extra tick to timer inaccuracies > > because of the errors ... does changing the polarity of the error > > affect that (seems like it would ... but I got lost by now ;-))? > > It doesn't affect the soft-timer subsystem very much due to the > additional rounding described above, but it does affect anywhere jiffies > is used directly via HZ for time. Awhile back there were some issues we > had with proc output being confused in the transition via HZ, ACTHZ and > USER_HZ that were related. > > This would probably be a good plug for Nish's time based (as opposed to > tick based) soft-timer work. By utilizing the timekeeping subsystem, > using absolute nanoseconds since boot instead of jiffies to expire soft- > timers we can avoid worrying about HZ/ACTHZ error in that subsystem. > Additionally it avoids any sort of accumulating error which could be > caused by lost ticks and allows for lower best-case latencies and > improved average latencies.
FWIW, I will be trying to get a new version of my patch which is independent of John's timeofday rework (will use xtime & wall_to_monotonic as a nanosecond "time" value) out before the end of the week. I think these arguments are still valid for the worst-case scenario with my patch, as the hardware interrupt rate is still tied to HZ. But, at least, we can discuss it in clearer terms and disjoin the soft-timer issues from the hardware ones (I hope). Thanks, Nish - 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/
