[chrony-dev] "leapsectz" and leapsecond announce (was:refclock: Add a new "tai" option)

[FUSTE Emmanuel]

> It is also possible that a leap second is subtracted rather than added, and
> the code should take that into account. (But by now, it is doubtful that any
> negative leap seconds will occur in the future, unless perhaps there are a
> bunch of really powerful earthquakes which change the moment of intertia of
> the earth.
>
Which is possible crazy people with nuclear power in hand...

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.

Emmanuel.N�r��y隊W!���u��z!�_jh�ʊ��+a�{.n�+�^���y�E��^���j)\��'�ׯ���z�\��'�۱}���*+�����)���.n7��:蹹^f��X��f���܆�'�۱}���*+

Re: [chrony-dev] "leapsectz" and leapsecond announce (was:refclock: Add a new "tai" option)

[FUSTE Emmanuel]

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-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] "leapsectz" and leapsecond announce

[FUSTE Emmanuel]

Le 12/10/2017 à 15:46, Miroslav Lichvar a écrit :
> 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.
OK
>> - 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.
OK
>> 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.
I was confident that all necessary counter measures/dispositions are 
taken on Chrony to minimize false leap second.
Anyway, if accepted/played, damage is done TAI offset updated or not. 
(In this case, in my previous "plan" zap the journal created at "leap 
event play time" manually)
>
> If using leapsectz and refclock with tai option, I think the
> requirement should be to keep tzdata up to date.
>
Fair enough ! (a little note should be added too to the tai option).

Thank you.
Emmanuel.
--
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] new feature request: add "fast" and "slow" to "clock wrong" and "clock stepped" log messages

[FUSTE Emmanuel]

Le 30/10/2017 à 19:42, Denny Page a écrit :
> FWIW, I believe “ahead” and “behind” are the most clear in speaking to the 
> condition before initiating a correct. “Fast” and “Slow” somewhat imply an 
> ongoing condition that may or may not be true. It could be the accuracy of 
> setting the RTC before reboot for instance.
>
>  System clock ahead by ?.
>  System clock behind by ?.
>
> Denny
>
I second you:

For system logs messages
"ahead" / "behind" for offset
"fast" / "slow" for freq

measurements.log are already totally unambiguous/perfectly specified.

Emmanuel.
>> On Oct 30, 2017, at 04:07, Miroslav Lichvar  wrote:
>>
>> On Fri, Oct 27, 2017 at 10:31:16AM -0600, James Feeney wrote:
>>> How about, rather than using the term "wrong", instead use the terms "fast" 
>>> and "slow" to describe this quantity "1.693005 seconds"?  Then the log 
>>> message might read:
>>>
>>> chronyd[622]: System clock fast by 1.693005 seconds, adjustment started
>>>
>>> or
>>>
>>> chronyd[622]: System clock slow by 1.693005 seconds, adjustment started
>> I agree this would be much clearer for the user. I never remember
>> which sign is for fast and slow in what context (it's not consistent
>> unfortunately). The trouble is that it would break existing scripts
>> that parse the log and the parsing itself would be more difficult if
>> it had to look for the word "slow" or "fast" instead of the sign. I'm
>> not sure how important that really is.
>>
>> Do you think it would make sense to keep the sign and indicate whether
>> it's fast or slow in parentheses?
>>
>> System clock wrong by +/-?.??? (slow/fast) ?
>>
>> System clock stepped by +/-?.??? (forward/backward) ?
>>
>> There are other messages that print an offset, so maybe they could be
>> all changed at once to keep it consistent.
>>
>> What do others think?
>>
>> -- 
>> 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.
>>
>

[chrony-dev] subscribe

[FUSTE Emmanuel]

--
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.

[chrony-dev] chrony.keys extension relevance

[FUSTE Emmanuel]

Hello,

As there is still a long road before NTS, is there any rationale to not 
implement something like an optional by key ip list like in the ntpd 
ntp.keys format ?
In the case of chrony, it could be a list of subnets of the same format 
as in the allow/deny directives.

Emmanuel.

Re: [chrony-dev] chrony.keys extension relevance

[FUSTE Emmanuel]

Le 24/01/2018 à 17:29, Miroslav Lichvar a écrit :
> On Wed, Jan 24, 2018 at 04:58:04PM +0100, FUSTE Emmanuel wrote:
>> As there is still a long road before NTS, is there any rationale to not
>> implement something like an optional by key ip list like in the ntpd
>> ntp.keys format ?
>> In the case of chrony, it could be a list of subnets of the same format
>> as in the allow/deny directives.
> In what cases it would be useful?
With the detailed below explanations, none.

>
> With ntpd as a client it's necessary to specify the IP address of the
> server in the key file to prevent its own clients (which have a
> different key) from performing a MITM attack on the server. With
> chronyd as a client this is not necessary as it checks the key ID in
> all responses it receives.
>
> The extended key file makes some sense with emphemeral associations,
> which have no peer directive in the config file where the key could be
> specified. chronyd does not support ephemeral associations.
>
> As a server, chronyd authenticates responses with any key the client
> can authenticate the request with. If I give a client a key, does it
> matter from which address it is sending requests authenticated with
> that key?
No, you're right

Thank you
Emmanuel.

Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

[FUSTE Emmanuel]

Le 13/03/2018 à 19:57, Christian Ehrhardt a écrit :
>
>
> On Tue, Mar 13, 2018 at 5:54 PM, Bill Unruh  > wrote:
>
> [17:25] * cpaelzer fails at explaining it seems
> [17:25]  if you deploy chrony to a random system
>
>
> If you have a random system and you have no idea whether or not
> its clock is
> good or a complete piece of merde, why would you want it acting as
> a server
> for anything? That is liable to cause mass confusion to the
> clients who have
> no idea whether or not to trust their server.
>
>
> Sorry, it was just a simplification to explain more easily.
> This is not an important detail to the discussion itself IMHO, but for 
> the sake of completeness, something like:
> s/random/a system where you have no means to check/ensure that either 
> on install time or for the lifetime of the system it will have the 
> capability to adjust the local clock. But even in case it's clock 
> would be a piece of merde let it get somewhat reliable time from 
> network sources and spread that locally to some peers to keep them in 
> sync among each other/
>
>
Reading more and more, I could not stay silent more time.
This way of thinking/doing things is completely mad.
Now we all need a GNSS receiver because people will happily spread crapy 
time even without knowing.
The -x is already highly questionable, but you're supposed to know what 
you do when using it.
Throwing things (what thing it is) away that "just seems to work" is a 
very very bad thing.
I'm sorry, but I still don't understand why/when this -X would be 
useful. And even if you give me a valid real case, it will only 
demonstrate that the real problem/needs are being tackled the wrong way.
We have a not politically correct dark humor expression for this in 
French: No hand, no chocolate.

Emmanuel.

Re: [chrony-dev] [PATCH v4 0/3] chrony in environments unable to adjtime

[FUSTE Emmanuel]

Le 14/03/2018 à 15:05, Christian Ehrhardt a écrit :
> There are several conditions which make running chrony in containers a pain
> today and this series tries to provide means to handle that.
>
>
What is the real use case of Chrony in a container ?
Why do you want to do that ?
> Until time namespaces are implemented
This is a completely crazy idea. I hope we will never get there. For 
what ? To push the container concept ad nauseam because this is the 
actual fashion ?

Please explain. For now, is seems that you are properly doing things but 
for a wrong reason.

Emmanuel.
N�r��y隊W!���u��z!�_jh�ʊ��+a�{.n�+�^���y�E��^���j)\��'�ׯ���z�\��'�۱}���*+�����)���.n7��:蹹^f��X��f���܆�'�۱}���*+

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 16/08/2018 à 09:40, Miroslav Lichvar a écrit :
> I was planning to make a new release in about a month, depending on
> how much time I'll have for chrony. There is just one new feature left
> on my todo list and then I'll be writing tests for the new code, etc.
>
> If people think it's important enough, I could make a quick 3.3.1 bug
> fix only release. I'm not sure.
>
Hello Miroslav,

Semi off-topic question:
As you are doing refactoring to share more code between ntp source and 
refclocks,
have you on your todo list for a future release some work around orphan 
mode and refclocks ?
Taking refclocks into account as other ntp sources for the orphan mode 
is the only feature I a missing from ntpd in my use case.

Regards
Emmanuel.

N�r��y隊W!���u��z!_jh�ʊ��+a�{.n�+�^���y�E��^���j)\��'�ׯ��z�\��'�۱}���*+�����)��.n7��:蹹^f��X��f���܆�'�۱}���*+

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 16/08/2018 à 10:10, Miroslav Lichvar a écrit :
> On Thu, Aug 16, 2018 at 07:53:24AM +0000, FUSTE Emmanuel wrote:
>> have you on your todo list for a future release some work around orphan
>> mode and refclocks ?
> I wasn't planning anything in that area.
>
>> Taking refclocks into account as other ntp sources for the orphan mode
>> is the only feature I a missing from ntpd in my use case.
> Could you please be more specific? I'm not sure what an orphan
> refclock would be or what is the use case.
>
Example:
Organization network not connected to Internet.
Time given by HW clocks (GNSS / radio clock / rubidium osc or whatever 
else) and distributed on a dedicated L2 PTP network.
NTP servers pool connected to the PTP network and to the organization 
network.
Each server use the GM on the PTP network.
Each server in the pool are declared as ntp source for the other servers.
Orphan mode is activated.

With ntpd, as long as my refclock is running all work normally.
If I lost my PTP switch, orphan mode kick in and all the servers in the 
pool serve a coherent time.

With chrony, as refclocks are not taken into account in the orphan mode 
decision (status of the refclock, stratum) and as I am not using other 
externals NTP sources I am always in orphan mode.

Emmanuel.

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 16/08/2018 à 10:57, Miroslav Lichvar a écrit :
> On Thu, Aug 16, 2018 at 08:47:16AM +0000, FUSTE Emmanuel wrote:
>> NTP servers pool connected to the PTP network and to the organization
>> network.
>> Each server use the GM on the PTP network.
> The servers have a SHM reference clock providing the PTP time (e.g.
> phc2sys)?
Yes.
>> With ntpd, as long as my refclock is running all work normally.
>> If I lost my PTP switch, orphan mode kick in and all the servers in the
>> pool serve a coherent time.
>>
>> With chrony, as refclocks are not taken into account in the orphan mode
>> decision (status of the refclock, stratum) and as I am not using other
>> externals NTP sources I am always in orphan mode.
> I'm not sure what is the difference here. The orphan mode should be
> active, but with chrony it's not? I.e. the servers are still
> synchronized to their SHM refclocks and don't want to select a server
> to which all others should synchronize?
No, with chrony the shm refclock seems to be ignored (need to retest 
precisely) . The observed stratum of my chrony servers were not 
refclock+1 (0+1) but the defined orphan stratum (3).
Last time I checked this, it was on an internet connected pool of two 
servers with ptp refclock, and public ntp sources (pool.ntp.org) and it 
exhibit the same behavior. The stratum of the chrony servers were orphan 
stratum or the stratum of a selected Internet ntp source + 1 (if lower 
than the ophan one) but not the shm + 1 one.
Will redo some tests if you want.

Emmanuel.

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 16/08/2018 à 11:40, Miroslav Lichvar a écrit :
> On Thu, Aug 16, 2018 at 09:23:06AM +0000, FUSTE Emmanuel wrote:
>> No, with chrony the shm refclock seems to be ignored (need to retest
>> precisely) . The observed stratum of my chrony servers were not
>> refclock+1 (0+1) but the defined orphan stratum (3).
> Oh, you mean the servers were not synchronized to their SHM refclocks
> even when they were working correctly? And removing the orphan option
> from chrony.conf fixed that?
Exactly
>
> That sounds like a bug. If you have a reproducer or have more details,
> please let us know.
>
Ok, will find time to redo some tests and report here.
Thank you.

Emmanuel.

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 16/08/2018 à 11:43, FUSTE Emmanuel a écrit :
> Le 16/08/2018 à 11:40, Miroslav Lichvar a écrit :
>> On Thu, Aug 16, 2018 at 09:23:06AM +0000, FUSTE Emmanuel wrote:
>>> No, with chrony the shm refclock seems to be ignored (need to retest
>>> precisely) . The observed stratum of my chrony servers were not
>>> refclock+1 (0+1) but the defined orphan stratum (3).
>> Oh, you mean the servers were not synchronized to their SHM refclocks
>> even when they were working correctly? And removing the orphan option
>> from chrony.conf fixed that?
> Exactly
>> That sounds like a bug. If you have a reproducer or have more details,
>> please let us know.
>>
> Ok, will find time to redo some tests and report here.
> Thank you.
Hello,

Tested rapidly with chrony git master of June 22. Work as expected ! If 
it was a bug, it is gone.
Will do some more tests with shm refclock and with lost of ptp link as 
the actual test is with a PHC type refclock.
(A status positioned by writer/ptp4l , readable by the PHC device 
consumers, and reset on writer close  would be great to alleviate the 
use of shm/phc2sys)

Emmanuel.

Re: [chrony-dev] When will chrony release next?

[FUSTE Emmanuel]

Le 17/08/2018 à 12:38, FUSTE Emmanuel a écrit :
> Le 16/08/2018 à 11:43, FUSTE Emmanuel a écrit :
>> Le 16/08/2018 à 11:40, Miroslav Lichvar a écrit :
>>> On Thu, Aug 16, 2018 at 09:23:06AM +0000, FUSTE Emmanuel wrote:
>>>> No, with chrony the shm refclock seems to be ignored (need to retest
>>>> precisely) . The observed stratum of my chrony servers were not
>>>> refclock+1 (0+1) but the defined orphan stratum (3).
>>> Oh, you mean the servers were not synchronized to their SHM refclocks
>>> even when they were working correctly? And removing the orphan option
>>> from chrony.conf fixed that?
>> Exactly
>>> That sounds like a bug. If you have a reproducer or have more details,
>>> please let us know.
>>>
>> Ok, will find time to redo some tests and report here.
>> Thank you.
> Hello,
>
> Tested rapidly with chrony git master of June 22. Work as expected ! If
> it was a bug, it is gone.
> Will do some more tests with shm refclock and with lost of ptp link as
> the actual test is with a PHC type refclock.
> (A status positioned by writer/ptp4l , readable by the PHC device
> consumers, and reset on writer close  would be great to alleviate the
> use of shm/phc2sys)
>
> Emmanuel
And I confirm. It was an old and now gone bug.
All is working as expected.

Thank you.
Emmanuel.N�r��y隊W!���u��z!_jh�ʊ��+a�{.n�+�^���y�E��^���j)\��'�ׯ��z�\��'�۱}���*+�����)��.n7��:蹹^f��X��f���܆�'�۱}���*+