Hi Bill,

Thanks for your comments.

I was stress testing, basically running these pair of commands in a loop every 
10 seconds.
--
chronyd -q -u ntp "server $first iburst"
...
chronyd -u ntp
--

I take it this is an "unusual" situation, but if a hang can happen, it will 
happen when you don't want it to.

BTW, if I do this with a pre-populated /etc/chrony.conf
--
chronyd -q -u ntp
...
chronyd -u ntp
--
The hangs do not occur since multiple sources are always involved, but it takes 
6-7 seconds to complete instead of 4 with a single server, for reference sntp 
does it in about 2 seconds.

Lonnie

BTW, my office NTP server (aggregates 2 external Stratum 1 and a local GPS 
network server) is an old Soekris net5501 (AMD Geode LX) and chrony results in 
much less jitter than ntpd did, very nice !




On Nov 30, 2016, at 8:07 PM, Bill Unruh <un...@physics.ubc.ca> wrote:

> 
> On Wed, 30 Nov 2016, Lonnie Abelbeck wrote:
> 
>> HI,
>> 
>> We are in the process of moving from 'ntp' to 'chrony' for our open source 
>> project.
>> 
>> In a matter of a few hours, I have made the conversion, including testing by 
>> booting without a network connection, restart chrony every 10 seconds for a 
>> 100+ times, etc .
>> 
>> I am very impressed with 'chrony' !
>> 
>> Though we have one issue uncovered during testing.
>> 
>> First, a little background, previously we used this sequence at boot time to 
>> set a big jump, then maintain the clock:
>> ----
>> first="$(awk '/^server / { print $2; nextfile; }' /etc/ntpd.conf)"
>> ...
>> sntp -S -t4 $first
>> ...
>> ntpd -g -c /etc/ntpd.conf
>> ----
>> 
>> This is how we are doing it now with chrony:
>> ----
>> first="$(awk '/^(server|pool) / { print $2; nextfile; }' /etc/chrony.conf)"
>> ...
>> chronyd -q -u ntp "server $first iburst"
>> ...
>> chronyd -u ntp
>> ----
>> 
>> What we would like is a "-t timeout" option to be used with "chronyd -q ..." 
>> just like sntp's -t option.  I have seen cases where "chronyd -q ..." hangs 
>> without a timeout.
>> 
>> The last thing we want to for chronyd to hang at boot time, and it can 
>> without such a timeout option, here are some logs...
>> 
>> 2016-11-30T18:50:24Z chronyd version 2.4.1 starting (+CMDMON +NTP +REFCLOCK 
>> +RTC +PRIVDROP -SCFILTER -SECHASH +ASYNCDNS -IPV6 -DEBUG)
>> 2016-11-30T18:50:24Z Initial frequency -17.442 ppm
>> 2016-11-30T18:50:26Z Received KoD RATE from 138.68.46.177, burst sampling 
>> stopped
>> (Hung for minutes or longer, a ^C was require to continue)
> 
> What are you doing to get a KoD? The intial burst should only be very brief
> and with something like 3 samples. More is not really needed.
> 
> 
>> 
>> 2016-11-30T18:43:30Z chronyd version 2.4.1 starting (+CMDMON +NTP +REFCLOCK 
>> +RTC +PRIVDROP -SCFILTER -SECHASH +ASYNCDNS -IPV6 -DEBUG)
>> 2016-11-30T18:43:30Z Initial frequency -15.827 ppm
>> 2016-11-30T18:43:37Z Received KoD RATE from 67.4.147.175, burst sampling 
>> stopped
>> 2016-11-30T18:47:57Z No suitable source for synchronisation
>> (Worked)
>> 
>> 2016-11-30T19:11:01Z chronyd version 2.4.1 starting (+CMDMON +NTP +REFCLOCK 
>> +RTC +PRIVDROP -SCFILTER -SECHASH +ASYNCDNS -IPV6 -DEBUG)
>> 2016-11-30T19:11:01Z Initial frequency -17.331 ppm
>> 2016-11-30T19:11:01Z Received KoD RATE from 50.116.52.97, burst sampling 
>> stopped
>> (Hung for minutes or longer, a ^C was require to continue)
> 
> All of the above are linked to KoD. The remote system is objecting strenuously
> to the rate at which you are hitting them for sample.
> 
>> 
>> Does adding a "-t timeout" option to be used with "chronyd -q ..." sound 
>> reasonable ?  We would probably use -t 8 (in seconds) for the upper bound.
>> 
>> Thanks,
>> 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.

Reply via email to