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

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


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.


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