Do You Have The Time? 451
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?
Microsecond accuracy for $25 (Score:5, Interesting)
ntp/sntp (Score:1, Interesting)
School server time (Score:2, Interesting)
Time for my VCR (Score:5, Interesting)
Maintaining a medium-size net of clocks (Score:5, Interesting)
For a few of the european hosts, we use GPS time receivers, primarily the Motorolla Oncore UT+ kits. You can get eval units of these, google around. They're nearly as easy to use, but do require a kernel config change.
It's really kind of addictive playing with time. :-) And you get spoiled by never having any clock weirdness on any of your machines...
I found... (Score:5, Interesting)
Since the MS time synch is enabled by default, they really should make sure their server farm has the correct time
Re:Time for my VCR (Score:5, Interesting)
Not if you had one of these [thinkgeek.com].
Coincidence (Score:3, Interesting)
That should probably be suitable I think
http://truetime.net sells some rack GPS-based NTP Servers too.. but I don' know the price.
Re:How do I get the time? (Score:2, Interesting)
Late for a meeting? "Oh my god! The clock on my PC was wrong! Damned XP time-synch decided I was in Hungary.
Seriously, though, I prefer setting the time myself from my watch or from the microwave in the lounge, or from calling out to a co-worker "Hey Sam! Got the time?"
I just feel odd about letting *anything* remote change any setting on my computer, even if it's just the time. ESPECIALLY if I'm on Windows. I mean... How long before there's a clock-virus?
-Sara
Or, if you need something even better than NTP... (Score:5, Interesting)
Right now I'm doing research in very high precision time synchronization for very large numbers of very small things. My lab [ucla.edu] does work in sensor networks -- get a tiny little computer with a few sensors and a radio, sprinkle thousands of them out over a building or a battlefield or a forest. Have the network tell you where the fire started, where the enemy is lurking, which light bulb needs to be replaced, or a thousand other things.
You need very time sync to do lots of this stuff -- to track motion, for example. Our current testbed times the flight of sound to tell how far apart things are, and for that we need accuracy on the order of 10 microseconds between clocks.
My research right now centers around a new time sync scheme, called Reference Broadcast Synchronization, which in a recent study [ucla.edu] I showed is almost an order of magnitude more precise than NTP under the same conditions -- 5 microseconds between a group of nodes with a userspace implementation, and down to 1 microsecond in the in-kernel implementation (which is the resolution of the clock! I'll do better when I have a clock that ticks more than once a microsecond.)
NTP, even under "optimal" conditions -- very high query rate to a stratum 1 GPS-steered clock in our lab--- did no better than 50 microseconds. When we introduced high levels of congestion on the network, NTP degraded by a factor of 30 while RBS was almost unchanged.
Of course, NTP is still a fantastic protocol, and much better than trying to apply RBS to the Internet (which is basically impossible). But for tiny nodes that need very tight time sync, I say, we can do better
Some recent papers you might like are here [ucla.edu], including
Re:What about (Score:2, Interesting)
Re:Don't Do That (Score:1, Interesting)
A stratum 1 server gets its time directly off a cesium clock (or some other high-precision timekeeper). A stratum 2 server gets its time updates from a stratum 1 server.
Obviously, an S1 server should never get it's time from an S2 server, which is the reason for that error message... 'that' machine has a lower (ie: less accurate) stratum setting than 'this' machine.
Re:[SC0RE: -1, Microserf] (Score:5, Interesting)
Relativity affects the rate at which time runs for two observers in different inertial frames. It doesn't affect synchronization directly; if you ignore or compensate for latency, you can synchronize two clocks in different reference frames. But the clocks will start to drift apart immediately due to the different rates at which time passes in the two frames.
Now here's the cool thing. According to general relativity-- actually, according to my vague recollection of general relativity from a college semester more than ten years ago-- gravity affects the rate at which time passes in a reference frame. In other words, time runs more quickly in a high gravity field relative to a lower gravity field.
It's pretty well known that the local force of gravity varies measurably over the Earth's surface. Depending on where you are, the local force of gravity may be higher or lower.
So if you wanna get accurate, pick an NTP server in a region with a similar local G to yours.
HHOS.
Re:Atomic Wall Clock (Score:3, Interesting)
Related: update daily (Score:3, Interesting)
The other nice thing about this aproach is that it's easy to toss the Windows equivalence of 'rdate' into the startup scripts managed by Samba, so whenever a Windows box comes onto the network it's also synced.
Re:Is this an XP thing? (Score:4, Interesting)
If you do a Google groups search for "NTP XP Mills" you'll find a host of articles detailing exactly what David L. Mills (Author of ntpd and the RFC1305) thinks of Microsoft's (intentionally?) b0rken implementation of NTP in WinXP this is one example [google.com]