Re: [patch 4/9] Remove the TSC synchronization on SMP machines

[Andrea Arcangeli <andrea@suse.de>]

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.