| Re: [chrony-users] Quickly syncing time |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Tue, 9 May 2017, Deven Hickingbotham wrote:
On 5/9/2017 5:35 AM, Miroslav Lichvar wrote:
Unless the system will be offline for very long intervals (e.g.
months), in which it could gain a very large offset, which would take
too long to correct, or it can be suspended and resumed without an
RTC, it's better to limit the number of updates in which the clock is
allowed to be stepped.
So what would you recommend to get the system clock synced to within 0.01
seconds?
Just let chrony run. The only purpose of the makestep directive is to bring
the clock near the correct time quickly, instead of trying to slew away 25
years of time say because the system clock when it starts up is set to a date
25 years ago. After that initial step, chrony keeps adjusting the clock to
keep it near its source's idea of UTC. If the clock ever gets out by .01 sec
later on, then there is something wrong with your computer, or with the
sources you are using for chrony. Ie, makestop is purely to do something at
startup.
makestep 0.01 ??
How soon is the first update made? How long between updates? I'd like to
make sure chrony has run long enough so that it has identified the PPS as the
best time source.
It is a stratum 0 source, so chrony will, unless there is strong evidence to
the contrary, believe that is the best source. You can try it. Watch at
startup with chronyc the sources test and when PPS gets a * beside it, chrony
is using it as the time source.
Note that the main problem with pps is that it tells chrony exactly when the
transition at the top of the second takes place, it does not tell it which
second that was. Thus chrony needs some other source to tell it which second
it is. That is either an NMEA source from the GPS puck, or some other time
source. That is typically what takes the time. The NMEA source should be good
to go quickly. Note there is a danger to using something that gives more than
one pulse per second. The nmea source takes a long time to deliver its
information (up to many tens of ms or more) and the danger is that the nmea
labeling of the second occurs too late and another PPS pulse has arrived, and
it gets the label rather than the correct pulse. Ie, There is no advantage to
more than 1 pulse per second, and possible disadvantages. Some gps receivers
are so bad that they deliver the label over a second after the pulse which
really means that GPS is wrongly labeled. You could tell that by comparing
the output of the PPS with that of some outside clock.
(The time of receipt of the nmea label is the end of the nmea message, not
its beginning which adds many ms to the displacement of the time of the
label.)
The first update is made when chrony starts and manages to contact the
sources. The interval is the polling interval. (2^poll seconds). )
Deven
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.