Re: [chrony-dev] Handling of leap seconds
On Wed, Mar 25, 2020 at 01:14:29PM +0800, Dennis Law wrote: > Hello Miroslav, > > I have a follow up question regarding this. I found that the > REF_IsLeapSecondClose() function uses the system time to check if a leap > second occurrence is close. > Under the circumstances whereby system time has not yet synchronized, > wouldn't it be more correct to use timestamp from time sources for this > check? The function checks the system time and the NTP time it is tracking. If the client was started in those 5 seconds around leap and had a significant offset, it could accept a bad sample, which could cause it to take longer to synchronize. I'll extend the check to include the sample time. Thanks, -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Handling of leap seconds
Hello Miroslav, I have a follow up question regarding this. I found that the REF_IsLeapSecondClose() function uses the system time to check if a leap second occurrence is close. Under the circumstances whereby system time has not yet synchronized, wouldn't it be more correct to use timestamp from time sources for this check? On Tue, Mar 10, 2020 at 3:15 PM Dennis Law wrote: > Hello Miroslav, > > Thank you for the clarification. This makes sense now. I was just > wondering why this 5 second check is there and could not figure out why. > > Thank you. > > > On Thu, 5 Mar 2020, 11:49 pm Miroslav Lichvar, > wrote: > >> (replying from an archive) >> >> On Sun, 01 Mar 2020, Dennis Law wrote: >> > It seems that when the program finds out about a leap second >> > occurrence too close to the occurrence itself (within 5 seconds), it >> > simply does not attempt to correct it. >> > >> > From my understanding from the code, the program should be able to >> > handle leap seconds even right before before it occurs, as it simply >> > schedules a timeout at either 00.00.00 (insertion) or 23:59:59 >> > (deletion). >> > >> > What is then the reason for the 5 seconds check? Am I missing >> > something obvious here? >> >> It prevents measurements from being accumulated and also prevents >> changes in the leap second status. The reason is that all kind of >> weird things may happen around the leap second (e.g. mixing of >> pre-leap and post-leap timestamps causing errors in the offsets, leap >> bits being set/cleared prematurely), so it's better to let it coast >> through. >> >> Leap seconds are normally announced by reference clocks at least an >> hour before the event. Is the 5 second check causing you some issues? >> >> -- >> Miroslav Lichvar >> >> >> -- >> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with >> "unsubscribe" in the subject. >> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in >> the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >>
Re: [chrony-dev] Handling of leap seconds
Hello Miroslav, Thank you for the clarification. This makes sense now. I was just wondering why this 5 second check is there and could not figure out why. Thank you. On Thu, 5 Mar 2020, 11:49 pm Miroslav Lichvar, wrote: > (replying from an archive) > > On Sun, 01 Mar 2020, Dennis Law wrote: > > It seems that when the program finds out about a leap second > > occurrence too close to the occurrence itself (within 5 seconds), it > > simply does not attempt to correct it. > > > > From my understanding from the code, the program should be able to > > handle leap seconds even right before before it occurs, as it simply > > schedules a timeout at either 00.00.00 (insertion) or 23:59:59 > > (deletion). > > > > What is then the reason for the 5 seconds check? Am I missing > > something obvious here? > > It prevents measurements from being accumulated and also prevents > changes in the leap second status. The reason is that all kind of > weird things may happen around the leap second (e.g. mixing of > pre-leap and post-leap timestamps causing errors in the offsets, leap > bits being set/cleared prematurely), so it's better to let it coast > through. > > Leap seconds are normally announced by reference clocks at least an > hour before the event. Is the 5 second check causing you some issues? > > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-dev] Handling of leap seconds
(replying from an archive) On Sun, 01 Mar 2020, Dennis Law wrote: > It seems that when the program finds out about a leap second > occurrence too close to the occurrence itself (within 5 seconds), it > simply does not attempt to correct it. > > From my understanding from the code, the program should be able to > handle leap seconds even right before before it occurs, as it simply > schedules a timeout at either 00.00.00 (insertion) or 23:59:59 > (deletion). > > What is then the reason for the 5 seconds check? Am I missing > something obvious here? It prevents measurements from being accumulated and also prevents changes in the leap second status. The reason is that all kind of weird things may happen around the leap second (e.g. mixing of pre-leap and post-leap timestamps causing errors in the offsets, leap bits being set/cleared prematurely), so it's better to let it coast through. Leap seconds are normally announced by reference clocks at least an hour before the event. Is the 5 second check causing you some issues? -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
