wallclock drift on Debian 6 (2011) i386 Linode

That document is many years out of date. With modern kernels (>2.6.20 or so, with Xen support in the mainline kernel), you get the hardware clock with all of its warts, and don't have a /proc/sys/xen.

So, yes, run ntpd. (It should have been installed and configured by default on deployment…)

I think it's the difference between the legacy kernels and the paravirt kernels. I don't recall if there was an underlying technical reason or not but the latter are not slaved to the host clock, so you are responsible for managing time in your guest.

– David

Legacy kernels by default were kept in sync with the host's clock. pv-ops based kernels do not have that option, so you must run ntpd to keep good time.

All of our templates default to pv-ops kernels and have ntpd preinstalled and running by default. It's been that way for some time.

-Chris

@caker:

All of our templates default to pv-ops kernels and have ntpd preinstalled and running by default. It's been that way for some time.
All the templates sans the Debian ones? :p

Anyhow, it does seem weird to be running an ntpd on individual Xen nodes, but having a 2 minutes/month drift would be worse…

I've just installed ntp with apt-get, and immediately got the clock shifted back by one minute, from 2011-01-18 16:54 to 16:53 (tcsh history is the proof). Somehow I cannot find the exact amount that the clock was shifted by (nothing relevant in /var/log/ at all, just some useless spam from ntpd in all the log files), but this seems like a bug that apt-get install ntp makes a sudden shift of your clock by a minute or so, and doesn't even report the amount by which it was so shifted. Very serious security flaw, even. The ntp package therefore sucks, why are there seemingly no alternatives in Debian? I found neither OpenNTPD nor dntpd in apt.

If the local clock is more than 128 seconds ahead of the reference clock, ntpd will set the clock backwards on start. The -x option will tell it to not to do that, but:

1) You probably will never have this problem again, and

2) It would take about 256,000 seconds (or nearly 3 days) to slew the clock into sync.

This isn't a particularly unique security issue, either; root can set the time as it wants. ntpd will at least set it to a relatively correct time.

And yeah, it does seem weird to run ntpd, but what's between your kernel and the hardware? Very, very little. Artificially synthesizing a more stable frequency source that isn't clocked by an existing hardware oscillator is a bit of a hard problem, too, and the old Xen-patched kernels didn't do a satisfactory job of it.

Bah … a step was indeed missed with the last go at our Debian image. We'll be pushing out the fix tomorrow (and discussing internally how to avoid this in the future). Sorry for the mess.

-Chris

@caker:

Bah … a step was indeed missed with the last go at our Debian image. We'll be pushing out the fix tomorrow (and discussing internally how to avoid this in the future). Sorry for the mess.
Can electrodes be connected to the ticketing system?

@Guspaz:

Can electrodes be connected to the ticketing system?
Directly to Jed's … nose?