Slashdot Mirror
Do You Have The Time?
RetroGeek writes: "This ZDNet article talks about the perils of the PC clock. And (something I did not know) that Windows XP and Mac OS X both automatically get a time stamp from MicroSoft and Apple respectively. At any rate, my home firewall gets the time every hour from the NIST servers, then each of the machines on my LAN query the time server daemon on the firewall. That way all my home network machines have the same time. And latency on the LAN is next to zero. Now if I can only get my VCR connected. Anyone else running a time server?" So how do you get the time?
Consider running a proper NTP daemon instead.
:)
It has the advantage of not jerking your clock around every time you sync. It makes calculated "smooth" adjustments to keep your clock accurate. It can also use multiple servers.
It's the difference between a perfectly-ticking clock, and one that gets manually reset twice a day to make it (temporarily) accurate.
The biggest impact this will have is if you do file access across the network or need your timestamps to be reliable. Depending on how much your clock drifts, that ntpdate adjustment could back up several seconds. This can wreck havok on timestamp-dependent things, like "make".
Most ntpd distributions make this easier to set up than a crontab entry anyway.
If you're on cable or DSL, most of the upstream routers run proper NTP servers, and they're just a hop away. The bandwidth for running an NTP client is minimal.
To find the nearest NTP server, to a traceroute to a few non-local hosts. Then start at your nearest router and ping each one for a time server using something like 'ntptrace'.
Near-perfect accuracy, just a trickle of data, and your provider will thank you for using nearby machinery.
On your Red Hat Linux server/firewall/whatever (easily adapted to any NTP setup, really):
/etc/ntp/drift /var/run/ntpd.pid /var/log/ntpd
/etc/ntp/step-tickers has the IP addresses for those hosts, all one line (the Red Hat startup script uses these to set the clock at boot, in case it's WAY out of sync.):
ntp.conf:
server time.apple.com
server tick.usno.navy.mil
server tock.usno.navy.mil
# In case the network is down
server 127.127.1.0
fudge 127.127.1.0 stratum 10
broadcastdelay 0.008
authenticate no
driftfile
pidfile
logfile
and
17.254.0.27 192.5.41.40 192.5.41.41 17.254.0.26 17.254.0.31
Then on your LAN, have all your other machines use this machine as the time server. That's it! Never set a clock again.
It's important to have accurate time for many protocols, including HTTP, and also to timestamp your logs accurately for forensics and evidence.
For even more accurate and secure local timeservers, run a GPS antenna to your roof and buy one of these products.
"...my home firewall gets the time every hour from the NIST servers,..."
Don't use stratum one servers for your home network. It's wasteful and unnecessary. Use a stratum 2 or higher server or your ISP's server.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
- time.windows.com
- time.nist.gov
Take a wild guess which one I chose...But if you want more choices than that:
This allowed me to set my own choice of NTP server, and then synced from it. Like many other MS 'features', theThis article inspired me to do some dumpster-diving in the Registry... Import this key/value:
default can be changed, if you know how...
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
The GPS output signals are CMOS/TTL level, not RS-232, so I put them through an MAX 232converter before they come out of the box on the roof and run downstairs to the PC. This is not exotic stuff; TTL to RS-232 converters are pretty much 30 year old technology.
The protocol is just plain async serial, so no special electronics to encode/decode.
the key won't affect the next, but the one after that will read this value to determine the time
for the one after that.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
It was right. The GPS time epoch is 0000 UT on 6-Jan-1980. Since then UTC has had 13 leap seconds inserted. This offset is available in the NAV message; maybe the version of NTP you used was ignoring that message or maybe that particular GPS receiver didn't implement that message. (Actually, buggy firmware in GPS receivers has been a problem in the past.)