> With this setup you have no single point of failure, and even if the > connection to internet fails, they can still provide time as they are peering > and synchronizing with each other. No, it doesn't work that way. You need connectivity to at least one stratum 1 server. There is an option to elect one, orphan mode, if you get disconnected from the net. That keeps all the local clocks close together. They will all drift along with the chosen leader. > You can use this list to pick stratum 1 servers: > http://www.advtimesync.com/docs/manual/ > stratum1.html There is no date on that list. At a quick glance, a few systems I'm familiar with are way out of date. I wouldn't trust any of the details. Same for other lists of stratum 1 servers. They might be a good starting point. In particular, many servers that say "open access" on lists like that have changed their rules, often going off the air. > server time.nist.gov That's a bad example. NIST has servers at several locations. That name rotates across them. You might get a good one, or you might get one on the other side of the country. If it works well today, it may not after you reboot and pick a different server. https://tf.nist.gov/tf-cgi/servers.cgi > just a cheap GPS receiver (serial is best, but USB should be OK There are 3 levels of GPS receiver. GPSDO is best. GPS with PPS is second - serial prefered, but USB works. Low cost GPS (without PPS) on USB is last. USB is polled -- no interrupts. That adds a millisecond of jitter. That's probably not an issue if your goal is 100 ms. (If you are a geek, be sure you understand hanging bridges.) The timing on the serial port from low cost GPS receivers is often crappy. This is a horrible example: http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif Anyway, you need to check the device you select. (Or get suggestions from people who are using them for NTP.) The PPS signal will fix that. The GPSDO will continue providing decent time if your GPS stops working. Holdover is the buzzword. -- These are my opinions. I hate spam.

> > > With this setup you have no single point of failure, and even if the > > connection to internet fails, they can still provide time as they are peering > > and synchronizing with each other. > No, it doesn't work that way. You need connectivity to at least one stratum 1 > server. > There is an option to elect one, orphan mode, if you get disconnected from the > net. That keeps all the local clocks close together. They will all drift > along with the chosen leader. My understanding is that it would work moderately well even without a stratum-1 server, at least be able to operate within a few tens of milliseconds for several hours. Although I confess I haven't used peering in a very long time. In my workplace we added stratum-1 GPS symmetricom NTP servers about 6 months after the above mentioned setup. > > > > You can use this list to pick stratum 1 servers: > > http://www.advtimesync.com/docs/manual/ > > stratum1.html > > There is no date on that list. At a quick glance, a few systems I'm familiar > with are way out of date. I wouldn't trust any of the details. Same for > other lists of stratum 1 servers. They might be a good starting point. In > particular, many servers that say "open access" on lists like that have > changed their rules, often going off the air. My apologies, I just did a quick googling because I was on the phone and didn't have access to my desktop bookmarks. This is the list I normally use http://support.ntp.org/bin/view/Servers/StratumOneTimeServers > > > > server time.nist.gov > > That's a bad example. NIST has servers at several locations. That name > rotates across them. You might get a good one, or you might get one on the > other side of the country. If it works well today, it may not after you > reboot and pick a different server. > https://tf.nist.gov/tf-cgi/servers.cgi 100% agree on this...... DNS roundrobin is good enough for 10s of milliseconds, but for best results you should always pick nearby servers. The worst thing of DNS round robin is that it gives unpredictable results. > > > > just a cheap GPS receiver (serial is best, but USB should be OK > > There are 3 levels of GPS receiver. GPSDO is best. GPS with PPS is second - serial prefered, but USB works. Low cost GPS (without PPS) on USB is last. > > USB is polled -- no interrupts. That adds a millisecond of jitter. That's probably not an issue if your goal is 100 ms. (If you are a geek, be sure you understand hanging bridges.) > > The timing on the serial port from low cost GPS receivers is often crappy. This is a horrible example: > http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif > Anyway, you need to check the device you select. (Or get suggestions from people who are using them for NTP.) Ouch, that looks pretty awful. > > The PPS signal will fix that. > > The GPSDO will continue providing decent time if your GPS stops working. Holdover is the buzzword. Currently my stratum-1 servers are as follows, in decreasing order of accuracy: * amd64 PC with Symmetricom/Microsemi BCP635 timing board, fed with the 1 PPS signal from a UBLOX-7 receiver. * amd64 PCENGINES with GPSDO with PPS fed to serial port. I very recently got two GPSDO, a BG7TBL and a Oscilloquartz STAR 4 receiver. The latter is very nice as it also provides the receiver state (calculating stationary mode, stationary mode, GPS lock info and holdover info). * amd64 PCENGINES with vanilla UBLOX-7 receiver with PPS fed to serial port. Thus far I have been playing with PPS on the serial port. I just modified the serial port driver to support PPS_ECHOASSERT and PPS_ECHOCLEAR so that I can use the oscilloscope to get a quantitative understanding of what the interrupt latency and jitter is. Perhaps I should experiment with PPS on the parallel port as well. RS232 is far from ideal, mainly due to the fact that the rise time of the PPS edge on a 12 volt signal is very high. The UBLOX-7 PPS has a TTL output and the RS232 port I use is TTL compatible so I'm hoping this ameliorates the issue with the rising edge on the RS232, but I'll only know for once I get the measurements with the oscilloscope. I keep comparing the time between these three servers, and I've observed an absolute lock offset of approximately 10 to 20 microseconds between the timing board server and the PPS on RS232 servers. That is what I would expect by RS232 timings. Once I have the oscilloscope measurements I should be able to adjust and correct for the average interrupt latency, although I won't be able to do anything for the jitter. > > > -- > These are my opinions. I hate spam. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.