[Ntp] Antwort: Re: [NTP] Draft "On Implementing Time"

[[e-mail]]

Hi,

I will add some additional to Tal's and Kristof's comments to the draft 
"draft-aanchal-time-implementation-guidance-00".


Clause 2:
- UTC is not a time but a time scale
- UTC is steered towards UT1 and not solar time. See e.g. Sec. 4.6 of the 
BCP (https://tools.ietf.org/html/draft-ietf-ntp-bcp-05#section-4.6).
- The explanation of UTC seems to me much too over-simplified. This should 
be dropped. Instead you could quote the definition of UTC given by the 
BIPM:
"The UTC scale is adjusted from International Atomic Time (TAI) by the 
insertion of leap seconds according to the advice of the International 
Earth Rotation and Reference Systems Service (IERS) to ensure approximate 
agreement with the time derived from the rotation of the Earth." 
[Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ]. 

Alternatively you could quote the ITU recommendation 
"Coordinated Universal Time (UTC): The time-scale maintained by the Bureau 
International des Poids et Mesures (BIPM) and the International Earth 
Rotation and Reference Systems Service (IERS), which forms the basis of a 
coordinated dissemination of standard frequencies and time signals." 
[Citation: ITU-R TF.686-3:(12/2013)].

Clause 2.2
- As Tal already mentioned, a clear definition of the used nomenclature is 
necessary. Tal mentioned Dave's definition, which of course is correct. 
But, since this documents aims to give general guidance in the field of 
the timing, I suggest to adjust your language to the ITU recommendations 
ITU-R TF.686-3:(12/2013). Hence, 
- using "frequency difference" if you speak of clocks whose frequencies 
differ,
- using "frequency drift" if you mean the change of a clock's frequency 
over time (the first derivative of the frequency).

I would recommend not to use NTP as an example in 2.2 since NTP does not 
provide a mean to synchronize the frequency of a clock. Instead it adjust 
the clock's frequency in order to synchronize the clock's time. That is a 
different goal and is therefore not comparable.

You could use the term "Syntonization" [ITU-R TF.686-3:(12/2013)], if you 
mean the adjustment of the clock's frequency.

PTP does provide a syntonization mode. Thus, you might use PTP as an 
example in this section.

Clause 2.3.
I don't like the term "Real time". It sounds like Real Time Clock (RTC) 
which you would call "Raw time" (if I understand it right).

This in short. I hope this might be useful.

Dieter






"ntp" <[e-mail]> schrieb am 16.11.2017 10:20:57:

> Von: Martin Hoffmann <[e-mail]>
> An: [e-mail]
> Kopie: [e-mail]
> Datum: 16.11.2017 10:21
> Betreff: Re: [Ntp] [NTP] Draft "On Implementing Time"
> Gesendet von: "ntp" <[e-mail]>
> 
> Hi Kristof,
> 
> [e-mail] wrote:
> > 
> > I have just given a read to the "On Implementing Time" draft (
> > 
https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes
> > ). 
> > There are a few issues that I'd like to raise.
> 
> Many thanks for reading the document and sharing your thoughts!
> 
> > (1) Vocabulary (technical): use of the term "time"
> > - Description: I take issue with not explaining what the document
> > means when in uses the term "time", specifically "a <property> time",
> > when properties like continuous, monotonic (separate issue, see
> > below) are assigned. In these cases, it is heavily implied the "a
> > time" is supposed to be a function (because the cited properties are
> > usually applied to functions), but this is never stated, which I find
> > problematic. For example, I still need to figure out what the domain
> > and co-domain of the function are supposed to be. Naively I would
> > assume that the co-domain is a subset (probably implementation
> > specific) of "int" or "float". I would then assume that the domain
> > is... well, "actual" time. Which brings me to my next issue with the
> > used terminology: "time" becomes an overloaded term, it represents
> > the abstract heuristic concept and then also some kind of function
> > from this concept to a machine-appropriate value set.
> > - Suggested remedy: edit the terminology to be consistent,
> > - Specific suggestions for the remedy (even if this is deemed 
> > insufficient, I still strongly advocate trying to implement the
> > remedy in some other way):
> >   -- "Time" remains as the abstract heuristic concept (and is not 
> > explained in the document).
> >   -- The kind of value that a machine can read and communicate (for 
> > example a timestamp) could be called a "clocktime". The document
> > should state this somewhere. How exactly "clocktime" is realized
> > (int, float, ...) is implementation specific. The document might or
> > might not go into that detail.
> >   -- The function that maps the current "time" to a "clocktime" is
> > called a "clock". The document should state this somewhere.
> 
> The draft already somewhat distinguishes between the two "classes" of
> definitions--wall time on the one side and the three remaining ones on
> the other, even if it doesn?t call out that distinction. I think we can
> make this more obvious by simply using the word "clock" instead of
> "time" for the three concrete representations of time available to a
> system.
> 
> We?ve been debating to what extent we should discuss the, for lack of a
> better term, philosophical background of time, keeping in mind our
> target audience. On the one hand, this is all very important and
> interesting, on the other hand, we don?t want to scare away people
> starting out with a lengthy treatise. 
> 
> > (2) Vocabulary (more editorial, with some technical implications):
> > use of the term "continuous"
> > - Description: since the co-domain of a "clock" (current term in the 
> > document is "time", see above) is necessarily a discrete set, the
> > notion of "continuity" causes some problems, since the usual
> > definitions don't easily apply (basically, the function always has
> > "jumps" in it, due to the discrete nature of the co-domain).
> > - Suggestion: clean up the terminology and make it consistent, OR
> > just dumb it down.
> > - Specific suggestion (clean-up): have "continuous" mean that the
> > function does not exhibit jumps greater than the "resolution" of the
> > co-domain. Use epsilon-delta definition, but loosen it to epsilon
> > greater than or equal to <resolution>. Note that this might require
> > quite a lot of thougfht to get right.
> > - Specific suggestion (dumb-down): simply state that "continuous"
> > shall mean that the function "has no substantial jumps", or something
> > along those lines.
> 
> My gut-feeling is that, again, with respect to the intended audience,
> we could probably keep this relatively informal. As a consequence, we
> should probably avoid the term "continuous" altogether. Perhaps
> the introduction of drift can move up to the introduction of the raw
> clock, discussing how the time perceived by the system and expressed
> via the raw clock differs from passage of wall time. It just felt
> better to do this as part of the introduction of adjusted raw time
> from a narrative perspective.
> 
> > (3) Vocabulary (technical and editorial): use of the term "monotonic" 
> > - Description: Although I acknowledge that in 2.1, the draft gives
> > a(n implicit) definition of what it refers to when it uses the term 
> > "monotonic" (i.e. "continuous and strictly monotonically
> > increasing"), I still do not like it.
> 
> This mention comes from the "monotonic clock" defined as one of the
> clock types in POSIX with a rather vague definition (leaving it
> unclear whether it refers to a raw clock or adjusted raw clock in
> our sense). As a result of that appearance, many people seem to use the
> term. I guess this warrants a longer discussion than just a drive-by
> mention.
> 
> > If there is interest (if the current editors think it would make
> > things easier and not harder), I guess I would offer to work on the
> > draft as an additional editor.
> 
> Many thanks for your kind offer. We?d be delighted to welcome you as
> an additional editor!
> 
> Kind regard,
> Martin
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp