Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
News

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?
This discussion has been archived. No new comments can be posted.

Do You Have The Time?

Comments Filter:
  • by shoppa ( 464619 ) on Thursday July 04, 2002 @06:10PM (#3823976)
    1. Roofmounted Trimble SVeeSix-CM3 GPS receiver with microsecond-accurate pulse-per-second output: $24.95 [bgmicro.com].
    2. Network Time Protocol synchronization software: Free [udel.edu]
  • ntp/sntp (Score:1, Interesting)

    by Anonymous Coward on Thursday July 04, 2002 @06:10PM (#3823978)
    Running ntpd on linux as an ntp server and automachron on windoze to keep their clock in sync.
  • School server time (Score:2, Interesting)

    by agent oranje ( 169160 ) on Thursday July 04, 2002 @06:12PM (#3823983) Journal
    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.
  • Time for my VCR (Score:5, Interesting)

    by the eric conspiracy ( 20178 ) on Thursday July 04, 2002 @06:14PM (#3823990)
    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.

  • by angio ( 33504 ) on Thursday July 04, 2002 @06:18PM (#3824014) Homepage
    As part of the Resilient Overlay Networks [mit.edu] project at MIT, I maintain a testbed of about 20 nodes, most of which have GPS-based time synchronization. We've started using a really fun little box from EndRun Technologies [endruntechnologies.com] called the Praecis Ct. It gets GPS time that's being rebroadcast by cellular CDMA base stations. They provide accuracy to about 10 microseconds, and don't require a roof antenna -- anywhere you can get CDMA cellular service, you can use these things. They're kind of pricey (about $1k), but they're completely easy to use and set up. For more general information about NTP and things, see ntp.org [ntp.org], which mtaintains a nice FAQ about things-ntp.

    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)

    by IanBevan ( 213109 ) on Thursday July 04, 2002 @06:18PM (#3824016) Homepage
    ..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 [dynip.com] client.
    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)

    by Mr. Sketch ( 111112 ) <<moc.liamg> <ta> <hcteks.retsim>> on Thursday July 04, 2002 @06:19PM (#3824017)
    I am down to one clock that I have to set - my wristwatch.

    Not if you had one of these [thinkgeek.com].
  • Coincidence (Score:3, Interesting)

    by Large Green Mallard ( 31462 ) <lgm@theducks.org> on Thursday July 04, 2002 @07:00PM (#3824157) Homepage
    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.
  • by neuroticia ( 557805 ) <neuroticia AT yahoo DOT com> on Thursday July 04, 2002 @07:03PM (#3824166) Journal
    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.

    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? :p

    -Sara
  • by jelson ( 144412 ) on Thursday July 04, 2002 @07:59PM (#3824318) Homepage
    Wow, who would have thought that the topic of my PhD thesis would be on the front page?

    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
    • "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.

  • Re:What about (Score:2, Interesting)

    by ergo98 ( 9391 ) on Thursday July 04, 2002 @08:15PM (#3824371) Homepage Journal
    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 [winntmag.com] : 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 [nist.gov] if they so desired (or disable it all together).
  • Re:Don't Do That (Score:1, Interesting)

    by Anonymous Coward on Thursday July 04, 2002 @08:51PM (#3824495)
    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.
  • by foobar104 ( 206452 ) on Thursday July 04, 2002 @09:13PM (#3824556) Journal
    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. ;-)
  • Re:Atomic Wall Clock (Score:3, Interesting)

    by Phork ( 74706 ) on Thursday July 04, 2002 @10:42PM (#3824747) Homepage
    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.
  • by coyote-san ( 38515 ) on Thursday July 04, 2002 @11:23PM (#3824990)
    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.
  • by Sheridan ( 11610 ) on Friday July 05, 2002 @05:27AM (#3826280) Homepage
    NB. Microsoft hasn't exactly been RFC compliant in their NTP server/client interactions.

    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]

"Engineering without management is art." -- Jeff Johnson

Working...