Re: [CentOS] System Time

[Blake Hudson]

On 3/8/2020 1:55 PM, Frank Cox wrote:
 Digital cinema equipment is the only commercial electronic equipment 
that I know of that is deliberately designed to not do what it's 
intended to do


When someone asks why their firewall is blocking such and such, I 
sometimes respond that firewalls are "specialized routers designed to 
drop traffic [rather than deliver it]"



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

Re: [CentOS] System Time

[Stephen John Smoogen]

On Sun, 8 Mar 2020 at 14:01, Chris Olson via CentOS 
wrote:

> A few years ago, one of our interns was curious about system
> time keeping features in computer systems.  This intern was
> also the proud owner of an inexpensive Radio-Controlled Clock.
> The intern wondered why computer motherboards were not just
> equipped with a chip like the ones in the RCC so that their
> system time would always be correct.
>
>
One issue is that the radio clock frequencies are based on the country they
are in. They are also dependent on different characteristics of those
frequencies. In the US, the clock measurement which reaches the entire
country is the 60 kHz WWWVB. It hugs the ground so does not miss places
like the WWV frequencies of 5,10,15 MHz. However WWWVB needs a very long
antennae to be used and it can get masked by anything from a kitchen
blender or a lot of computer parts. This means that the antennae need to be
away from most equipment. The frequencies that most US radio clocks use are
the WWV 5, 10 and 15 Mhz.  The problem with these frequencies are many:
1. They are shortwave frequencies which bounce off the ionosphere. You may
get areas of the country skipped over all different times of day or year or
sun sponts.
2. The frequencies are used by a lot of chips. That means you are going
drown out a lot of talk from computers.
3. The data in the signals are different per country but due to the
ionosphere skipping you might get a different clock source.
4. There is only one signal per country so you can drift out of time easier
for various reasons.



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

https://en.wikipedia.org/wiki/WWVB
The radiation pattern of WWVB antennas is designed to present a field
strength of at least 100 μV/m over most of the continental United States
and Southern Canada during some portion of the day. Although this value is
well above the thermal noise floor, man-made noise and local interference
from a wide range of electronic equipment can easily mask the signal.
Positioning receiving antennas away from electronic equipment helps to
reduce the effects of local interference.



> I posted a question about this on the CentOS email list and
> received more responses than those postings about problems
> with the new Firefox release.  I must have really struck a
> very sensitive system time nerve.
>
> This large response was a bit of a surprise and included a
> bunch of time related horror stories.  It became clear why
> using an RCC chip on motherboards would NOT be a good idea.
> GPS network time servers seemed to be a preferred choice.
>
> All of our bedrooms have Radio-Controlled Clocks. At 5:30
> this morning, half of the clocks displayed the correct time.
> The other half of the clocks were incorrectly showing a time
> one hour ahead. Maybe this is one more piece of evidence to
> reject using an RCC time base for computers, at lease in thestate of
> Arizona.
>
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time

[Chris Adams]

Once upon a time, Pete Biggs  said:
> There's also a massive problem with
> signal strength in the UK - the (singular) time transmitter is in the
> middle of the country in Cumbria and in the south it's virtually
> impossible getting a signal any further than about 2 feet from a window
> - not a hope of getting anything in an office building!

There are different systems around the world (WWVB in the US for
example), and I don't think there's a system at all in many countries.
Also, putting a receiver inside a computer case would pretty much never
work for the low radio frequencies used by these systems, so there'd
have to be an external antenna (a lot of effort to go to when you could
just use network time sources).

Radio clock accuracy is typically in the 100ms range, so is good enough
for most people's computer clock usage.

> GPS times also have problems. They are very accurately wrong!  The
> atomic clocks on the satellites haven't been updated since they were
> launched, so no leap seconds.

That is not a problem - GPS time is defined as being continuous, unlike
UTC.  However, the GPS signal includes the UTC offset, which is updated
when UTC applies a leap second, so you can calculate correct UTC from
just the radio signal.  I'm not as familiar with the GPS alternatives
(Galileo, GLONASS, Beidou, and more), but I believe they'd all be the
same (a continuous time base, with offsets specified in the data).

Also, again, GPS signals are weak and require an external antenna.

I do have an external GPS receiver and external antenna hooked up to one
system at home, so I have a stratum-1 NTP server (probably accurate to
about 1µs).

Basically for most, the "chip inside the box to set the clock" is the
network chip. :)  If you need clock setting on a disconnected network,
you can get a dedicated time server.

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

Re: [CentOS] System Time

[Kenneth Porter]

--On Sunday, March 08, 2020 6:59 PM + Chris Olson via CentOS 
 wrote:



All of our bedrooms have Radio-Controlled Clocks. At 5:30
this morning, half of the clocks displayed the correct time.
The other half of the clocks were incorrectly showing a time
one hour ahead.


Probably a result of political changes to when DST transitions occur. We 
see a new tzdata package fairly regularly because some politician somewhere 
in the world decided to change when his country would switch between 
standard time and DST. (It's not just Linux. All operating systems use this 
package. So that Windows Patch Tuesday may be JUST for a tzdata update!)


The hardware that suffers the most is devices with fixed firmware that 
can't be updated. Notably, those cheap "atomic" clocks.


So just wait a few weeks for the older clocks to switch on the day the 
older laws specified.


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

Re: [CentOS] System Time

[Frank Cox]

On Sun, 8 Mar 2020 17:59:16 + (UTC)
Chris Olson via CentOS wrote:

> why computer motherboards were not just
> equipped with a chip like the ones in the RCC so that their
> system time would always be correct.

Digital cinema servers (the gadgets that feed the movie to the projector and 
sound systems) run on Linux.  The movies are shipped to the theatre in an 
encrypted form and a key is emailed to the theatre that allows the movie to be 
played from date-and-time to next-date-and-time.  Some keys are valid for one 
day, most are valid for a week, some are valid for six months.

As you can see, the system time on a cinema server is very important.  If a key 
is valid at 11:00am for a movie that's to be shown at 11:00am (which can happen 
even though it's not a good practice) then if your system time is five or ten 
minutes slow your showtime gets screwed up because you can't play the movie yet.

And cinema server clocks are notoriously inaccurate.  It's one of those ironies 
that a twenty-thousand dollar server is built with a fifteen cent clock chip in 
it.  And because the showtimes are an important element of the digital cinema 
key system, the servers all have a "secure clock" in them that can't be 
adjusted by more than six minutes per year.

(Yes, they're built that way.  Cinema servers are the most locked down 
awful-to-deal-with things that you can possibly imagine outside of digital 
cinema projectors which are also locked down with the additional feature of 
anti-tamper devices, and a lot of "hidden stuff" in both servers and 
projectors.  Digital cinema equipment is the only commercial electronic 
equipment that I know of that is deliberately designed to not do what it's 
intended to do, i.e. play a movie.)

After learning the pitfalls of this the hard way, most theatres (including 
mine) now have a computer dedicated to acting as an ntp server in the 
projection booth to tell the equipment what time it is.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time

[Pete Biggs]

On Sun, 2020-03-08 at 17:59 +, Chris Olson via CentOS wrote:
> A few years ago, one of our interns was curious about system
> time keeping features in computer systems.  This intern was
> also the proud owner of an inexpensive Radio-Controlled Clock.
> The intern wondered why computer motherboards were not just
> equipped with a chip like the ones in the RCC so that their
> system time would always be correct.
> 

> 
> This large response was a bit of a surprise and included a
> bunch of time related horror stories.  It became clear why
> using an RCC chip on motherboards would NOT be a good idea.
> GPS network time servers seemed to be a preferred choice.
> 

The problem with radio time signals is that they just aren't accurate
enough. Your bedroom clock needs to be correct to within a minute or
so, but they are generally correct to about +/- 5 seconds. That's just
not good enough for system times.  There's also a massive problem with
signal strength in the UK - the (singular) time transmitter is in the
middle of the country in Cumbria and in the south it's virtually
impossible getting a signal any further than about 2 feet from a window
- not a hope of getting anything in an office building!

GPS times also have problems. They are very accurately wrong!  The
atomic clocks on the satellites haven't been updated since they were
launched, so no leap seconds. There are corrections that can be applied
once the time has been received but it depends on a knowledge of leap
seconds - I think they are currently about 18 seconds out.  But they
are accurate to about 10-100ns.  You also need a decent antenna to get
the high accuracy, which again means that you need to be near a window
to see the satellites.

Generally much easier to use NTP!

P.




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

[CentOS] System Time

[Chris Olson via CentOS]

A few years ago, one of our interns was curious about system
time keeping features in computer systems.  This intern was
also the proud owner of an inexpensive Radio-Controlled Clock.
The intern wondered why computer motherboards were not just
equipped with a chip like the ones in the RCC so that their
system time would always be correct.

I posted a question about this on the CentOS email list and
received more responses than those postings about problems
with the new Firefox release.  I must have really struck a
very sensitive system time nerve.

This large response was a bit of a surprise and included a
bunch of time related horror stories.  It became clear why
using an RCC chip on motherboards would NOT be a good idea.
GPS network time servers seemed to be a preferred choice.

All of our bedrooms have Radio-Controlled Clocks. At 5:30
this morning, half of the clocks displayed the correct time.
The other half of the clocks were incorrectly showing a time
one hour ahead. Maybe this is one more piece of evidence to
reject using an RCC time base for computers, at lease in thestate of Arizona.




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

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

[CentOS] System Time Source Responses

[Chris Olson]

It looks like we may have hit on a popular subject with the
questions about system time sources.  Thanks for all of the
responses.  Our intern and senior software staff now have
useful information and new perspective.

___
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

[CentOS] System Time Source

[Chris Olson]

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] System Time Jumps During Boot on CentOS 7

[Peter Brady]

Hi All,

Just noticed a funny time jump on a testing CentOS 7 VM.  Specifically
the system time jumps around by a few hours during system boot.  The
below is a selection from /var/log/messages during boot:


Jan 19 12:49:57 arr-data-dev chronyd[716]: Frequency -0.829 +/- 0.007
ppm read from /var/lib/chrony/drift
Jan 19 12:49:57 arr-data-dev polkitd[720]: Started polkitd version 0.112
Jan 19 12:49:57 arr-data-dev systemd: Starting D-Bus System Message Bus...
Jan 19 12:49:57 arr-data-dev systemd: Starting GSSAPI Proxy Daemon...
Jan 19 12:49:57 arr-data-dev systemd: Started Dump dmesg to /var/log/dmesg.
Jan 19 12:49:57 arr-data-dev kernel: NET: Registered protocol family 40
Jan 19 12:49:57 arr-data-dev sssd: Starting up
Jan 19 12:49:57 arr-data-dev systemd: Started GSSAPI Proxy Daemon.
Jan 19 12:49:57 arr-data-dev systemd: Reached target NFS client services.
Jan 19 12:49:57 arr-data-dev systemd: Starting NFS client services.
Jan 19 12:49:57 arr-data-dev systemd: Reached target Remote File Systems
(Pre).
Jan 19 12:49:57 arr-data-dev systemd: Starting Remote File Systems (Pre).
Jan 19 12:49:57 arr-data-dev systemd: Started Authorization Manager.
Jan 19 12:49:57 arr-data-dev systemd: Starting firewalld - dynamic
firewall daemon...
Jan 19 20:47:57 arr-data-dev systemd: Time has been changed
Jan 19 20:47:57 arr-data-dev chronyd[716]: Forward time jump detected!
Jan 19 20:47:57 arr-data-dev sssd[be[default]]: Starting up



Jan 19 20:48:05 arr-data-dev systemd: Starting Multi-User System.
Jan 19 20:48:05 arr-data-dev systemd: Starting Update UTMP about System
Runlevel Changes...
Jan 19 20:48:05 arr-data-dev systemd: Started Update UTMP about System
Runlevel Changes.
Jan 19 12:50:09 arr-data-dev chronyd[716]: Selected source IP-CHANGED
Jan 19 12:50:09 arr-data-dev chronyd[716]: System clock wrong by
-28676.126423 seconds, adjustment started
Jan 19 12:50:09 arr-data-dev chronyd[716]: System clock was stepped by
-28676.126423 seconds
Jan 19 12:50:09 arr-data-dev systemd: Time has been changed
Jan 19 12:50:09 arr-data-dev chronyd[716]: Selected source IP-CHANGED
Jan 19 12:50:10 arr-data-dev chronyd[716]: Selected source IP-CHANGED
Jan 19 12:50:11 arr-data-dev chronyd[716]: Selected source IP-CHANGED

For reference the 12:49 -> 12:50 is the correct local time, I'm in the
Australian Eastern Daylight Saving time zone and my hardware clock (from
hwclock) is close to that time.

The plus eight hours jump has me curious though as I think this is
causing some trouble for SSSD and Network Manager that are starting up
in interval when the time is stepped forward.  Given I'm at +11 from UTC
the system clock does not appear to be jumping to UTC.

I'm running 3.10.0-514.2.2.el7.x86_64 with yum reporting no patches. 
This is a VM running on ESXi 5.6.

According to /var/log/boot.log everything started up OK.

Has anyone seen anything similar?

Thanks in advance,
-pete





signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] System Time - UTC and Local Time

[Johan Martinez]

I have installed CentOS on a VM by checking 'System Clock uses UTC' option.
Later I selected CST time zone. Now the date command shows UTC time with
CST timezone:  Thu Dec  1 04:14:39 CST 2011.  How do I change system
clock to show CST local time? Also, more likely a dumb question but why
isn't date command showing UTC here instead of CST?

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

Re: [CentOS] System Time - UTC and Local Time

[Digvijay Patankar]

On Thu, Dec 1, 2011 at 9:47 PM, Johan Martinez jmart...@gmail.com wrote:

 I have installed CentOS on a VM by checking 'System Clock uses UTC' option.
 Later I selected CST time zone. Now the date command shows UTC time with
 CST timezone:  Thu Dec  1 04:14:39 CST 2011.  How do I change system
 clock to show CST local time? Also, more likely a dumb question but why
 isn't date command showing UTC here instead of CST?

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


This will be useful to you.

http://www.linuxsa.org.au/tips/time.html

With regards,


-- 
*Digvijay Patankar*
Senior Research Fellow,*
*
Dept. of Civil Engineering,
Indian Institute of Science,
Bangalore - 560012*
*


Please avoid sending me Word or PowerPoint attachments.

See http://www.gnu.org/philosophy/no-word-attachments.html
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time - UTC and Local Time

[Johnny Hughes]

On 12/01/2011 10:17 AM, Johan Martinez wrote:
 I have installed CentOS on a VM by checking 'System Clock uses UTC' option.
 Later I selected CST time zone. Now the date command shows UTC time with
 CST timezone:  Thu Dec  1 04:14:39 CST 2011.  How do I change system
 clock to show CST local time? Also, more likely a dumb question but why
 isn't date command showing UTC here instead of CST?

you told it that the system clock is set to UTC ... it sets the time
based on that when it boots up.

But, your system clock is NOT really set to UTC, it is set to CST.  So
you lied :D

That means it is going to shift your CST value by the amount of hours
you are away from CST as a correction, since you told it that the
hardware clock is set to UTC.

What you need to do to fix it is edit /etc/sysconfig/clock and if
there is a UTC=true, change it to UTC=false.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time - UTC and Local Time

[Johan Martinez]

Thanks for the explanation Johnny.  I checked on 'System Clock uses
UTC' option and on the next screen I set timezone to CST. I don't remember
what exactly I did there.

I changed /etc/sysconfig/clock as you mentioned and then also changed the
currently set datetime using date command. Then I installed ntp to manage
system time. And it's working as fine now.

jM


On Thu, Dec 1, 2011 at 10:39 AM, Johnny Hughes joh...@centos.org wrote:

 On 12/01/2011 10:17 AM, Johan Martinez wrote:
  I have installed CentOS on a VM by checking 'System Clock uses UTC'
 option.
  Later I selected CST time zone. Now the date command shows UTC time with
  CST timezone:  Thu Dec  1 04:14:39 CST 2011.  How do I change system
  clock to show CST local time? Also, more likely a dumb question but why
  isn't date command showing UTC here instead of CST?

 you told it that the system clock is set to UTC ... it sets the time
 based on that when it boots up.

 But, your system clock is NOT really set to UTC, it is set to CST.  So
 you lied :D

 That means it is going to shift your CST value by the amount of hours
 you are away from CST as a correction, since you told it that the
 hardware clock is set to UTC.

 What you need to do to fix it is edit /etc/sysconfig/clock and if
 there is a UTC=true, change it to UTC=false.


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


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

Re: [CentOS] System Time - UTC and Local Time

[Johan Martinez]

On Thu, Dec 1, 2011 at 10:30 AM, Digvijay Patankar dbpatan...@gmail.comwrote:

 On Thu, Dec 1, 2011 at 9:47 PM, Johan Martinez jmart...@gmail.com wrote:

  I have installed CentOS on a VM by checking 'System Clock uses UTC'
 option.
  Later I selected CST time zone. Now the date command shows UTC time with
  CST timezone:  Thu Dec  1 04:14:39 CST 2011.  How do I change system
  clock to show CST local time? Also, more likely a dumb question but why
  isn't date command showing UTC here instead of CST?
 
  jM
  ___
  CentOS mailing list
  CentOS@centos.org
  http://lists.centos.org/mailman/listinfo/centos
 

 This will be useful to you.

 http://www.linuxsa.org.au/tips/time.html

 With regards,



Thanks for the useful link. It was really helpful.

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Alexander Dalloz]

ankush grover schrieb:
 Hi friends,
 
 I am running Nagios 2.7-1 on Centos 5.0 32-bit hosted on Vmware ESX
 4.0. The issue I am seeing on the server is sometimes nagios is
 showing the below messages in /var/log/messages and as the system time
 gets changed some false alarms gets generated. I searched it on the
 google but I am not able to find the correct solution. I even posted
 on the nagios forum and they asked me to see elsewhere why the server
 shitfs so much before looking at nagios.
 
 
 Nov 21 20:37:12 linuxmonitoring nagios: Warning: A system time change
 of 4398 seconds (forwards in time) has been detected.  Compensating...
 Nov 21 19:23:54 linuxmonitoring nagios: Warning: A system time change
 of 4398 seconds (backwards in time) has been detected.  Compensating..
 
 
 Earlier this server was syncing time through ntp daemon and below is
 the ntp.conf file. Now I have set a cronjob which sync the time with
 the ntp server every 5 minutes but still the problem persist.
 
 ntp.conf file
 
 
 restrict default ignore
 restrict 127.0.0.1
 driftfile /var/lib/ntp/drift
 broadcastdelay 0.008
 #authenticate yes
 keys /etc/ntp/keys
 restrict 172.16.6.3 nomodify notrap noquery
 server 172.16.6.3
 restrict 172.16.6.2 nomodify notrap noquery
 server 172.16.6.2
 
 Please see the output of hwclock and date at the same time.
 hwclock
 Sat 21 Nov 2009 08:19:02 PM IST  -0.496922 seconds
 
 date
 Sat Nov 21 20:19:55 IST 2009
 
 
 Please advice what I need to do to fix this error.
 
 
 Regards
 
 Ankush

Be sure that only 1 mechanism for syncing time is active for your VM:
either NTP client configuration through ntpd running (like you have) OR
through the VMware tools. Both being active will result in trouble.

VMware recommends to use time syncronisation through NTP within the VM.

To debug your time sources in NTP make use of ntpq and/or ntpdc.

Regards

Alexander

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[nate]

ankush grover wrote:

 Earlier this server was syncing time through ntp daemon and below is
 the ntp.conf file. Now I have set a cronjob which sync the time with

Best not to run NTP inside a ESX VM. I've never gotten NTP to sync
inside of VMware outside of a kernel with VMI enabled (no versions
of RHEL support VMI at this time as far as I know).

What I do for my ~40 ESX/ESXi hosts:
- Have your ESX hosts sync to a good NTP server
- Make sure vmware tools is installed and running correctly
  (/etc/init.d/vmware-tools status)
- Enable time sync for your guest, either via the UI or via
  this command in the guest(I have this command run in cron
  every 5 minutes as I have seen for some reason time sync turn
  itself off:
   /usr/sbin/vmware-guestd --cmd vmx.set_option synctime 0 1
- On top of all of that I have another cron set to run ntpdate
  every 5 minutes against a local NTP server:
   /usr/sbin/ntpdate `cat /etc/ntp/step-tickers | grep -v \#`

For providing NTP services themselves, currently I run 3 VMs
at each site with Fedora 8 with VMI enabled for the guest VM
(the kernel in FC8 supports VMI, I suspect newer Fedoras work
fine too I just have no reason to change right now). And I have
these FC8 VMs sync to internet hosts(mainly time.nist.gov) so
my internal ESX and other systems can sync against them(they
are load balanced behind a F5 BigIP).

from FC8 kernel log:
VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 1.0
vmi: registering clock event vmi-timer. mult=9483317 shift=22
Booting paravirtualized kernel on vmi
vmi: registering clock source khz=2260999
Time: vmi-timer clocksource has been installed.

I currently run roughly 400 VMs this way and don't have any
noticeable time-related issues.

nate

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Akemi Yagi]

On Sun, Nov 22, 2009 at 7:08 AM, nate cen...@linuxpowered.net wrote:
 ankush grover wrote:

 Earlier this server was syncing time through ntp daemon and below is
 the ntp.conf file. Now I have set a cronjob which sync the time with

 Best not to run NTP inside a ESX VM. I've never gotten NTP to sync
 inside of VMware outside of a kernel with VMI enabled (no versions
 of RHEL support VMI at this time as far as I know).

As quoted by Brian earlier in this thread, the VMware knowledge base
offers their best practices for Linux guests in :

http://kb.vmware.com/kb/1006427

for VMware products including ESX and ESXi.  According to their
current recommendations,  In all cases use NTP instead of VMware
Tools periodic time synchronization.

The above KB articles gets updated from time to time, so it is a good
idea to check it back occasionally.

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[nate]

Akemi Yagi wrote:
 for VMware products including ESX and ESXi.  According to their
 current recommendations,  In all cases use NTP instead of VMware
 Tools periodic time synchronization.

I've been using vmware for 10 years, and I've never, ever ever
gotten NTP to hold sync inside of a VM outside of using a VMI
enabled kernel.

nate


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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Benjamin Franz]

nate wrote:
 Akemi Yagi wrote:
   
 for VMware products including ESX and ESXi.  According to their
 current recommendations,  In all cases use NTP instead of VMware
 Tools periodic time synchronization.
 

 I've been using vmware for 10 years, and I've never, ever ever
 gotten NTP to hold sync inside of a VM outside of using a VMI
 enabled kernel.
   

I've got more than 20 VMs spread over 5 machines (VMware Server 2.x), 
both 32 and 64 bit (hosts and VMs) that hold time perfectly using NTP.

1) Make *SURE* that 'cpuspeed' and any BIOS 'power saving' modes are 
disabled on your host and your VMs. Nothing screws timekeeping like 
having the CPU speed vary.

2) Use 'divider=10' on your grub kernel boot lines for your virtual 
machines.

-- 
Benjamin Franz
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Alexander Dalloz]

Benjamin Franz schrieb:
 nate wrote:
 Akemi Yagi wrote:
   
 for VMware products including ESX and ESXi.  According to their
 current recommendations,  In all cases use NTP instead of VMware
 Tools periodic time synchronization.
 
 I've been using vmware for 10 years, and I've never, ever ever
 gotten NTP to hold sync inside of a VM outside of using a VMI
 enabled kernel.
   
 
 I've got more than 20 VMs spread over 5 machines (VMware Server 2.x), 
 both 32 and 64 bit (hosts and VMs) that hold time perfectly using NTP.
 
 1) Make *SURE* that 'cpuspeed' and any BIOS 'power saving' modes are 
 disabled on your host and your VMs. Nothing screws timekeeping like 
 having the CPU speed vary.
 
 2) Use 'divider=10' on your grub kernel boot lines for your virtual 
 machines.

That kernel parameter information is out of date with CentOS 5.4:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427

As Akemi said, users of VMware virtualization products (bare metal
hypervisor products like ESX/ESXi and the other solutions) should
closely follow the KB article recommendations which are frequently updated.

Alexander


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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Clint Dilks]

nate wrote:
 ankush grover wrote:

   
 Earlier this server was syncing time through ntp daemon and below is
 the ntp.conf file. Now I have set a cronjob which sync the time with
 

 Best not to run NTP inside a ESX VM. I've never gotten NTP to sync
 inside of VMware outside of a kernel with VMI enabled (no versions
 of RHEL support VMI at this time as far as I know).

 What I do for my ~40 ESX/ESXi hosts:
 - Have your ESX hosts sync to a good NTP server
 - Make sure vmware tools is installed and running correctly
   (/etc/init.d/vmware-tools status)
 - Enable time sync for your guest, either via the UI or via
   this command in the guest(I have this command run in cron
   every 5 minutes as I have seen for some reason time sync turn
   itself off:
/usr/sbin/vmware-guestd --cmd vmx.set_option synctime 0 1
 - On top of all of that I have another cron set to run ntpdate
   every 5 minutes against a local NTP server:
/usr/sbin/ntpdate `cat /etc/ntp/step-tickers | grep -v \#`

 For providing NTP services themselves, currently I run 3 VMs
 at each site with Fedora 8 with VMI enabled for the guest VM
 (the kernel in FC8 supports VMI, I suspect newer Fedoras work
 fine too I just have no reason to change right now). And I have
 these FC8 VMs sync to internet hosts(mainly time.nist.gov) so
 my internal ESX and other systems can sync against them(they
 are load balanced behind a F5 BigIP).

 from FC8 kernel log:
 VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 1.0
 vmi: registering clock event vmi-timer. mult=9483317 shift=22
 Booting paravirtualized kernel on vmi
 vmi: registering clock source khz=2260999
 Time: vmi-timer clocksource has been installed.

 I currently run roughly 400 VMs this way and don't have any
 noticeable time-related issues.

 nate

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

   
The OP should also reference this document
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Akemi Yagi]

On Sun, Nov 22, 2009 at 12:19 PM, Clint Dilks cli...@scms.waikato.ac.nz wrote:

 The OP should also reference this document
 http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427

This is the 3rd time that KB article was quoted in this thread...  :-D

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

[CentOS] system time automatically fowards in time and then comes back to normal

[ankush grover]

Hi friends,

I am running Nagios 2.7-1 on Centos 5.0 32-bit hosted on Vmware ESX
4.0. The issue I am seeing on the server is sometimes nagios is
showing the below messages in /var/log/messages and as the system time
gets changed some false alarms gets generated. I searched it on the
google but I am not able to find the correct solution. I even posted
on the nagios forum and they asked me to see elsewhere why the server
shitfs so much before looking at nagios.


Nov 21 20:37:12 linuxmonitoring nagios: Warning: A system time change
of 4398 seconds (forwards in time) has been detected.  Compensating...
Nov 21 19:23:54 linuxmonitoring nagios: Warning: A system time change
of 4398 seconds (backwards in time) has been detected.  Compensating..


Earlier this server was syncing time through ntp daemon and below is
the ntp.conf file. Now I have set a cronjob which sync the time with
the ntp server every 5 minutes but still the problem persist.

ntp.conf file


restrict default ignore
restrict 127.0.0.1
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
#authenticate yes
keys /etc/ntp/keys
restrict 172.16.6.3 nomodify notrap noquery
server 172.16.6.3
restrict 172.16.6.2 nomodify notrap noquery
server 172.16.6.2

Please see the output of hwclock and date at the same time.
hwclock
Sat 21 Nov 2009 08:19:02 PM IST  -0.496922 seconds

date
Sat Nov 21 20:19:55 IST 2009


Please advice what I need to do to fix this error.


Regards

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

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Brian Mathis]

On Sun, Nov 22, 2009 at 12:19 AM, ankush grover ankushcen...@gmail.com wrote:
 Hi friends,

 I am running Nagios 2.7-1 on Centos 5.0 32-bit hosted on Vmware ESX
 4.0. The issue I am seeing on the server is sometimes nagios is
 showing the below messages in /var/log/messages and as the system time
 gets changed some false alarms gets generated. I searched it on the
 google but I am not able to find the correct solution. I even posted
 on the nagios forum and they asked me to see elsewhere why the server
 shitfs so much before looking at nagios.


 Nov 21 20:37:12 linuxmonitoring nagios: Warning: A system time change
 of 4398 seconds (forwards in time) has been detected.  Compensating...
 Nov 21 19:23:54 linuxmonitoring nagios: Warning: A system time change
 of 4398 seconds (backwards in time) has been detected.  Compensating..


 Earlier this server was syncing time through ntp daemon and below is
 the ntp.conf file. Now I have set a cronjob which sync the time with
 the ntp server every 5 minutes but still the problem persist.

 ntp.conf file


 restrict default ignore
 restrict 127.0.0.1
 driftfile /var/lib/ntp/drift
 broadcastdelay 0.008
 #authenticate yes
 keys /etc/ntp/keys
 restrict 172.16.6.3 nomodify notrap noquery
 server 172.16.6.3
 restrict 172.16.6.2 nomodify notrap noquery
 server 172.16.6.2

 Please see the output of hwclock and date at the same time.
 hwclock
 Sat 21 Nov 2009 08:19:02 PM IST  -0.496922 seconds

 date
 Sat Nov 21 20:19:55 IST 2009

 Please advice what I need to do to fix this error.

 Regards
 Ankush


Because you are using VMware you must become very familiar with how
timekeeping works on computer systems.  VMware has some helpful guides
on this:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427
http://www.vmware.com/pdf/vmware_timekeeping.pdf
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system time automatically fowards in time and then comes back to normal

[Eero Volotinen]

ankush grover wrote:
 Hi friends,
 
 I am running Nagios 2.7-1 on Centos 5.0 32-bit hosted on Vmware ESX
 4.0. The issue I am seeing on the server is sometimes nagios is
 showing the below messages in /var/log/messages and as the system time
 gets changed some false alarms gets generated. I searched it on the
 google but I am not able to find the correct solution. I even posted
 on the nagios forum and they asked me to see elsewhere why the server
 shitfs so much before looking at nagios.

Well, VMWare ESX sometime causes time jumps ;)

Possibly your service provider is overbooking cpu time of that ESX host ..

--
Eero
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos