Linux time question....

Oooooooooohhhhhh.

So the system time is coming from another system which is getting its time from a GPS receiver?

How is it being synced? I know you said a cron job, but what's the cron job doing? An ntp daemon would be a better solution. In fact, it may be the solution.

It's called ntpdate it runs at 2 in the morning. It connects to a box in the Manchester Computing Center which has the GPS attached to it.

Looking through the cron logs it seems that ntpdate is correcting by at least a second every day. I think updating more regularly may do the trick.

If you're using ntpdate, that means you already have an NTP server that it's syncing to. Just use an NTP daemon. That'll keep it in perfect sync. Within milliseconds, if not better.

yes.. you want to run ntpd, instead of running ntpdate on a cron. I've been told that it's best to setup ntpd with around 6 good sources to maintain a good solid clock sync.. ntpd will drift your system clock dynamicaly to adjust for inacuracies in most PC's poor clock chips. This will keep everything in sync.. I use this on many servers.. it's great.

In reality, it'll only use one at a time to sync to, based on some server quality calculations I don't know. The others are only in case it loses connection to the one it's using, or if the one it's using starts to be of a lesser quality. However, if he's got a machine sitting right next to it that's a stratum 1 server (meaning it's connected directly to an official source), it's not such a big deal, unless that machine is down a lot.

My understanding is that the PC's hardware RTC is based upon a CMOS circuit operating a 32.768KHz xtal and on boot, the OS tends to sample the time/date and maintain it from there on making the hardware clock redundant until the next reboot. Sure Linux might be different and my supposition is based upon MS Windows here.

Can't you schedule the cron job for (say) every 15mins so that the time adjustments made are quite small but at the same time keep the OS clock fairly accurate?

RIght then after some rummaging i've configured ntpd and started it on the machine. Does this ntp.conf file look okay?

Code:

---

restrict default ignore
server ntp2a.mcc.ac.uk
server ntp2b.mcc.ac.uk
server ntp2c.mcc.ac.uk
server ntp2d.mcc.ac.uk
server ntp0.uk.uu.net
server ntp1.uk.uu.net
server ntp2.uk.uu.net
server ntp.cs.strath.ac.uk
server ntp.tcd.ie
server tick.tanac.net
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

---

I believe so. In order to check that it's running properly, run "ntpq". You can use it to check the status of the NTP daemon.

When you run ntpq, type in "peers" or "pe". This will return a list of all the servers you're conected to, with some related information. If it's working right, one of them should be marked with an asterisk, which indicates that it's the one being used to sync to. If it's still working on initial sync, it'll use a plus symbol for the one it will sync to once it's going good. Now type "associations" or "as". This will show the same servers, without good identifiers. Find the one listed as "sys.peer" (or the other odd man out if it's still in initial sync), assuming I remember all this correctly. Then type "pstatus" or "ps" followed by the appropriate assID from the associations list you just ran. This will produce a lot of information about the peer.

When you initially start the ntp daemon, it'll show all eight columns at the bottom of the pstatus output at zero. As it contacts the remote NTP server, it'll start to populate those columns. After it's done with all eight, it'll zero them back out and start over. Once it's filled them all up again, it'll start syncing your system clock. However, if the system clock is way off, it'll refuse, so make sure you run ntpdate once before starting your ntp daemon.

Looking good, one last question. I've compared 'pe' outputs over a couple of hours, I assume it's normal for ntpd to swap preferred servers. It's done it once already today.

Thanks for all your help.

It figures out which is the best based on certain criteria that I don't know the ins and outs of, but I imagine it includes round trip time as a significant factor. I'm guessing that those machines are all topologically close to each other and similarly configured, so I suppose it makes sense for it to flip-flop. It doesn't really make any difference, as it's always getting time info from all the servers you have configured, and they should all be close enough that it's not going to make any difference on the time.

So, short answer, it's probably perfectly fine.