I noticed last night that the clock on my linode was two minutes (okay okay, 104 seconds) slow. Thinking that the clock on the linode was synched to the clock on the host, I threw in a support ticket ... and it seems that the newer paravirt kernels (if you've selected the "Latest 2.6 Paravirt" option) will now drift.

Because this is indeed a VPS provider, the host load may drastically slow your clock down. In short, your clock is going to run slow.

If you don't want your clock to run slow, install and run ntpd.

So go install ntpd! Package name might be "ntp" or "ntpd." Be sure to start the service too.

Hey, linode people! Any chance we could get an internal ntp server to sync to? :)

edit: hey linode people! How about opening up the ntp daemon on the hosts to the VMs they support? I like that idea even better.

I realize you weren't aware of it, but I thought this was fairly common knowledge?

Previously, with the UML kernerls, you couldn't adjust your clock -- it was hard synced with the host.

I had a UML based linode, that is now a paravirt-kernel linode.

This is news to me.

do a search in the forums, it's pretty well known. Just grab ntpdate.

Is there any benefit to running ntpd vs just setting up a cronjob to do "ntpdate pool.ntp.org" every month or something?

I did, and found... very very little. Search for "clock AND drift" and you'll see why I posted this.



The advantage of ntpd is that it continually keeps your clock accurate. Instead of jumping forward (or whatever) a large number of seconds, it continually makes minor adjustments to keep the clock in sync. ntpd also (with most distro-provided config files) syncs with several NTP sources at once, which can help negate the effects of general internet latency.

I was seeing a drift of ~2.4186 seconds per day. ntpdate could have been run twice daily and it would help, but with ntpd, you can forget about it entirely.

Note that you can't run ntpd and ntpdate at the same time, as the NTP protocol uses port 139 exclusively on both the server and the client side.

Please don't use ntpdate via cron to keep your clock synced.

Most importantly for your system, it will change your clock abruptly, which can make log timestamps ambiguous. If your clock is fast (its time is ahead of the reference time), a sudden jump backwards can freak things out.

It also causes a sudden and heavy load on the time servers at the top of the minute, even more so at the common cron times (*, */2, */3, etc). You're much better off investing the ~1MB of RAM and running ntpd, pointing it at 0.pool.ntp.org, 1.pool.ntp.org, and 2.pool.ntp.org.

This message brought to you by 0.19% of us.pool.ntp.org

(Also, the clock decoupling appears to be a side effect of the mainline Linux Xen implementation. I believe we're seeing the physical host's inherent clock drift. The virtualization is THAT GOOD.)

The statistics geek in me would love to see a graph of requests for the top of the minute requests. It would seem that the spike would relate to the amount of drift in clocks for those that request them. Probably more like a prolonged 15 second spike on each side of the top of the minute?

So my host drifts more than one second per twelve hours? :/

I sure hope not...

*pats ntpd*

I have a PC that drifts a minute a day. I've heard of worse. There is a threshold where NTP will tell you to get bent and no longer sync because you drift so much, and I've heard of it being hit, too.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Sounds a bit like my router... (which has done that before)

Rest assured that if I could remember where I've seen the graphs, I would have included them. I figure they're somewhere in the timekeepers mailing list archives...

Also, never underestimate how accurate your clock will be if you run ntpdate every minute.

(Don't get me started on htpdate.)



But of course. Your host's hardware clock oscillator deviates from an ideal reference oscillator by about 23 parts per million, or 0.0023%. If we assume a 32768Hz oscillator, it's off by less than 1Hz. That's an easy software fix.

Now, the hard thing to fix is the frequency drift: the rate of change of the frequency is a pain in the butt. ntpd is really good about handling that.

Fun reading: http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

why yes, that is a possibility. This is the short list, there are others.
http://www.linode.com/wiki/index.php/Internal_Services

_________________
~-~ J.T. Sage ~-~
[-=-jtsage.com-=-]

Urm, if I can ask for clarification... is NTP necessary only when using paravirt kernels, or with the "oldstyle Xen" 2.6.18.8 too?
ISTR that one doesn't let me mess with the clock at all...

I like syncing to ntp.canonical.com... from my Windows boxes