LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux Mint (http://www.linuxquestions.org/questions/linux-mint-84/)
-   -   Linux Mint(s) have a ntp time issue (http://www.linuxquestions.org/questions/linux-mint-84/linux-mint-s-have-a-ntp-time-issue-4175509510/)

GTrax 06-28-2014 01:13 PM

Linux Mint(s) have a ntp time issue
 
.. apparently..
I have earlier sought help in the Linux-Server section on using ntp, and found help from michaelk.

I have discovered that on boot-up, and possibly also at regular intervals, the system actually resets the Hardware Clock. This might be a well meaning use of ntp that has gone wrong. We use, for reference, an MSF time standard signal radio controlled clock.

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

Checking, with a new restart, we find the CMOS Hardware Clock has indeed been suddenly advanced by the unwanted 2 seconds.

We can reset the system time various ways, such via the Date Display --> Preferences, (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 OK that Linux Mint should so insist on using the wrong time, and it makes the use of time-critical application programs impossible.

This situation seems to be so, for both Linux Mint 14, and a new Linux Mint 17 installation. The question is, of course, how can we fix it? My thanks to any who can help.

P.S. On advice from michaelk, we are now going to verify the MSF radio clock. Probably a good GPS satnav would also be OK. I am so much hoping that the MFS clock is wrong!

notKlaatu 06-29-2014 05:51 AM

You should probably file a bug on this here https://bugs.launchpad.net/linuxmint

GTrax 06-30-2014 04:24 AM

Quote:

Originally Posted by notKlaatu (Post 5195771)
You should probably file a bug on this here https://bugs.launchpad.net/linuxmint

Not a chance notKlaatu - at least not yet! I am too cautious of being misled by electronic kit, especially the lower cost variety, and the whole reason I posted all this is because deep down, I trust the computer clock more. I just could not believe this could be true.

Also, I noted that the Android clock (on a smartphone) seemed to be about 1 second out of step with the Mint - not 2 seconds! A tracking app on the phone reported this offset as 1.17seconds.

The basic nature of the self-resetting radio clocks locked to atomic clocks is they are phenomenally accurate when they work properly. It is when you put two side by side, and see a difference that confidence is shaken.

---------

P.S. I have now had opportunity to check using a new Auriol radio controlled time standard. This one uses the DST broadcast from Frankfurt, which has a 1500km range. Thankfully it appears 2 seconds ahead of the science clock, and in step with Mint. The place that requires the bug report just might be the Science Museum in London, which sold the MSF time standard clock with a certificate!

turtlebay777 07-05-2014 06:37 PM

Wow, I've finally found someone who's bothered about being one or two seconds adrift. I thought NASA were being extreme when they insisted their clocks had to be accurate to +/- ten seconds!

GTrax 07-06-2014 04:49 PM

Quote:

Originally Posted by turtlebay777 (Post 5199254)
I thought NASA were being extreme when they insisted their clocks had to be accurate to +/- ten seconds!

Yes - This is more closely related to NASA than I thought to mention.
The usual need for network transfers in a pile of high traffic is to get within 128mS.
Getting the time from network time servers can get the clock within a few milliseconds.

My need is different. Machinery can be synchronized to move with millisecond accurate timing, and register shaft position angles within fractional arc-seconds. If the machinery is pointing antennas at moving satellites, you then have to raise the game to a whole new level, because now you have to make it happen at an exact celestial time counted forward from a "epoch" related to a the number of microseconds after various "Truncated Julian Dates" from back in 1950, 1970, etc.

Latitude is still, as it always was, a matter of knowing the right time. It is when the stuff is not attached to Earth that it gets difficult. The Earth is slowing down, and it wobbles its axis, and that wobble itself has a "wobble". The Moon pulls things about, and the Earth centre of mass is not in the centre, and the Earth is not a sphere. The NASA published algorithms have to be used with care, and the input information updated daily, or hourly.

Time is controlled in layers.
NIST-F1 The Cesium Fountain Atomic Clock - 3 parts in 10^16
Less than 1 second in 100 million years, aiming to get 1 second in 300 million years
It is run several times a year to set hundreds of "lesser" atomic standards.
These are used to set network time servers, again in "levels"

"Unix Time" counts from 0h 0m 0S Jan1, 1970. For this work, we will only trust a Linux PC running ntp.


All times are GMT -5. The time now is 01:19 PM.