On Tue, Jun 02, 2009 at 02:20:39AM +0200, Ingo Molnar wrote: > > Would this not be true already, because the convergence of Linux > > system suddenly became a lot slower in 2.6.19? > > > > Damned if we do, damned if we don't - except the new behaviour > > introduced by your patches is nicer. > > Not just that - but there's calibration noise during bootup that can > cause randomly distributed recalibrations as well. So other hosts in > a mixed environment will see inconsistencies anyway, after every > bootup. > > NTP is all about being able to be resilient against time noise and > being able to sync up to a common time base ASAP. There has to be a compromise between frequency and offset noise. When SHIFT_PLL is set to 2 the frequency noise will be higher and that will have a negative impact on the long-term ability to keep the clock accurate. The error will grow faster when network connection is suspended. The PLL response can be configured to be the same as the proposed SHIFT_PLL 2 by decreasing the time constant value in adjtimex structure, so I'd rather keep following the NTP specification and control it from userspace if necessary. As for the calibration issue, would it be possible to export the information that an instable clocksource is used and when was the last time it was calibrated? Then we'd know when the drift file should not be trusted and let NTP calculate the frequency directly (it takes about 15 minutes). -- Miroslav Lichvar -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|