Re: [CentOS] System Time Source

[Valeri Galtsev]

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_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!).
>
> ___
> 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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Lamar Owen]

[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_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!).


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Andrew Holway]

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  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
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Valeri Galtsev]

On Wed, May 24, 2017 10:45 am, Warren Young wrote:
> On May 24, 2017, at 8:52 AM, Chris Adams  wrote:
>>
>> Once upon a time, Warren Young  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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Robert Moskowitz]

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  wrote:


On May 24, 2017, at 7: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.

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”? :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos






___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 9:37 AM, Tate Belden  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.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[John Hodrien]

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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Lamar Owen]

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-n...@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.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 8:52 AM, Chris Adams  wrote:
> 
> Once upon a time, Warren Young  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.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Tate Belden]

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  wrote:

> On May 24, 2017, at 7: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.
>
> 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”? :)
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



-- 
Natrona County Beekeepers 
Casper Amateur Radio Club 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Pete Biggs]

On Wed, 2017-05-24 at 13:53 +, 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.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Chris Adams]

Once upon a time, Warren Young  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).
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Markku Kolkka]

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

-- 
Markku Kolkka
markku.kol...@iki.fi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 7: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.

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”? :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Chris Adams]

Once upon a time, Chris Olson  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".

-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[m . roth]

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Robert Moskowitz]

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


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos