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.
On 05/24/2017 09:53 AM, Chris Olson wrote:
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.
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:
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?
Because we connect directly to a known time server, which are all synced 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 chris_e_olson@yahoo.com said:
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.
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".
On May 24, 2017, at 7:53 AM, Chris Olson chris_e_olson@yahoo.com wrote:
One of our STEM interns recently observed that there are inexpensive clocks that sync via radio to standard time services.
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.
When I was a student, such questions would have earned me extra homework assignments.
So do I get an “A”? :)
Once upon a time, Warren Young warren@etr-usa.com said:
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!
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).
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.
Not exactly; laptop batteries' capacity is an order of magnitude larger than phone batteries.
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.
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).
On May 24, 2017, at 8:52 AM, Chris Adams linux@cmadams.net wrote:
Once upon a time, Warren Young warren@etr-usa.com said:
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!
This really has no bearing on time source; none of the commonly-used time sources (satellite, terrestrial radio, or network) carry time zone information
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.
(although WWVB does carry a bit to indicate if US DST rules are in effect).
…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.
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.
Not exactly; laptop batteries' capacity is an order of magnitude larger than phone batteries.
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.
The GPS transmitters probably have a higher received signal strength than WWVB
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).
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.
On Wed, May 24, 2017 10:45 am, Warren Young wrote:
On May 24, 2017, at 8:52 AM, Chris Adams linux@cmadams.net wrote:
Once upon a time, Warren Young warren@etr-usa.com said:
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!
This really has no bearing on time source; none of the commonly-used time sources (satellite, terrestrial radio, or network) carry time zone information
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.
(although WWVB does carry a bit to indicate if US DST rules are in effect).
â¦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.
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.
Not exactly; laptop batteries' capacity is an order of magnitude larger than phone batteries.
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.
The GPS transmitters probably have a higher received signal strength than WWVB
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).
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.)
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
Regardless, that's another reason not to do this as a matter of general policy. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ 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]
On 05/24/2017 12:20 PM, Valeri Galtsev wrote:
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?).
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_id=50031 ).
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)).
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...).
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_Ap...
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!).
On Thu, May 25, 2017 11:16 am, Lamar Owen wrote:
[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]
Lamar, thanks a lot for very instructive write-up!!
Valeri
On 05/24/2017 12:20 PM, Valeri Galtsev wrote:
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?).
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_id=50031 ).
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)).
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...).
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_Ap...
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!).
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
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
On Wed, May 24, 2017 at 8:36 AM, Warren Young warren@etr-usa.com wrote:
On May 24, 2017, at 7:53 AM, Chris Olson chris_e_olson@yahoo.com wrote:
One of our STEM interns recently observed that there are inexpensive clocks that sync via radio to standard time services.
There are two major types:
WWVB and its equivalents in other countries:
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.htmlb. 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.
When I was a student, such questions would have earned me extra homework assignments.
So do I get an “A”? :) _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On May 24, 2017, at 9:37 AM, Tate Belden wyoham@gmail.com wrote:
The time transmitted from WWV is not Mountain Time.
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.
On 05/24/2017 11:37 AM, Tate Belden wrote:
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
I remember listening to this on a shortwave radio back around '62...
On Wed, May 24, 2017 at 8:36 AM, Warren Young warren@etr-usa.com wrote:
On May 24, 2017, at 7:53 AM, Chris Olson chris_e_olson@yahoo.com wrote:
One of our STEM interns recently observed that there are inexpensive clocks that sync via radio to standard time services.
There are two major types:
WWVB and its equivalents in other countries:
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.htmlb. 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.
When I was a student, such questions would have earned me extra homework assignments.
So do I get an “A”? :) _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Chris Olson kirjoitti 24.5.2017 klo 16.53:
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.
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.
Our senior staff did not have a good answer or if time from such a radio module would be supported by the operating system.
The NTP server supports a large number of different radio clocks: https://www.eecis.udel.edu/~mills/ntp/html/refclock.html
On Wed, 2017-05-24 at 13:53 +0000, Chris Olson wrote:
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.
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.
On 05/24/2017 11:29 AM, Pete Biggs wrote:
... 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. ...
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.
On Wed, 24 May 2017, Pete Biggs wrote:
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.
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
Time on computers is typically set using Network Time Protocol (NTP) over the internet however I believe these [1] devices do what you're describing.
[1] - https://www.meinbergglobal.com/english/products/pci-express-clocks.htm
On 24 May 2017 at 15:53, Chris Olson chris_e_olson@yahoo.com wrote:
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. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Andrew Holway -
Chris Adams -
Chris Olson -
John Hodrien -
Lamar Owen -
m.roth＠5-cent.us -
Markku Kolkka -
Pete Biggs -
Robert Moskowitz -
Tate Belden -
Valeri Galtsev -
Warren Young