Interesting stratum 1 NTP clock
Folks who run NTP in their nets might wanna check out: http://www.coetanian.com/tss/tss100.htm This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer, complete with 10BaseT interface. It's also getting close to being plug-n-play. I've been beta testing one for a couple of weeks and it seems to chime reasonably well. Tony p.s. I have no finanical interest in this product or this company whatsoever. I'm just a time geek...
I know some of you have heard this rant before, but I thought I'd send it anyway. I'm a time geek for many years, and used to run a popular open stratum 1 clock back when you had to do custom work to get 20us system clock accuracy. It always pained me when someone from Australia thought it was better to get time from my stratum 1 in the US rather than some perfectly fine stratum 2 in oz. NTP does well with random time packet delays, but will have errors with systematic differences in the out and back legs of the round trip (like asymmetric routing.) I know running an antenna wire and a roof antenna is a pain, but PLEASE PLEASE start looking at making clocks a standard part of your infrastructure and have something that describes to your customers how to get time from you. The number of open stratum 1 clocks is just not adequate for the number of people that are starting to chime. With entries in the market like this, it's not realy a matter of cost or engineering any more. I would be happy to talk to people about special situations they need to solve. jerry
Would a GPS hooked to the serial port of a Linux box do the same? Dirk On Mon, Jun 22, 1998 at 10:43:48PM -0700, Tony Li wrote:
Folks who run NTP in their nets might wanna check out:
http://www.coetanian.com/tss/tss100.htm
This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer, complete with 10BaseT interface. It's also getting close to being plug-n-play.
I've been beta testing one for a couple of weeks and it seems to chime reasonably well.
Tony
p.s. I have no finanical interest in this product or this company whatsoever. I'm just a time geek...
On Wed, Jun 24, 1998 at 09:40:01AM -0700, dirk@power.net wrote:
Would a GPS hooked to the serial port of a Linux box do the same?
Within limits. There are latency issues. Check out http://www.eecis.udel.edu/~ntp/ for an excellent collection of info on NTP. Cheers, -- jr 'always did love that verb...' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Would a GPS hooked to the serial port of a Linux box do the same?
Dirk
On Mon, Jun 22, 1998 at 10:43:48PM -0700, Tony Li wrote:
Folks who run NTP in their nets might wanna check out:
http://www.coetanian.com/tss/tss100.htm
This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer, complete with 10BaseT interface. It's also getting close to being plug-n-play.
I've been beta testing one for a couple of weeks and it seems to chime reasonably well.
Tony
p.s. I have no finanical interest in this product or this company whatsoever. I'm just a time geek...
Any clock hooked up to a NTP server will make the server a stratum 1 server. It makes no statements about accuracy, just NTP hopwise closeness to truth. To NTP stratum, there is no difference between the thing Tony mentioned and a modem calling ACTS. Your accuracy of time will be much lower in the later cases, with what you proposed usually having errors in the single digit milliseconds. (rant #2) Lots of people say 'Why should I care about accurate time?' I have used NTP synchronized clock with both tcpdump and Cisco logging to chase problems. Sometimes I'm after big things, but other times I'm trying to figure out whether two things that are happening are the same or different. Being able to have time accurate to the few packet range is a real in separating these out. It's really hard to get there when you're talking about OC48s, but even fast ethernets have packets lasting in the 10s of microseconds. The nastiest problem I ever traced this way was a ethernet card on a bsd unix box that would occasionally drop interrupts when the system was under load. Being able to have two machines looking on the wires while the problem machine was acting as a router was the only way I found it. The events rarely lasted more than a couple milliseconds, so 10+ms timing just wouldn't have been good enough. Someone might have been able to guess the problem other ways, but with this I had tools to see the problem. So usually you don't need it, and if you don't have it you won't even believe you need it, but I have used it and always want it available. Not many (maybe none) customers are going to care below the 10s on milliseconds, but as a network engineers it could save you. (end or rant) jerry
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 ---- :r~/humour/signature :wq
From: Tim Pozar <pozar@lns.com>
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
It is noteworthy that certain manufacturers (Rockwell and possibly Trimble come immediately 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.
Welcome to the nasty world of using boxes not designed for time source as a time source. The Trimble accutime units (which are designed for time synch) do the right thing, they are the only ones I've used. I have gotten a couple companies to stop advertising that they can be a time source if they don't do it right. Not all GPS receivers are time sources! It may be imperfect, but GPSWorld magazine does an annual receiver survey, and they list applications each receiver was designed for. Using anything that doesn't say it is designed for timing is risky. Once you get any new stratum 1 online, always find a nearby trusted stratum 1 and peer, just to do a couple week sanity check before offering it live. an expect script on the ntpq or xntpdc output in a cron job should catch it if it goes weird. jerry
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 On Thu, 25 Jun 1998, Robert E. Seastrom wrote:
From: Tim Pozar <pozar@lns.com>
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
From: Shawn David Solomon <sdsolomo@iupui.edu> 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_Sy... 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
Robert E. Seastrom wrote:
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.
We're using (as a stratum 1 NTP clock) the Datum Inc. TymServe 2100 box, a nice 1U rack-mount unit which receives GPS and outputs NTP and 1PPS (satisfying 2 above) and also has a 10MHz output (satisfying 1 above). A rubidium oscillator is an option on this box. See http://www/datum.com/ for more details. Disclaimer: No affiliation to Datum Inc... just a customer! James
Some of you may be interested in this website about submicrosecond UTC on a FreeBSD machine http://phk.freebsd.dk/rover.html -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com
W&G also used to make or resell a stratum 1 NTP speaking GPS clock with oven-based thermally stabilized oscillator. I loved it. But I cannot find it on their web page, so perhaps they do not sell it anymore. It was a little pricy, and Tony's suggestion looks much cheaper. Eric Carroll -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Tony Li Sent: Tuesday, June 23, 1998 1:44 AM To: nanog@merit.edu Subject: Interesting stratum 1 NTP clock Folks who run NTP in their nets might wanna check out: http://www.coetanian.com/tss/tss100.htm This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer, complete with 10BaseT interface. It's also getting close to being plug-n-play. I've been beta testing one for a couple of weeks and it seems to chime reasonably well. Tony p.s. I have no finanical interest in this product or this company whatsoever. I'm just a time geek...
I looked at Stratum 1 clocks at SuperCom (I'm a time geek too, but it's hard to get sub-microsecond accuracy from a stem-wind chronometer...) TrueTime has some damn nice clocks that you can use to time standard telco and video stuff, but which also can have NTP capable Ethernet interfaces. GPS based, but you can add cesium oscillators, if you go for that sort of thing.... As I recall, prices range form about $5k to about $20k, depending. No affiliation at all with these guys, I just happened to have their catalog sitting on my desk. Stan
participants (12)
-
dirk@power.net
-
Eric M. Carroll
-
james@millhams.co.uk
-
Jay R. Ashworth
-
Jerry Scharf
-
Michael Dillon
-
Paul Mansfield
-
Robert E. Seastrom
-
Shawn David Solomon
-
Stan Hanks
-
Tim Pozar
-
Tony Li