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?
Running ntpd on linux as an ntp server and automachron on windoze to keep their clock in sync.
At my school, a time server is set up to keep the computers on the network within a certain range of time. I believe the purpose of this is for security, as we can't renew our kerberos tickets if our time is more than X minutes from the server's specified time.
-agent oranje.
Some VCRs including my JVC can get a time signal that is broadcasted by PBS stations via cable. It's wonderful to never have to set that puppy.Combined with ntp for my computers, and WWV for my stand alone clocks (so called 'atomic alarm clocks' I am down to one clock that I have to set - my wristwatch.
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...
..that the Microsoft time server was 3 minutes slow ! This was about 2 weeks ago. I checked it against both another time server, and then the UK speaking clock (dial 123 in the UK) which is synchronised with Greenwich. As a result, I disabled the time synch (right click on the time in the system tray, Adjust Date Time, Internet tab, uncheck the box). I now use the time synchronisation feature that comes with the Dynip client. :(
Since the MS time synch is enabled by default, they really should make sure their server farm has the correct time
Never, ever lose a file again. Ever.
Just yesterday at work I was talking with a researcher about this.. he was showing me an NTP server he made, using two DGPS units and some embedded ethernet controllers.. he said the accuracy on it was about 40 nanoseconds from UTC..
:)
That should probably be suitable I think
http://truetime.net sells some rack GPS-based NTP Servers too.. but I don' know the price.
I look briefly at the time when I set up my computer, ensure that it's within the proper range of "It's light out" or "It's dark out" and leave it be.
:p
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
Right now I'm doing research in very high precision time synchronization for very large numbers of very small things. My lab 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 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, including
- "Fine Grained Network Time Sync using Reference Broadcasts" -- the original RBS paper
- "Wireless Sensor Networks: A New Regime for time synchronization" -- my argument as to why NTP shouldn't be used for sensor networks
- "Locating nodes in time and space: A case study" -- description of our testbed that is capable of localizing objects down to 1cm by measuring time of flight of sound, combined with RBS time sync.
It's funny, I'm sitting in the lab right now, tinkering with the testbed when this article should come up.NT 4 had time synchronization, but it came front and center with Windows 2000 (which automatically time sync with your domain controller, which itself should be configured to sync with a master authority) because of Kerberos as implemented in Windows 2000 and beyond : Time is one of the parameters, so if Bob's PC is 20 minutes ahead and his kerberos keys are by a different clock, security conflicts will arise (namely, his keys will be refused). Of course, anyone with XP can bring up the clock applet (double clicking on the clock in the system tray) and choose the Internet Time tab that allows them to change the server to a different one if they so desired (or disable it all together).
It's just like a 'level' of how many machines you've gone through.
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.
There's latency, and then there's relativity. When the server receives the time request, it takes the current timestamp and puts it in a network packet, which then trickles down the wire to the client. The client receives the packet and then knows what time it was at the server. That's latency. If you're NTP'ing over a dial-up connection from a distant server, the latency can be a second or more in worst cases. (NTP may have features to compensate for this; I couldn't say.)
;-)
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.
It gets the signal from wwvb in colorado, which broadcasts the time on 60khz encoded in bcd using some odd modulation scheme. wwvb time is very accurate, at the trasmitter i think the accuracy is within a picosecond. If you know your location you can calculate the time it takes the signal to reach you from the transmitter, and get your time as accurate as the clock at the transmitter. WWVB is run by NIST. They also run two other radio stations, wwv and wwvh. WWV broadcasts from the same site in colorado that WWVB broadcasts from, but broadcasts a voice signal of the time, a pulse every second, as well as bcd and several other things. WWV broadacts on 2.5, 5, 10, 15, and 20 MHz. WWVH broadcasrs the same thing as WWV but is located in hawai, has a female voice instead of the male voice that WWV has, and doesnt broadcast on 20mhz. WWV rocks.
-- free as in swatantryam - not soujanyam.
Another point is that it's unnecessary to update more often than daily except for the most exacting situations. Do you really need to keep your clocks synchronized to within milliseconds? I've found daily updates against a time server (which is sync'd to my ISP's NTP source) via a cron job running 'rdate' is good enough to keep my systems synced to within a second.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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