Re: [chrony-users] Syncing time as with a single request

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ] 

Not my concerns, but trying to make sure you understand the consequences of
your decision. If what is most important is the speed of bootup, together with
the clock being roughly on time, then your solution is fine, assuming of
course that the system one happens to get from the pool say is itself roughly
on time, and is not way out. You have no safeguard against false tickers out
there. It might set you clock to 00:00 Jan1 1970, in which case chrony might
have a real problem getting you back on time once chrony starts running
(taking years if it tries to correct via slewing). But the probability of that
might be small enough that you need not worry about it. And the consequences
of that happening might be bearable (eg, no automatic launches of missiles or
the equivalent for your systems).




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 Sun, 1 Mar 2020, Lonnie Abelbeck wrote:


Hi Bill,

I appreciate your comments, but chronyd is called immediately after the foreground "chronyd -q ..." so that should mitigate your concerns.

Lonnie



On Mar 1, 2020, at 4:27 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

There is a battle between acuracy and speed. Your time might be synched, but
your rate may be way off. Thus your clock might lose 10 sec per minute with
your procedure. To get a good estimate for the rate you need to spend more
time. (with 4 sec you might reduce the rate to something like 20-200PPM from
true 1 sec per second ( I am assuming that the accuracy of your reading the
remote clock is something like 5 to 50 microseconds error.) Now you may not
care, which is fine, But you might, as soon as the system comes up, want to
find out the some elapsed time to high accuracy. Then this system is not
great. Of course if all you care is is that the the system is synced to one
second and the rate is correct to 1% is good enough. Then that is fine. But
you might want to go into your decisions with eyes open.



On Sun, 1 Mar 2020, Lonnie Abelbeck wrote:





On Jan 28, 2020, at 2:35 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

On Tue, Jan 28, 2020 at 04:11:49AM +0000, Gustav Krantz wrote:

Would it be possible to do the initial sync with a single request per server? If so how would this be done and what would the drawback be?


The current development code in git supports a single-sample
selection/update mode, enabled by setting maxsample to 1, but it's
meant to be used only in the "ntpdate" mode (-q/-Q option) as it
doesn't adjust the frequency of the clock. You could use it for the
initial correction before normally starting chronyd.

# chronyd -q 'pool pool.example.com maxsamples 1 iburst'



I have been testing this new "maxsamples 1" feature with the latest chrony-master.tar.gz snapshot of 2020-02-19.

Works very nicely.  Our project first does a quick foreground "chronyd -q ..." step (historical from sntp/ntpdate days) and then followed by a background chronyd .

With "maxsamples 1", our boot times are 4-6 seconds faster.

Using time.cloudflare.com, the step is performed in about 230 ms.  (versus 4.4 seconds before)
--
pbx4 ~ # time chronyd -q -t 8 "server time.cloudflare.com maxsamples 1 iburst"
2020-03-01T21:31:53Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG)
2020-03-01T21:31:53Z Initial frequency -17.927 ppm
2020-03-01T21:31:53Z System clock wrong by -0.000330 seconds (step)
2020-03-01T21:31:53Z chronyd exiting

real	0m0.229s
user	0m0.006s
sys	0m0.005s
--

While testing, a '-t 8' is needed since DNS errors/misconfigurations can cause "chronyd -q ..." to hang, seemingly forever.

Example, using a typo .con instead of .com ... Control-C'ed to quit:
--
pbx4 ~ # time chronyd -q "server time.cloudflare.con maxsamples 1 iburst"
2020-03-01T21:34:23Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG)
2020-03-01T21:34:23Z Initial frequency -17.927 ppm
^C2020-03-01T21:41:07Z chronyd exiting

real	6m43.632s
user	0m0.003s
sys	0m0.010s
--

Adding the '-t 8' guards against those special DNS issues, without it a box could hang at startup.  Example, same typo with a '-t 8':
--
pbx4 ~ # time chronyd -q -t 8 "server time.cloudflare.con maxsamples 1 iburst"
2020-03-01T21:41:38Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG)
2020-03-01T21:41:38Z Initial frequency -17.927 ppm
2020-03-01T21:41:46Z chronyd exiting

real	0m8.014s
user	0m0.002s
sys	0m0.009s
--

Lonnie



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






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

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/