Would a GPS hooked to the serial port of a Linux box do the same?
Dirk
No. You need to dectect the event of the second. Some OEM GPS boxes will
have another pin that will go low/high when this event occurs.
Also, beware that currently GPS time is 12 seconds fast from UTC.
Tim
we synchronize from the NTP server attached to Stonehenge... the first silicon
based clock.
not very accurate, and useless when its cloudy, but great for predicting the
next ice-age.
sorry, I couldn't resist
(to explain, for those historically challenged, I found this on altavista...
http://www.dcs.ex.ac.uk/studyRes/my-town/cs93dlh/stone.htm
)
Paul
Would a GPS hooked to the serial port of a Linux box do the same?
No. You need to dectect the event of the second. Some OEM GPS boxes will
have another pin that will go low/high when this event occurs.
In places where I've seen this done, that pin usually ended up tied to
DCD. The Cisco appears to permit this to be on { RI, DSR, DTR, CTS,
RTS, DCD } and also support an "inverted" signal, which I take to mean
high->low transition is PPS, not low->high. It is noteworthy that
certain manufacturers (Rockwell and possibly Trimble come immediately
to mind) do not synchronize the PPS pulse to the top of the second as
standardized by USNO (and indirectly BIH) but rather just give you one
pulse per second starting at an arbitrary (but accurately expressed in
the NMEA sentence!) point in the second.
Also, beware that currently GPS time is 12 seconds fast from UTC.
Not if you have a "good" GPS that picks up that data in the ephemeris
and corrects automatically. Almost all of them will do this now.
Your average end-user has no interest in the fact that GPS has no
concept of "leap seconds" to bring itself into compliance with
international standard time, and thus should not have to compensate
for it.
---Rob
> Also, beware that currently GPS time is 12 seconds fast from UTC.
The UTC correction is sent in the almanac, I think, as well as the
leap second warning. Most boxes make the correction for you, or
give you the choice.
And GPS time sources do seem to chime in sync with non-GPS sources:
address ref clock st when poll reach delay offset disp
*~x.x.x.x .GPS . 1 174 256 377 9.8 -0.21 4.2
+~x.x.x.x .GPS . 1 237 256 377 15.9 0.17 0.4
~x.x.x.x . . 1 981 1024 377 8.9 157.65 136.0
+~x.x.x.x .ACTS. 1 3 256 377 42.8 -0.31 4.2
-~x.x.x.x .WWVB. 1 334 1024 377 10.0 -7.86 0.2
~x.x.x.x . . 1 271 1024 373 297.4 66.60 70.4
-~x.x.x.x .WWVB. 1 680 1024 377 18.0 -10.39 2.0
-~x.x.x.x . . 1 219 1024 277 195.8 20.83 40.5
-~y.y.y.y .GPS . 1 21 256 377 24.6 0.73 0.6
+~x.x.x.x .USNO. 1 209 256 377 41.6 0.16 0.2
-~x.x.x.x .USNO. 1 592 1024 377 61.7 17.96 97.0
Or, from another perspective:
address ref clock st when poll reach delay offset disp
-~x.x.x.x .GPS . 1 686 1024 377 54.9 -10.35 5.2
+~x.x.x.x .USNO. 1 128 128 376 107.0 0.12 0.3
+~x.x.x.x .USNO. 1 113 128 377 107.6 -0.32 2.3
-~x.x.x.x .DCFp. 1 53 512 357 55.6 4.16 10.6
~x.x.x.x .ACTS. 1 279 1024 377 159.1 -2.54 16.1
-~x.x.x.x .ACTS. 1 347 1024 377 151.7 -2.00 5.9
-~x.x.x.x .GPS . 1 505 1024 377 70.5 6.75 11.2
~x.x.x.x .GPS . 1 237 1024 377 555.6 7.68 19.5
~x.x.x.x .WWVB. 1 365 1024 377 162.7 -10.05 18.3
+~y.y.y.y .GPS . 1 183 128 377 164.5 0.83 0.1
+~x.x.x.x .IRIG. 1 14 128 377 114.5 0.44 1.3
~x.x.x.x .TDF . 1 104 1024 377 116.0 30.94 22.2
+~x.x.x.x .DCFa. 1 124 128 377 35.7 -0.12 0.8
*~x.x.x.x .PL02. 1 78 128 377 2.2 0.42 0.4
~x.x.x.x .PL01. 2 180 512 377 1.8 0.05 1.7
Note that the y.y.y.y address is the beta test box in question.
Addresses changed to protect the guilty. 
Tony
I'm glad we've wandered upon the topic of stratum 1 clocks. I've been
looking for a clock that has the capability to provide clocking to Cisco
ATM switches (BPX's) and also provide a clock source for our unix hosts.
Do they make such a beast? is it a good idea to use the clock for both
purposes?
Any help/comments welcomed..
shawn
I'm glad we've wandered upon the topic of stratum 1 clocks. I've been
looking for a clock that has the capability to provide clocking to Cisco
ATM switches (BPX's) and also provide a clock source for our unix hosts.
Do they make such a beast? is it a good idea to use the clock for both
purposes?
Actually, you're looking for two different things here:
1) a frequency standard that is traceable to a cesium or rubidium
frequency source, with an output of 1 MHz, 10 MHz, 100 MHz, or
whatever the PLL in the Cisco wants to see to discipline the line
clocking, and
2) a time standard (synchronized to USNO) with a 1PPS output that is
synchronized to the top of the second.
My question would be, what is the goal here? All of the integrated
plug-n-play NTP servers represent a tradeoff of money for time, but
that may well represent a wise choice if you don't have someone on
your staff who has built a stratum 1 NTP server before. If there is
some reason to use the same clock for both? If not, there is a pretty
good chance that you can set up two separate units, a GPS-based unit
for the computers and a Cs or Rb standard for the ATM switch for less
money than you would pay for a brand new integrated unit. This is
particularly true if you're handy with surplus shops -- I have seen Rb
standards going for as low as $800 (working, with plenty of life left
in the tube), and if you have plenty of time and access to an
already-calibrated frequency standard, even the calibration is well
within the capabilities of any reasonably advanced technical
generalist.
If you want to talk more about this, let's take it offline before
someone sends me email telling me that NTP is not an operational issue
(bah!). 
---rob
PS: links o' the day (bouquet of options from ready-made to roll-your-own):
http://www.truetime.com/DOCS/request.html
http://www.tmo.hp.com/tmo/Summaries/English/#Frequency_Time_Standards_and_Synchronization
http://www.trimble.com/oem/om_timng.htm
http://www.mot.com/AECS/PNSB/products/pnsbprod.html
http://www.tapr.org/tapr/html/tac2.html