Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time.is

time.is

Post reply on HN
Print view View original

31–40 of 108 posts

Re: Time.is

#31

Post by ComputerGuru »

mwexler wrote: post #14

I like Time.gov, personally; it was the first site I ever found around this concept and so it has a soft spot. I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ…

The answer to your question is GPS devices. They're supposed to take into account (most of) what you mentioned, and even though consumer GPS devices are fairly cheap and not up to industrial or even military GPS, time is one thing they do right. In fact, for several projects that needed a reliable time source instead of using the (as you noticed) poorly implemented atomic clock radio frequencies, we would just buy GPS chips to just extract the time signal.

I simply don't have any clocks that aren't part of electronic devices, my wristwatch being the exception (but it's analog (Roman numerals, even :P) and only has second accuracy anyway, so I don't fuss about it).

Simply put, all my devices take care of all this for me. My MacBook and Windows 7 work desktop are both configured to sync to the Apple NTP servers (lowest ping for me, AND they're always up. Microsoft's are down a good 10% of the time in my experience). My cell phone gets its signal from God knows where (iPhone 4S - it could technically be using one of 4 different sources) but is always more or less in sync with the rest (I just checked with time.is for what little that is worth, however, and while my MacBook says that my time is within the margin of error "The difference from Time.is was -0.007 seconds (±0.018 seconds).", my iPhone returns "Your clock is 0.5 seconds slow" - but I would trust my iPhone's NTP implementation over time.is' response as its the same OS X NTP that got it "right" on my MacBook) as it can theoretically use a) GPS b) GSM/CDMA towers c) NTP d) time from PC sync.

All my other electronic devices fall in the same category. Garmin nüvi (GPS), Kindle (NTP, auto configured), Cisco IP Phone (NTP, manually configured), Brother printer (NTP, manually configured). I purposely do not set my microwave clock because a) I'll never get it right, and b) any time the power cuts, it resets and in 2012 they're still too stupid to add a 5 cent battery to keep the time in case of power outage.

Re: Time.is

#32

Post by dfc »

mwexler wrote: post #14

I like Time.gov, personally; it was the first site I ever found around this concept and so it has a soft spot. I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ…

Radio controlled clocks are subject to numerous sources of error. However two seconds is pretty bad, according to NIST the RCC "should always be accurate to within one second of UTC, assuming that they synchronize at least every other day and that their quartz oscillator is of reasonable quality." How far do you live from Fort Collins, CO? I have included some WWVB references at the end...

My GPS + Pulse Per Second fed ntp server is remarkably better than a radio controlled clock. The Sure GPS evaluation board probably costs less than your radio controlled clock:)

  dfc@ronin:~$ ntpq -p 
       remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
  oGPS_NMEA(0)     .GPS.            0 l   12   16  377    0.000    0.001   0.001
   bonehed.lcs.mit .CDMA.           1 u   32   64  377   51.365    0.670   0.364
   rooster.stonybr .CDMA.           1 u   14   64  377   49.019    6.141   0.445
   navobs1.oar.net .USNO.           1 u    1   64  377   57.310    9.494   0.456
   meg.ee.lbl.gov  .PPS.            1 u    1   64  377   88.639   -2.204   0.270
  dfc@ronin:~$ ntptime
  ntp_gettime() returns code 0 (OK)
    time d3076554.79d48450  Sun, Mar 11 2012 13:54:28.475, (.475899416),
    maximum error 234 us, estimated error 0 us, TAI offset 34
  ntp_adjtime() returns code 0 (OK)
    modes 0x0 (),
    offset 0.856 us, frequency -32.941 ppm, interval 1 s,
    maximum error 234 us, estimated error 0 us,
    status 0x2001 (PLL,NANO),
    time constant 4, precision 0.001 us, tolerance 500 ppm,
Radio clock reference material:

NIST Page on Radio clocks: http://www.nist.gov/pml/div688/grp40/radioclocks.cfm

"How accurate is a radio controlled clock" http://tf.nist.gov/general/pdf/2429.pdf

"WWVB Radio Controlled Clocks: Recommended Practices for Manufacturers and Consumers": http://tf.nist.gov/timefreq/general/pdf/2422.pdf.

Re: Time.is

#33

Post by mdda »

For those alarmed at the offset...

# yum install ntpdate

# ntpdate -u ntp-1.vt.edu

# hwclock -w

"Your time is exact!"

Re: Time.is

#34

Post by guylhem »

I like it a lot. Easy to remember URL. However the services offered are not so good.

At least there is no RFC 867 and RFC 868 date on port 37 and port 13.

This is deprecated, I know, but rdate is still the easiest way to fix the date on a system which do not require precision. I did run my own minimal daemon on my DSL modem for the various gizmos I have that include busybox (thus rdate) and where recompiling to get a ntp would be overkill. (the right day and the right hour are more than enough)

time.nist.gov removed RFC 867 (port 13) and 868 (port 27) support. time-nw.nist.gov kept it a bit longer, then I used by DSL modem, which went in RMA and so guylhem.org is also down.

I'll try to email the author and offer to give a hand.

Re: Time.is

#35

Post by lukeschlather »

dfc wrote: post #32
mwexler wrote: post #14

I like Time.gov, personally; it was the first site I ever found around this concept and so it has a soft spot. I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ…

Radio controlled clocks are subject to numerous sources of error. However two seconds is pretty bad, according to NIST the RCC "should always be accurate to within one second of UTC, assuming that they synchronize at least every other day and that their quartz oscillator is of reasonable quality." How far do you live from Fort Collins, CO? I have included some WWVB references at the end... My GPS + Pulse Per Second f…

>"physical atomic clock"

Are you trolling or did you really miss the whole phrase "physical atomic clock synced clocks?"

Re: Time.is

#36

Post by gwern » 

    Your clock is 0.2 seconds slow.
    Accuracy of synchronization was ±0.625 seconds
If the result is within the margin of error, wouldn't it be better to just not tell me at all?

Re: Time.is

#37

Post by dfc »

ComputerGuru wrote: post #31
mwexler wrote: post #14

I like Time.gov, personally; it was the first site I ever found around this concept and so it has a soft spot. I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ…

The answer to your question is GPS devices. They're supposed to take into account (most of) what you mentioned, and even though consumer GPS devices are fairly cheap and not up to industrial or even military GPS, time is one thing they do right. In fact, for several projects that needed a reliable time source instead of using the (as you noticed) poorly implemented atomic clock radio frequencies, we would just buy GP…

NTP does a lot more than what you theorized about and none of it is trivial.

FYI: Ping is a remarkably bad tool to gauge the accuracy of remote time source. What is the delay value from "ntpq -p"

I highly doubt that Apple's time servers are your best bet for time synch. Use the pool.ntp.org servers, preferabbly with your country code: e.g. us.pool.ntp.org, ca.pool.ntp.org.

Re: Time.is

#38

Post by dfc »

lukeschlather wrote: post #35
dfc wrote: post #32

Earlier quoted context omitted.

Radio controlled clocks are subject to numerous sources of error. However two seconds is pretty bad, according to NIST the RCC "should always be accurate to within one second of UTC, assuming that they synchronize at least every other day and that their quartz oscillator is of reasonable quality." How far do you live from Fort Collins, CO? I have included some WWVB references at the end... My GPS + Pulse Per Second f…

>"physical atomic clock" Are you trolling or did you really miss the whole phrase "physical atomic clock synced clocks?"

I apologize. I will edit my post. I did not see the synched the originally and/or his post was edited.

Re: Time.is

#39

Post by morsch »

mdda wrote: post #33

For those alarmed at the offset... # yum install ntpdate # ntpdate -u ntp-1.vt.edu # hwclock -w "Your time is exact!"

This is an unobtrusive app that does the job for Android (root required/recommended): https://play.google.com/store/apps/details?id=ru.org.amip.Cl...

My ZTE Blade/CM7 was obnoxiously bad at keeping time, probably a software bug or something.

Re: Time.is

#40

Post by moe »

Reminds me of the radio clock that I have in the bathroom.

It is labeled "DCF signal - precision time", yet is off by hours most of the time (jumps randomly).

I keep it for the entertainment value. Guests always have a good chuckle when they enter the bathroom at 16:41 and leave it at 23:41.

Post reply on HN