Hi, On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote: > It's not inherent to ntpd's design, but the current (which may have been > fixed since I looked last) implementation of the NTP PLL in the kernel. > > The interaction with ntpd can be fixed and I've done it in the past > once, although the fix wasn't all that nice.
Yep, it can slowly move towards the correct time, but ntpdate (or more generally settimeofday) remains a fundamental issue (and I prefer time skews to be fixed ASAP, not slowly). If the admin is good, he can know that if he ever runs the db when the clock isn't perfectly synchronized with the atomic clock, he risks to screwup his whole dataset as the apps won't even handle time going backwards after reboot. I think there should be a limit to how much an app can pretend from gtod before generating failures. Certainly it's always better to write apps that are robust against a not monotonic gtod because eventually it _can_ happen (either that or remove the stod syscall ;). About ntpdate at boot and ntpd at runtime, not running them isn't really an option on the server IMHO, think the liability if system time runs out of sync of a minute and you need to know exactly when something bad has happened. - 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/