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 <un...@physics.ubc.ca> 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 <mlich...@redhat.com> 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-requ...@chrony.tuxfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > > > -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
