Despite setting the hardware clock in CMOS setup at boot-up, with Lithium battery OK, and that "ntp" and "ntpdate" are installed, and /etc/ntp.conf and /var/lib/ntp/ntp.drift exists, the time as reported using #date is not in step with the MSF radio time signal. The clock display ticking away at lower right on the desktop screen is similarly in error, ahead by about 5 seconds. I have searched the threads, but none of the answers worked for me.

Is there anywhere a clear explanation on how to make this happen right, with perhaps some diagnostic command tricks on the way to check?

I should explain that although I have been a Linux desktop applications user for years, I am a newbie at systems setup. This time the need is to use a Linux box to provide real-time satellite earth station servo drives control (big dishes!). The need is similar to network server time control.

The system I am trying things out on happens to be Ubuntu-based Linux Mint 17, though the box used in the final kit need not be.

Clearly something happens. The value in /var/lib/ntp/ntp.drift is -11.096 seconds? Still no way to set the time accurately, and I am not sure the time seen in the system is the same as in the hardware clock.

The ntp daemon can be stopped and started from root terminal OK.

I have read that "ntpdate" is deprecated and that "ntpd" is to be more used in future. This alone makes the majority of advice seen in searches moot. Many thanks if anyone can help.

At the time of your post your synced to panda.zeroloop 145.238.203.14 with an offset of 0.38 ms.

Currently if I query the same time server.
ntpdate -q 145.238.203.14
server 145.238.203.14, stratum 1, offset -0.004696, delay 0.15808
23 Jun 07:30:36 ntpdate[3206]: adjust time server 145.238.203.14 offset -0.004696 sec

My offset is 4.69 ms. So at the moment ntp seems to be working ok although I can not explain why your clocks appears to be 5 seconds fast.

The hardware clock and the system clock are independent of each other. The hardware clocks only function is to set the system clock at boot up. ntp will update the hardware clock every 11 minutes.

Thanks much for the reply michaelk.
I am steadily learning things about how to do this.

I have concluded that ntp daemon is probably working OK because I have noted the value in the ntp.drift file is changing at various times, now set at 12.128

#ntpdate -q 145.238.203.14
server 145.238.203.14, stratum 1, offset -0.009578, delay 0.09871
23 Jun 14:40:22 ntpdate[6976]: adjust time server 145.238.203.14 offset -0.009578 sec
#

Everything seems OK except that the time available to applications seems to be (at present) about 3 seconds ahead.
Earlier today, it was more than 5 seconds.

I know the MSF radio clock is in step with real time to a far greater accuracy than any computer time, and it is what I use for checking. Several seconds out for applications is not good enough to keep drive servos pointing at a low orbit moving satellite. Normal server time accuracy for networks would be near good enough, and if compensated by using the drift file in ntp, might well be completely OK.

I would not clutter your life by posting my complete "ntp.conf", but I might enable the logging function for a while..

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

Though I don't really want to pick apart the whole process by which my computer ends up thinking it is several seconds into the future, I do need to get this right. I know there are available radio-clock time standards that can do this, for example..

http://www.timetools.co.uk/

Such extreme stuff does seem a bit OTT when this sort of thing can be done via network time servers out there, which already have this sort of kit, and are broadcasting it (with known offsets) to most places.

#edit: The value in ntp.drift has a minus sign "-12.128", and I am thinking the units might be milliseconds - not seconds!

ntp slowly corrects the system clock on purpose so its better if the computer runs continuously until it stabilises drift.

Thanks michaelk.
The good news is that by this morning, the "future error" has reduced to about 2 seconds.

Drift is one thing, and is apparently measured and compensated for. That part is probably working OK. This is not the same thing as not being set to the actual time. We cannot wait days for the correct time to be set.

How does one do a one-time command to set the time? Indeed, why does it not come up accurate just after a re-boot? I thought ntp runs at start-up, and possibly periodically through cron.

After reading up on how http://www.itworld.com/nls_unixntpcommands041014
.. the third page explains the advantages of "ntpdate".

Maybe just need to understand the ntpdate command better. It might need the "-b" option.

P.S.
I have just tried using ntpdate.
To get it to work, one has to first stop the ntp daemon, because the NTP socket is in use. Then, use ntpdate, and wait. When it completes, the start the ntp daemon again.
It all looks very good, but I have to say that the system time still ticks away 2 seconds ahead.
It is as if the system clock went on relentlessly, completely un-affected by the command.

Is Mint running some sort of work-around that one cannot at all modify what it thinks is the time?

ntpdate should force a time correction but ntp with the -g option should do the same thing.

I have found that right-click the time/date display, and go for "preferences" lets you change the time, with a first-time miss because of the root password dialogue. OK - so now at least the computer clock is in step with the radio reference. I does make me wonder whether the rest of ntp is running separately, all on it's own..
Anyways, thanks much for your help.

Many thanks for the help so far from michaelk.
I will post any further things I find out in the Linux Mint section of this forum.

Info possibly of interest to Linux Mint users:

I have discovered that on boot-up, and possibly also at regular intervals, the system actually forcibly resets the Hardware Clock, even though it is already correct to within less than 200 milliseconds. This might be a well meaning use of ntp, scripts or cron that has gone wrong.

If I ensure the CMOS clock (with new battery) is set to the correct time during BIOS setup, then start (Mint), the time will will show as about 2 seconds later than it should.

After new re-start, we find the CMOS Hardware Clock has been advanced by the unwanted 2 seconds.

Even if we use the set time facility, (root password required), or force it with ..

#hwclock --set --date="6/28/14 12:50:00" // Force a time on CMOS clock.
#hwclock -s // Make the system clock accept that time

.. the unwanted 2 seconds will re-appear after a while.

It cannot be that Mint should insist on using the wrong time!

This situation is so, for both Linux Mint 14, and a new Linux Mint 17 installation.
If anyone has a good suggestion, I will be very grateful, but clearly this issue may well belong in a different forum.

Hardware clocks tend to drift and as discovered ntp will update it every 11 minutes. ntp will also calculate its drift and store it in /etc/adjtime. Its possible that this factor is off which is driving the computer to be 2 seconds off at boot.

The ntp start up script should be configured to use the -g option. This should force the system clock to be the correct time. The -g option does the same thing as running ntpdate (The basic reason why it has been deprecated). Not sure why ntpdate didn't correct time either.

http://linux.die.net/man/8/hwclock

The other obvious question is have you verified your MSF radio clock is correct?

Indeed - this is a good point. I very much hope this turns out to be the case. Probably a GPS SatNav would be a good alternative.

setting up a time server with a GPS receiver is not difficult. I Have a Garmin 18X unit that has a serial interface with 1 PPS output.

My thanks michaelk. The kit in the rack would normally have a GPS unit, but for this one, the client has had fitted whole 1u high GPS time server with multiple network outputs.

----------------------

Related to this, simply because always I trusted the computer clock more, and I am wary of the lower cost variety of electronic kit, I have just now added a new Auriol Time Standard Receiver, which uses the DST broadcast from Frankfurt locked to atomic time standards.

Thankfully, it is in step with the Mint. The science MSF radio time standard clock, even though I have seen it lock to the MSF signal and correct its time from a cold start, is the 2 seconds behind, which is hard to believe, but I can see it so.

Many thanks for your interest and help.