System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by AES » Fri, 08 Jul 2011 23:42:10



Re mysterious computer time glitches, and the NERC 60 Hz story:



Quote:> There may have been a telephone based service where you got clock pulses
> from the atomic clock (I think there is only one in the country that is
> available to civilians), but those days are long gone.

Just for the record, a few days ago I found in a drawer one of those
Oregon Scientific battery-powered weather gadgets with a couple of
remote temperature gauges.  Changed the batteries, set it on a shelf in
my office, within a day or so it had accurately self-synched it's date
and time to somebody's broadcasts out of the ether .  (Except it won't
and I can't push its Year beyond 2004;  it had been in that drawer for a
while.)
 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by John Meisse » Sat, 09 Jul 2011 07:47:23






> > There may have been a telephone based service where you got clock pulses
> > from the atomic clock (I think there is only one in the country that is
> > available to civilians), but those days are long gone.

> Just for the record, a few days ago I found in a drawer one of those
> Oregon Scientific battery-powered weather gadgets with a couple of
> remote temperature gauges.  Changed the batteries, set it on a shelf in
> my office, within a day or so it had accurately self-synched it's date
> and time to somebody's broadcasts out of the ether .  (Except it won't
> and I can't push its Year beyond 2004;  it had been in that drawer for a
> while.)

Probably just monitors WWV's transmission:
 http://www.nist.gov/pml/div688/grp40/wwv.cfm

I've slowly been replacing all of the clocks in my house with ones that
set themselves.  It was interesting to see which ones failed when they changed
the DST dates because they had hard-coded them. There's no reason to
hard-code it because the DST status is part of the data stream.

***** Moderator's Note *****

Please tell us which ones were able to handle the DST change.

Bill Horne
Moderator

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Adam H. Kerma » Sat, 09 Jul 2011 14:34:16



>Just for the record, a few days ago I found in a drawer one of those
>Oregon Scientific battery-powered weather gadgets with a couple of
>remote temperature gauges.  Changed the batteries, set it on a shelf in
>my office, within a day or so it had accurately self-synched it's date
>and time to somebody's broadcasts out of the ether .  (Except it won't
>and I can't push its Year beyond 2004;  it had been in that drawer for a
>while.)

Same pattern as 1994 on the perpetual calendar.
 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Robert Bono » Sat, 09 Jul 2011 09:26:19




Quote:

> There may have been a telephone based service where you got clock pulses
> from the atomic clock (I think there is only one in the country that is
> available to civilians), but those days are long gone.

There were, and are, _at_least_two_.  One from NIST, with a Colorado number,
in the Boulder area, IIRC.  A second from the U.S. Naval Observatory, in
*ia, as I recall, but it is an area-code 202 number.

There _may_ be modem access to WWVH, I'm not sure -- there _is_ telephone
access to the =voice= time there, in addition to the WWV voice channel
in Colorado.

The NIST facility is _amazingly_ accurate.  They have 'smarts' on the
server end that measure the round-trip latency to the user, and advance
the 'tick' so that it _arrives_ at the user's location at the proper
instant.  With quality software, one can set the system clock with sub-
millisecond accuracy.  If memory serves, the 'jitter' is around 15 _micro-
second_.

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by tlvp » Sat, 09 Jul 2011 07:30:33



> Re mysterious computer time glitches, and the NERC 60 Hz story:



>> There may have been a telephone based service where you got clock pulses
>> from the atomic clock (I think there is only one in the country that is
>> available to civilians), but those days are long gone.

> Just for the record, a few days ago I found in a drawer one of those
> Oregon Scientific battery-powered weather gadgets with a couple of
> remote temperature gauges.  Changed the batteries, set it on a shelf in
> my office, within a day or so it had accurately self-synched it's date
> and time to somebody's broadcasts out of the ether .  (Except it won't
> and I can't push its Year beyond 2004;  it had been in that drawer for a
> while.)

Following the example of the y2k shenanigans I had to invent to retain the
usefulness of an AT&T-branded "Computer telephone 8130" (nominated 'Computer
Telephony Product of the Year' the year it came out late last century), you
can get month, day, and date to come out just fine if you adjust the *year*
to exactly 28 years ago -- not 2011 (which it won't do, you report), but
1983.

(Or won't it accept 1983, either? The old 8130 happily accepted 1972 in
2000.)

HTH. And cheers, -- tlvp (who's *still* wondering how that 8130 could
have been Product of the Year one year, and a sacrificial y2k victim a
few years later, as AT&T had no firmware update prepared for it.)

--
Avant de repondre, jeter la poubelle, SVP

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Wes Leatheroc » Sun, 10 Jul 2011 09:41:52



      [ ... ]

Quote:> The NIST facility is _amazingly_ accurate.  They have 'smarts' on
> the server end that measure the round-trip latency to the user, and
> advance the 'tick' so that it _arrives_ at the user's location at
> the proper instant.  With quality software, one can set the system
> clock with sub- millisecond accuracy.  If memory serves, the
> 'jitter' is around 15 _micro- second_.

     This must be the one that you reach at www.time.gov.  When you
click on your time zone it tells you to wait, which appears to be
while it is measuring the round trip latency.  Then in a few seconds
the digital time (hours, minutes, seconds) appears in the box.

     If it doesn't want to come up at www.time.gov there is also a
button to click at www.nist.gov, which brings up the same page.

     The is also a timing pulse in the interstitial information on PBS
stations, as the instructions on video recorders often spell out in
detail.

Wes Leatherock


 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by AES » Sun, 10 Jul 2011 02:33:53




> > Just for the record, a few days ago I found in a drawer one of those
> > Oregon Scientific battery-powered weather gadgets with a couple of
> > remote temperature gauges.  Changed the batteries, set it on a shelf in
> > my office, within a day or so it had accurately self-synched it's date
> > and time to somebody's broadcasts out of the ether .  (Except it won't
> > and I can't push its Year beyond 2004;  it had been in that drawer for a
> > while.)

> Following the example of the y2k shenanigans I had to invent to retain the
> usefulness of an AT&T-branded "Computer telephone 8130" (nominated 'Computer
> Telephony Product of the Year' the year it came out late last century), you
> can get month, day, and date to come out just fine if you adjust the *year*
> to exactly 28 years ago -- not 2011 (which it won't do, you report), but
> 1983.

> (Or won't it accept 1983, either? The old 8130 happily accepted 1972 in
> 2000.)

My error:  It now seems to have auto-set everything, including the year,
correctly.   (Model number is BAR618HGA)
 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Peter R Coo » Sun, 10 Jul 2011 06:08:14




>The NIST facility is _amazingly_ accurate.  They have 'smarts' on the
>server end that measure the round-trip latency to the user, and
>advance the 'tick' so that it _arrives_ at the user's location at the
>proper instant.  With quality software, one can set the system clock
>with sub- millisecond accuracy.  If memory serves, the 'jitter' is
>around 15 _micro- second_.

This is a standard feature designed into the NTP protocol. It uses
Marzullo's algorithm to determine the round trip delay.

--
Peter R Cook

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Gary » Sun, 10 Jul 2011 01:13:26



> Probably just monitors WWV's transmission:
> http://www.nist.gov/pml/div688/grp40/wwv.cfm

> I've slowly been replacing all of the clocks in my house with ones
> that set themselves.  It was interesting to see which ones failed
> when they changed the DST dates because they had hard-coded
> them. There's no reason to hard-code it because the DST status is
> part of the data stream.

I agree, the "ether" has to be WWV or WWVH.  That's what all of these
"atomic" clocks we can buy for a few bucks use.

As far as DST goes, don't forget that Arizona and parts of Indiana
don't use DST.  They stay on standard time all year.  So, unless the
clock has a way of knowing if it's in such a location it will need
some sort of user input to tell it to use or ignore the DST flag.
Since the clock also has to be manually adjusted for UTC offset
(i.e. time zone), I can see why manufactures skimped on adding an
auto-DST option for the standard consumer "atomic" clocks.  It was
probably left out of the first chip designed for these clocks and
nobody wants to spend the money to put it in.  It looks to me like
Oregon Scientific uses the same chip in all their products, but I
could be wrong.

My favorite clock in my house is a rather old (maybe over 100 years)
Waterbury wind up pendulum clock; I think it's a school house model.
When I bother to fine tune the pendulum height and remember to wind it
regularly, it keeps pretty good time - staying within a minute or two
per day (relative to my "atomic" clock.)  I do have to adjust the
pendulum every few months, I suspect due to temperature changes.
Anyway, it does quite well for something so old.  They just don't
build them like they used too...

-Gary

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by grumpy4413 » Mon, 11 Jul 2011 01:06:05


Quote:> ***** Moderator's Note *****

> Please tell us which ones were able to handle the DST change.

This was what i found so far -

http://www.nist.gov/pml/div688/grp40/receiverlist.cfm

http://tinyurl.com/5wd39ro

***** Moderator's Note *****

I changed the second URL for readability: it's for a Google search,
but it was 570 characters long, so I used the tinyurl site to make
it fit better.

Bill Horne
Moderator

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by David Scheid » Mon, 11 Jul 2011 01:54:51


:As far as DST goes, don't forget that Arizona and parts of Indiana
:don't use DST.  They stay on standard time all year.  So, unless the

All of Indiana has observed daylight savings time for six years or so.

--
sig 9

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Scott Dors » Mon, 11 Jul 2011 05:01:36




>> Probably just monitors WWV's transmission:
>> http://www.nist.gov/pml/div688/grp40/wwv.cfm

>> I've slowly been replacing all of the clocks in my house with ones
>> that set themselves.  It was interesting to see which ones failed
>> when they changed the DST dates because they had hard-coded
>> them. There's no reason to hard-code it because the DST status is
>> part of the data stream.

>I agree, the "ether" has to be WWV or WWVH.  That's what all of these
>"atomic" clocks we can buy for a few bucks use.

Actually most of them use WWVB, down in the VLF band, usually with a
small loopstick antenna that looks at the magnetic field rather than
the electrical field, so it can be physically small.  WWVB is a big
win because the groundwave goes a long distance, so the propagation
time is both much shorter than more predictable than that of a skywave
at 10 MHz from WWV or WWVH.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by John Meisse » Mon, 11 Jul 2011 09:35:22


Quote:> Please tell us which ones were able to handle the DST change.

I'm pretty sure they were La Crosse Technology clocks, but I don't
remember for sure. When they didn't change I called the manufacturer
and they sent me new clocks, no charge.

I haven't had the problem with any clocks since then. I sent the old
ones to my sister in Arizona. Since they don't observe DST the problem
won't affect her.


> As far as DST goes, don't forget that Arizona and parts of Indiana don't use
> DST.  They stay on standard time all year.  So, unless the clock has a way of
> knowing if it's in such a location it will need some sort of user input to
> tell it to use or ignore the DST flag. Since the clock also has to be manually
> adjusted for UTC offset (i.e. time zone), I can see why manufactures skimped
> on adding an auto-DST option for the standard consumer "atomic" clocks.

All of my consumer clocks have buttons on the back to specify US timezones,
and a switch to disable DST changes.
 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Sam Spad » Mon, 11 Jul 2011 10:16:14



> In message


>> The NIST facility is _amazingly_ accurate.  They have 'smarts' on the
>> server end that measure the round-trip latency to the user, and
>> advance the 'tick' so that it _arrives_ at the user's location at the
>> proper instant.  With quality software, one can set the system clock
>> with sub- millisecond accuracy.  If memory serves, the 'jitter' is
>> around 15 _micro- second_.

> This is a standard feature designed into the NTP protocol. It uses
> Marzullo's algorithm to determine the round trip delay.

I've used this program for years:

http://www.dillobits.com/yats32.html

 
 
 

System Clock Apparently Gaining One Second Every 30 Minutes [Telecom]

Post by Robert Bono » Mon, 11 Jul 2011 08:54:34






>>The NIST facility is _amazingly_ accurate.  They have 'smarts' on the
>>server end that measure the round-trip latency to the user, and
>>advance the 'tick' so that it _arrives_ at the user's location at the
>>proper instant.  With quality software, one can set the system clock
>>with sub- millisecond accuracy.  If memory serves, the 'jitter' is
>>around 15 _micro- second_.

>This is a standard feature designed into the NTP protocol. It uses
>Marzullo's algorithm to determine the round trip delay.

All well and good, but the NIST _dial-up_ service does not use NTP.

Also, all references  I i find for Marzullo's algorithm reference finding
the 'best fit' for uncertainty from *MULTIPLE* sources, over a _variable-
latency_ packet network.  When you have only a _single_ source Marzullo
doesn't seem to be of much use.   Claimed accuracy is circa 10 milliseconds,
for WAN sources, and circa 200 microsecond for in _local_ networks.

A _dial-up_ connection to NIST is, for all practical purposes, a *fixed*
latency connection, and thus the 'uncertainty' that Marzullo addresses is
essentially zero to start with.

You can have the far end simply 'echo' _character_by_character_, what the
server side sends, and measure the delay from when the UART 'transmit' is
toggled to when the 'received' interrupt is raised.  subtract off the
duration of the character, divide by 2, and you have a good estimate of
the one-way latency.  Advance the UART transmit toggle  by one character
duration _plus_ the one-way latency, the far-end 'received' interrupt
will occur _very_ close to the actual 'tick'.