I've written a simple linux program to grab the current system time and display it on an LED display. The time needs to be accurate as the clock is used to count down to an hourly news service via Satellite. We currently have 2 MSF radio clocks and I've now installed these two digital displays. The machine this runs on has a cron task to syncronise the time with a local GPS locked time server. When I started the app the clocks were in sync, after a day the digital clocks have drifted back by a second, this is unacceptable.

My question is, does a process remain synced to the real time clock? I know in Windows 16 bit apps run in a VM which has it's own RTC which I've witnessed go out of sync with the 32 bit clock. Could something similar happen in linux?

I don't quite understand how you have things set up, but it sounds like you have "official" clocks and the cron job you're running get sthe time from them and resets the system clock. I have no idea how it could get out of sync unless your cron job is not working properly.

To answer your question, though, there is only one system clock in Unix. Calls to get that time are essentially direct calls to the OS. There is no other (standard) place to get time information.

Also, you might want to try to run the official clock through an ntp daemon. There seem to be patches to get xntpd to understand an MSF clock.

I use ntpdate to set the clock. The task is in the middle of the night to stop the clocks possibly bouncing round and confusing people. I may see if its drifted further tomorrow and if necessary, decrease the time between syncs, I may just have a really innacurate drifty RTC.

Thanks for the clarification on the clock calls though Bitt.

Okay, so I'm spamming this thread. Sue me.

Looks like MSF is a reference radio signal for time. So you've got two receivers for that.

Then you've got another system that's getting its time from a GPS receiver, and you say you're syncing to that.

So which of these sources is feeding the system time? If it's the GPS-locked server, what are the MSF receivers for?

That looks quite interesting, although our radio clocks are self contained units so I'd have to buy the MSF module mentioned in the article to make that work.

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.