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
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] "leapsectz" and leapsecond announce (was:refclock: Add a new "tai" option)
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Thu, 12 Oct 2017 15:46:48 +0200
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@xxxxxxxxxx
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D1D567F3FB
On Thu, Oct 12, 2017 at 03:12:19PM +0200, FUSTE Emmanuel wrote:
> Le 12/10/2017 à 13:21, Miroslav Lichvar a écrit :
> > 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 ?
The refclock will be off by one seconds. If there are at least two
good sources, it will be marked as a falseticker and 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.
The offset will be wrong. There is no adjustment of the TAI-UTC offset
which is used for correcting refclock offset. The local TAI-UTC offset
is adjusted after a leap second, but it will be overwritten on the
next clock update with the incorrect value from tzdata.
> - and after a restart of chrony (leap happened event lost) ? => real
> case of wrong TAI-UTC offset
Restart shouldn't make a difference.
> 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
What if a fake leap second was accepted? This sounds too complicated
and fragile to me.
If using leapsectz and refclock with tai option, I think the
requirement should be to keep tzdata up to date.
--
Miroslav Lichvar
--
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.