Atomic Clock

[ndujoe1]

I inquired about a Linux version of the atomic clock, this is the response I got back from the government agency:

> Any consideration given to issuing a Linux version of your software?

Linux already has several time clients that come with the distribution.
Look at NTP, the Network Time Protocol and RDATE, which is a simpler and
less robust client. Both of these are usually part of most versions of
Linux and either of them can be used with our time servers.
We also have source code that you can use to build a simple time
client for most versions of Unix and Linux. You can get this source
code using ftp to any of our servers. For example, go to:

ftp://time-a.nist.gov/pub/daytime

and look at the files there. You can build a simple time client called
nistime by copying tcp_time_client.c, sw.c and the Makefile. The source
code for a number of other time clients is also located in this directory.
Look at the read-me files for details.

Judah Levine
Time and Frequency Division
NIST Boulder

[Pizzasgood]

Puppy has rdate already. To check the time (without setting it):
rdate -p time-a.nist.gov
To set the time:
rdate -s time-a.nist.gov

That doesn't save it back to the hardware clock. If you want to do that, run this afterward:
hwclock --systohc --localtime
(if you have the HW clock set to UTC time like me, then you'd replace --localtime with --utc - be aware that you must also track down all the calls to hwclock that Puppy makes and modify them appropriately, or else Puppy will do weird time-traveling tricks)


That's just one server. There are many. Google if you want another.


Attached is a basic program that will look at a list of servers in /etc/timeservers and try each one until it finds one that works (in case they are offline for whatever reason), then it will use that one and update both the software and hardware clocks (using localtime - modify /usr/sbin/timesync if you want to change it to utc). It will also store the address of the server, so that next time it runs it doesn't have to search unless that specific server goes down. You can run it with the command timesync or by clicking the menu entry in "Menu->Desktop->Synchronize clock with time-server". Warning: this gives you no opportunity to change your mind once you run it.

It also adds the file /etc/init.d/timesync_auto, set to non-executable. If you change it to be executable, then each time Puppy boots it will attempt to synchronize the time (by running timesync -q where the -q option suppresses the graphical notification). To disable it again, just set it non-executable.

Set executable:
chmod 755 /etc/init.d/timesync_auto
Set non-executable:
chmod 644 /etc/init.d/timesync_auto

Or you can right-click and go to 'File -> Properties' or the slightly less intuitive 'File -> Permissions'.

[alienjeff]

That's just one server. There are many.

http://tf.nist.gov/tf-cgi/servers.cgi

[SirDuncan]

I just have this alias set in my .bashrc file,
alias set_time='rdate -s nist1-dc.WiTime.net;hwclock --systohc --localtime;rdate -p nist1-dc.WiTime.net'.
WiTIme is in Virginia, which is slightly closer to me than time-a.nist.gov's Maryland location (probably doesn't make any actual difference in speed). Pizzasgood's script is more feature packed, but I only set my time about once a year, so this simple alias works fine for me.

[Colonel Panic]

Good info, thanks all! I've just used this to reset my system clock (and will use it again in the future).

Cheers,

CP .

[Flash]

time.gov - NIST time <- Just click the link for the atomically correct time.

[Colonel Panic]

time.gov - NIST time <- Just click the link for the atomically correct time.

Thanks for that one. I once tried filling an exercise book with all the Linux commands I'd need (with the commonest options I use) but the book fell to pieces Time and date commands are definitely amongst them though.

[Moose On The Loose]

I inquired about a Linux version of the atomic clock, this is the response I got back from the government agency:

Slightly off topic but worth pointing out:

The nice folks at NIST provide what makes this work.

Code: Select all

#!/bin/bash
cat </dev/tcp/time.nist.gov/13

In some applications, a GPS connected to your computer can give you a quite accurate time. The trick is the kludge together something that makes the GPS's 1PPS pulse into something like an RS232 signal that you can get the interrupt for. The interrupt records the system time of the pulse and the non-interrupt code tunes the system clock to stay right on the mark.

I run a more graphically compact version of psync of my own creation. If you are running puppy on something with a small screen, you may like to give it a try. It has some added features like popping up in case of trouble and giving reasonable attempts at diagnosis messages.

[Flash]

GPS time should be accurate to something on the order of nanoseconds. It's that accurate time signal that makes GPS so accurate.

[Moose On The Loose]

GPS time should be accurate to something on the order of nanoseconds. It's that accurate time signal that makes GPS so accurate.

Inside the GPS, the time is really good. The RS-232 output delays from the time of the fix and hence carries a time from the past and since the formatting takes a varying time, the delay varies.

The 1PPS that a GPS outputs is usually good to a microsecond. Over long times it averages to exactly 1Hz but a given pulse time can wobble about quite a bit.

Many GPS models don't output the 1PPS if they loose the signal briefly. Thus if you want to use the 1PPS, it is best to phase lock a local clock onto the 1PPS and contrive the servo so that it interpolates through a missed pulse.

Some GPS models will from time to time skip producing a fix or delay the fix an unusually long time. The code you use should deal with outliers.