System Time Source

Home » CentOS » System Time Source
CentOS 17 Comments

One of our STEM interns recently observed that there are inexpensive clocks that sync via radio to standard time services.  This begged a question about why every computer would not have a radio module to receive time.  Our senior staff did not have a good answer or if time from such a radio module would be supported by the operating system.

When I was a student, such questions would have earned me extra homework assignments.  We now have only PC directed relationships with interns so we don’t assign any extra homework for curiosity.  Can anyone help with the answers?

Thanks and best regards.

17 thoughts on - System Time Source

  • It costs more to add a radio than an RTC and battery and get time from any of the Internet NTP time servers. Plus you then have to put the computer where the radio will receive the signal.

    I can’t tell you how many clocks I have seen with the wrong time because they are not getting the radio signal. It shows right on the clock face of no radio signal.

    If you have Internet, you have NTP.

    In fact most ARM SOCs are without RTC and depend on the Internet for time. Chrony works really well to make the quick jump at startup to get the time right. ntp itself can take too much time to step a system to the current time.

    I have done a bit of research into configuring chrony for a system without an RTC. See my guide at:

    http://www.htt-consult.com/CentOS7-armv7.html#Chrony%20caveats

  • Chris Olson wrote:
    with the atomic clocks of places like the NIST, or Greenwich, etc. This is what NTP or chrony is for.

    Why add a radio receiver when you’re already online, and can connect to one from the US federal gov’t?

    mark

  • Once upon a time, Chris Olson said:

    Only a very small percentage of computers sold need higher accuracy than can already be obtained from existing network sources. Many computers also are not in a position to receive the radio signals; both the satellite (GPS, GLONAS, etc.) and terrestrial (WWVB, MSF, etc.) signals are relatively difficult to pick up indoors.

    Also, while the receiver cost has come down significantly over the years, a typical timing GPS receiver module and antenna is still at least $50, which is a large amount of money compared to the razor-thin margins most computer manufacturers operate under, and would be a significant price increase on a $500 computer. The GPS cost would come down some in volume, but not enough to make it a “throw in”.

  • There are two major types:

    1. WWVB and its equivalents in other countries:

    https://en.wikipedia.org/wiki/WWVB

    2. GPS clocks.

    WWVB has several problems:

    a. It’s transmitting from a fixed location in a time zone you probably aren’t in — US Mountain — being the least populous of the lower 48’s four time zones. You therefore have to configure time zone offset and DST rules, which means additional software if you want it to track changes to these things. There were 10 batches of such changes last year!

    https://mm.icann.org/pipermail/tz-announce/2016-November/thread.html

    b. It’s a weak signal. Unless you’ve got a big antenna or are positioning the receiving device near a window, you probably can’t receive the WWVB signal reliably.

    c. Computers have major RFI shielding problems, which is why they’re typically placed in metal boxes. (Even plastic-cased laptops have metal boxes inside.) That means you have to have an external antenna even in the best case. Now apply what you know about Wifi reliability to the problem of receiving a signal from a different *time zone*.

    I happen to be in the Mountain time zone, and it doesn’t take too much to shield our WWVB clocks from the signal. I can only imagine how much easier it is out on the coasts.

    GPS time is a much better solution, but it’s power-hungry, as you probably know from running GPS on your smartphone. This rules it out for laptops.

    The GPS transmitters probably have a higher received signal strength than WWVB, but cinderblock walls and grids of 42U equipment racks block the GPS signal quite well. This is why data centers with such clocks generally have to run an antenna to the outside for their clock. That makes it far more expensive than just connecting to an upstream NTP server.

    So do I get an “A”? :)

  • Chris Olson kirjoitti 24.5.2017 klo 16.53:

    Terrestrial time services like DCF77 or WWV cover only part of the world, and satellite based GPS time receivers don’t work reliably indoors. So every computer wouldn’t be able to use a radio time receiver.

    The NTP server supports a large number of different radio clocks:
    https://www.eecis.udel.edu/~mills/ntp/html/refclock.html

  • Once upon a time, Warren Young said:

    This really has no bearing on time source; none of the commonly-used time sources (satellite, terrestrial radio, or network) carry time zone information (although WWVB does carry a bit to indicate if US DST rules are in effect). They each use a single global time scale (although unfortunately, not the _same_ time scale).

    Not exactly; laptop batteries’ capacity is an order of magnitude larger than phone batteries.

    No, GPS is lower signal strength than WWVB, at least for most of the continental US (although WWVB signal strength varies significantly based on the time of day, because it is a low frequency signal).

    Chris Adams

  • In addition to what everyone else has said …

    The terrestrial radio clocks are actually not that accurate. They are not designed for keeping things like a system clock “correct”. Commercial solutions only keep to within about +/- 0.5s per day, with resynchronisation happening about once a day.

    The GPS time system is also notoriously very precisely wrong. The time was set when the first satellite was sent up and has never been corrected since – so hasn’t taken account of leap seconds or relativistic effects. All that matters for GPS is that the time on each satellite transmission is identical, and to that end you can get a precision of about 3ns (which is what you need to get metre GPS
    accuracy) and which you then have to correct for all the various artefacts since inception. Lower cost GPS receivers get about 50ns accuracy, which is probably still OK for a system clock. The good thing is that the corrections necessary are well known and updated frequently.

    The bottom line is that NTP is still by far the best way of obtaining an accurate clock with a computer. If you need GPS accuracy, then it’s usually an enterprise solution with a single good GPS receiver providing a stratum 1 NTP source on the local network.

    P.

  • Warren, one slight correction on an other wise nicely written bit of info:

    The time transmitted from WWV is not Mountain Time. Even though the WWV
    transmitter farm is located in the Mountain time zone, the signals are transmitted as “Coordinated Universal time”, UTC, or ‘Zulu’ time.

    Here, you can listen to a recording made at the transmitter site for the
    5Mhz signal:
    https://ia802605.us.archive.org/24/items/WWV5MHz/WWV-5MHz.MP3


    Natrona County Beekeepers <http://ncbees.org>
    Casper Amateur Radio Club <http://casperarc.net>

  • In editing my prior reply, I removed the observation that GPS solves problem “a” by telling you where you are in the world, as well as what the UTC time is.

    It still has problems b and c, though.

    …which is of no help when the DST rules are hard-coded into the clock, as they are so frequently. I had to discard a few WWVB clocks when the last DST rules went into effect.

    Sure, but it’s still a market where people buy based on benchmarks. The laptop that gets 20 minutes less battery life but has great time accuracy even when not on the Internet will lose in the market.

    I went looking, and you’re right. GPS satellites transmit at 0.5 kW and WWVB at 70 kW, and WWVB has the additional advantage of less distance to transmit.

    (21000 km from orbit to Earth surface vs ~3000 km from Fort Collins to either Bangor, Maine or Miami.)

    Regardless, that’s another reason not to do this as a matter of general policy.

  • Whee, I had to check headers to see if my input filters had started pulling time-nuts@febo.com traffic into my CentOS folder….. and if you want to discuss the ins and outs of serious timekeeping, you might find that mailing list useful. (My $dayjob requires me to deal with that kind of precision.)

    No one has mentioned using the most ubiquitous of the time sync sources, though, and that’s the digital cellular network. Any one of GSM, 4GLTE, or 3G or even old CDMA2000 works, and will have very precise time (it’s required for the protocols for the phones to be locked to the base station’s time, and most base stations use GPS or SONET timing signals and either disciplined OCXO’s or rubidium standards frequency-locked to the GPS 1PPS or the SONET frame clock. Even a real T1 provided from the telco is traceable to a cesium PRS somewhere. ).

    One such standalone box is made by Beagle Software; see http://www.beaglesoft.com/celsynhome.htm and while it’s not exactly cheap, the concept could be extended to use one of the commonly available SDR dongles (like an RTL-SDR) and the timecode could be retrieved with software. No cell account is required to receive the timecode.

  • http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html https://www.aapt.org/doorway/TGRU/articles/Ashbyarticle.pdf http://www.timetoolsglobal.com/information/gps-ntp-server/

    I’ll accept that it doesn’t include leap seconds, but it does provide the offset from GPS time to UTC, so that’s not an issue.

    I understand the exact opposite as far as relativistic effects, with countering them being necessary for it to work as a positioning system.

    jh

  • I should have split the paragraph, because I didn’t mean to imply that that was the case.

    My point in mentioning the transmission location is to show that it’s probably a thousand km or more from wherever you are, since the spots in the US within the 1000 km radius are some of the least populous parts of the US.

    When most people think of “radio,” they think of the towers on the big hill just outside of town, or the faux palm tree concealing the cell phone transmitter a mile down the road.

    WWVB is in a different sub-class of “radio” from those two.

  • It is insightful, yet… There are a bunch of other factors that may need to be taken into account. Angular transmission pattern of satellite (horn?
    or is it yagi? antenna) vs ground based (monopole? or dipole? antenna –
    which one is used there to transmit in HF?). Ground effect (attenuation)
    along the whole path or propagation for ground based HF vs ground effect only at the receiption point, but much higher for much higher frequencies of GPS; pre-amplifier Signal to Noise ratio (S/N; which can technically be achieved to be much better at much higher GPS frequencies…). So, 70 kW
    vs 0.5 kW and the distance advantage still may not necessarily allow ground system beat hands down satellite based one (again, speaking only about S/N ratio for one vs another). It would be good to ask someone who can measure S/N for both (using the same $$ receiving radios) – which one is better.

    I would expect one disadvantage factor for GPS, as you have to receive and decode much wider signals for it as opposed to much slowed stuff for time purely ground based one…

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • [Going a bit off-topic here, and going to do a bit of a deep-dive on RF
    stuff, but maybe it will be useful to Chris]

    WWVB uses a two-element phased array, where each element is a 400-ft top-loaded vertical monopole. The ERP is listed as 70kW, so the antenna gain is already applied to the transmitted signal’s specification and thus doesn’t need to be considered. (Lots of technical data can be found in NIST’s report on the 1998 upgrade:
    http://ws680.nist.gov/publication/get_pdf.cfm?pub_idP031 ).

    Please see http://gpsinformation.net/main/gpspower.htm for the relevant data on GPS (25.6W output, 13dBi gain, EIRP 27dBW (about 500W), free space loss of 182dB, -130dBm receive signal strength (0.1 femtowatts, if I’ve done the calculation correctly)).

    WWVB’s signal is at 60kHz, which is LF, not HF. LF signals are not significantly attenuated by ground conductivity effects, so a simple inverse-square-law free-space path loss calculation is a close approximation; the loss to a point halfway around the world (~20,000 km)
    is about 94dB (82dB for 5,000km); the ERP is 70kW (78.45dBm); the minimum power available anywhere on the surface of the world is
    -15.55dBm, or 0.03mW and the minimum power available within 5,000km is about -3.55dBm, or about 0.44mW. Half a milliwatt is quite a bit to work with, excepting the noise effects of 1/f (“pink”) noise and local interference. Higher-gain receive antennas are easy at 60kHz (iron-core loopstick or a multi-turn loop). According to NIST’s site, however, WWVB is currently running at half-power (35KW ERP; 75.45dBm) so cut the available power in half at the moment.

    However, WWVB’s signal _is_ 60kHz, and so any building of metal construction, even sparse-spaced rebar in concrete, will effectively be a very high attenuation ‘waveguide-beyond-cutoff’ attenuator, and so a very effective shield, even with the very high power available to the receiver.

    GPS receiver module manufacturer u-Blox has an informative paper on GPS
    receiver antenna design that might answer some other questions:
    https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf?utm_source=en%2Fimages%2Fdownloads%2FProduct_Docs%2FGPS_Antennas_ApplicationNote%28GPS-X-08014%29.pdf

    I’m running an NTP setup here with our secondary being a CentOS box using an Agilent Z3816 GPS-disciplined OCXO with timecode and 1PPS
    outputs. Our primary is a Datum/Symmetricom SSU2000 modular system with a cesium PRS, a rubidium stratum 2E secondary clock, and an OCXO stratum
    3E tertiary clock. The cesium PRS is down at the moment, but the rubudium is close enough for current work.

    The CentOS box runs very well for this purpose, and the interface wasn’t too difficult. I have not implemented the 1PPS discipline for the kernel clock as yet, however, since the SSU2000 is up.

    As far as cost is concerned, I would think CDMA, GSM, or LTE timecode receivers would be a bit less expensive to integrate than GPS receivers, but u-blox and others have really gotten the cost down for GPS modules.
    GPS is already supported by the NTP server shipped with CentOS, where I
    don’t think any CDMA/GSM/LTE timecode receivers are (but I reserve the right to be wrong!).

  • Lamar, thanks a lot for very instructive write-up!!

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++