My linode is losing about 15 seconds per day. I run cron jobs at various times and need reasonable accuracy for my end users.

I'm not sure whether time has been "virtualised" with UML. Can system time be synchronised at least one per day?

Interesting -- I'll ask Jeff (creator of UML) about it.

I believe your Linode gets the initial time from the host at each boot. But, I think it acts like a software clock from there.

Are you running ntp? You're able to change/set the time when ever you need to.

-Chris

It looks like the date has been "virtualised" as I can set it with the 'date' command.

I can't seem to get rdate to work - 'rdate -p ntp.nasa.gov' gives 'No route to host'.

But the following Perl script works on the small Redhat distro - it uses UDP on port 123 to get the time from an ntp server
http://www.kloth.net/software/sntp.htm

Does this work for you:

/usr/sbin/ntpdate -s -b -p 8 clock.redhat.com

-Chris

$ ./sntpclock `dnsip ntp2.kansas.net` | ./clockview
before: 2003-08-11 11:31:54.395679000000000000
after: 2003-08-11 11:33:16.993675980730354785
$ uptime
11:32:10 up 16 days, 6:09, 1 user, load average: 0.07, 0.02, 0.00

$ ./sntpclock `dnsip ntp2.kansas.net` | ./clockview && echo && ./sntpclock `dnsip clock.redhat.com` | ./clockview
before: 2003-08-11 11:39:29.600608000000000000
after: 2003-08-11 11:40:52.257771671075329184

before: 2003-08-11 11:39:30.094399000000000000
after: 2003-08-11 11:40:52.750950499869413673

Before then after a reboot. The clock on my linode seems consistent, just looks like host2's clock is off by 82 seconds. Of course, if it really bothered me that much I could just change the time on my linode

Kenny

I ended up installing ntpd on my Debian system, and it has worked well for keeping the clock up-to-date.

Are there any plans for an ntp.linode.com server, so I don't have to burden the public servers that I'm using?

_________________
Bus error (passengers dumped)

I'm also running ntpd on my system.

Now when my system isn't busy idling (:shock:), it's knocking 250ms off the clock. This happens about every half an hour, and the syslog is dominated by lines like these:

Sep  9 20:17:07 quotable ntpd[4324]: time reset -0.274347 s
Sep  9 20:17:07 quotable ntpd[4324]: synchronisation lost
Sep  9 20:29:43 quotable -- MARK --
Sep  9 20:50:32 quotable -- MARK --
Sep  9 20:53:49 quotable ntpd[4324]: time reset -0.271359 s
Sep  9 20:53:49 quotable ntpd[4324]: synchronisation lost
Sep  9 21:11:21 quotable -- MARK --
Sep  9 21:28:34 quotable ntpd[4324]: time reset -0.262755 s
Sep  9 21:28:34 quotable ntpd[4324]: synchronisation lost
Sep  9 21:52:59 quotable -- MARK --

Is it normal for UMLs to be losing time at this rate?

Mine does.

$ uptime; sntpclock `dnsip ntp2.kansas.net` | clockview
17:08:16  up  6:00,  1 user,  load average: 0.00, 0.00, 0.00
before: 2003-09-03 17:08:17.082964000000000000
after:  2003-09-03 17:08:20.034561662591069936
------
 17:37:06  up  6:27,  1 user,  load average: 0.08, 0.02, 0.01
before: 2003-09-03 17:37:07.275384000000000000
after:  2003-09-03 17:37:10.452421301536075770
------
 12:44:15  up 1 day, 23:40,  2 users,  load average: 0.00, 0.00, 0.00
before: 2003-09-05 12:44:16.433667000000000000
after:  2003-09-05 12:44:39.748888432488374411

I really didn't want to run ntpd on my host (ntpd just.. doesn't make me feel good [i haven't checked out xntpd]) and even if clockspeed would have ran, I figured it would've have made matters much worse as it depends on a "persistently fast or slow system clock". I ended up just writing a script that will correct the clock if it is beind. It runs from cron every half hour and one fourth second

Am I right that the reason this happens is because the linodes keep their own system time with a software clock?


kenny

Looking through the UML source code, I discovered I was wrong about how UML manages time. It uses an offset from the host's time (it looks like it calls gettimeofday and then addes the UML instance's offset).

I'm now looking towards the host clock being the problem. I'm gathering some stats and will update here when I know more.

-Chris

The host servers are now running ntpd, instead of just random ntpdate calls. That should take care of the issue.

You shouldn't have to run ntp inside your Linode after this change, that is unless you don't trust the host or want more accuracy than the small drift between updates.

Let me know if this doesn't fix stuff.

-Chris

Is host8 on ntpd as well? It seems to be wandering slowly away from standard time.

This is from the loop statistics of my own ntpd (the drift is in bold typeface):

Host8 is running ntpd. I can't quite get my head around how ntpd on the host, and ntpd inside UML are going to interact. Perhaps as host8 slowly goes into sync (which it should be by now), your Linode has to compensate?

-Chris