| Re: [chrony-dev] "leapsectz" and leapsecond announce (was:refclock: Add a new "tai" option) |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
Le 12/10/2017 à 13:21, Miroslav Lichvar a écrit :
> On Thu, Oct 12, 2017 at 11:31:13AM +0200, FUSTE Emmanuel wrote:
>> One side question about "leapsectz" option: Does the use of the option
>> imply ignoring leap announcements from other ntp servers or sources ?
>> Which would imply that the timezone database MUST be maintained up to
>> date to honor any future leap ?
>>
>> Or leap announcement is taken into account but utc-tai offset lost in
>> case of a restart ?
>>
>> In any case, a little add to clarify this point would be great in the
>> "leapsectz" option documentation.
> Good questions. I'll add the following to the documentation:
>
> The specified timezone is not used as an exclusive source of
> information about leap seconds. If a majority of time sources
> announce on the last day of June or December that a leap second
> should be inserted or deleted, *chronyd* will accept it even if it
> is not included in the timezone.
Great ! Thank you.
> The TAI-UTC offset of the system clock will be wrong if the timezone
> is missing a (genuine) leap second. If it is a fake leap second, the
> clock will be twice (wrongly) corrected by one second.
>
So in the presence of a refclock with the "tai" option and after a leap
not present in the tz data but accepted because of a majority of other
sources /servers have announced it, the TAI-UTC offset will be wrong.
So what will be done with the refclock ?
- de-selected / ignored ?
- as it has a lower stratum, it could take precedence over the other ntp
sources and system time and served time will be re-offset-ed by 1s ?
Or (after re-reading your answer and what I write) the TAI-UTC offset
was run-time adjusted and is not wrong.
- and after a restart of chrony (leap happened event lost) ? => real
case of wrong TAI-UTC offset
A complete solution could be to save the "not present in the leapsectz
zone" leap event in a journal and increment/decrement the TAI-UTC offset.
At startup, or at next runtime check
- clear the journal if the event was added in the leapsectz zone by an
update to the local TZ database and reset TAI-UTC offset with the one
given by leapsectz zone
- or replay the event on top of the offset given by leapsectz zone to
get the right TAI-UTC offset
Last remaining corner cases (out of date TZ database and leap event
happening with chrony not running) would/could then be cleared with the
future "ntp extended information".
Being bitten by the phc2sys hardcoded TAI offset and not satisfied with
it's new way of remembering the offset (a combination of something like
the chrony "leapsectz" mechanism using the local TZ database and a
persistent learned offset) I am interested by the Chrony tai refclock
option on top of a PHC refclock.
Using the "pps" option on top of a PHC refclock has drawbacks but is
the more safe option in my case for now.
Emmanuel.
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.