Subject: Re: [art] Fwd: New Version Notification for draft-touch-time-05.txt

From: Joe Touch <[email-masked]>
Date: Sat, 9 Nov 2019 09:21:39 -0800

Hi, Tony,

While addressing these comments, I had a few notes below.

Joe

On 9/13/2019 12:41 PM, Tony Finch wrote:
...
>    o  Ordering: to determine the relative sequence of events across
>       systems, such as with Lamport clocks [La78] or Vector clocks
>       [Fi88][Ma88].
>
> Lamport clocks and vector clocks don't use time, but the section heading
> implies that they do.

It depends on how you interpret 'time'. If it's a sequence of labels
used for absolute and relative ordering, then they are. They're just not
continuous with respect to "natural time", but then nearly all time
scales have that property in one way or another.

>    o  NTP [RFC5905]: the Network Time Protocol, used in the Internet to
>       synchronize local clocks, in which dates are indicated by UTC
>       values. NTP times track the time of the clock they connect to.
>
> NTP uses a unix-style count of seconds so it isn't able to represent UTC
> values.

The doc describes the time NTP provides not its representation in its
protocol messages. It claims to sync within a few ms of UTC.

>  The NTP leap indicator bits are not synchronized with the
> occurrence of leap seconds so they don't disambiguate leapy timestamps.
> https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

This is an issue with the protocol - that's not the focus of this doc.

> 4.3. Comparison of properties
>
> Should the discussion of GLONASS etc. be moved to section 5 before the
> table in which they occur?

It was left where it is; the table is just a summary of those systems.

> Should PTP be added to the list of time scales? (Given section 7 talks
> about selecting timescales I think it's worth pointing out one that is of
> practical use in computing, as opposed to TAI which is a retrospective
> paper clock.)

PTP isn't a time scale; it's a system for reporting time. The problem is
it reports multiple timescales that are already discussed.

I.e., the doc talks about time scales and systems that report ONE
timescale; not all protocols for representing or syncing timescales.

>    Unix time does not specify the definition of a 'second' or 'day',
>    and so it is not clear whether it intends to track SI seconds (where
>    time would be uniform) or solar time (where it would not).
>
> Unix time is defined in terms of struct tm fields, which are a
> representation of a UTC time stamp. It explicitly says it doesn't
> specify any relationship to real civil time.

Civil time is neither SI nor solar. The statement above explains that
even the duration of a second or day isn't defined for Unix time.

> ...
>
> Google deployed leap smear in 2011 (not 2017 as your reference states) and
> they weren't the first to propose it.

2017 is the date of the published archival reference. That's not a
statement of when it was deployed, which this document doesn't include.

> 7.2. Hazards of some time scales
>
> It's worth mentioning that if you aspire to representing UTC correctly
> then it cannot be done as a simple count of seconds, and Unix and NTP are
> shining examples of getting it wrong.
>
> There should be a discussion of leap-second-related hazards in Unix time
> and NTP.
This isn't a time protocol design doc or advice on which protocol to
use; it is advice on how to pick a time scale.
> The draft seems to give the impression that leap smear is a Google
> peculiarity, but there are several other organizations doing it (see the
> link to the leapsecs list above).

It mentions Google only as notable examples.

--

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Nov 2019 14:37:33 +0000

Joe Touch <[email-masked]> wrote:
> ....
> It depends on how you interpret 'time'.

I meant in the usual sense, as implied by the draft's terminology section.

> protocol messages. It claims to sync within a few ms of UTC.

Your wording "UTC values" to me implies a vague description of the
representation of the timestamps. Perhaps you could re-word it to make it
clear that you meant something else.

> it reports multiple timescales that are already discussed.

The impression I get is that although PTP can transport different
timescales, it almost always uses a specific one which is different from
the other ones in the draft. (It differs from Unix time by the number of
leap seconds.)

It's a widely-available timescale, like many of the others listed in that
section, and I think readers would be surprised that it isn't listed in a
draft that's providing advice on choosing timescales.

> even the duration of a second or day isn't defined for Unix time.

The problem with that paragraph is it sets up a false dichotomy. Unix time
does not intend to track solar time nor SI seconds, it tracks civil time,
which is a different third option. Leaving that option out is misleading.

> statement of when it was deployed, which this document doesn't include.

   [Go17]    Google's approach to NTP leap smearing, proposed in 2017.
             https://developers.google.com/time/smear

The date 2017 doesn't appear on that page, and the page itself says
deployed in 2008 so I'm not sure why you say it isn't included. (I think I
got 2011 from my mail archives...) The reference doesn't match the title
nor the contents of the page it refers to.

> use; it is advice on how to pick a time scale.

Exactly why I think it should discuss hazards of bad representations of
time. Especially since two of the main time systems it discusses suffer
from such bad representations.

> It mentions Google only as notable examples.

Perhaps you could re-word it to make that more clear.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Southeasterly 6 to gale 8, occasionally severe gale 9 at
first, backing northeasterly 4 to 6. Very rough or high, occasionally very
high in west at first. Rain. Good, occasionally poor.

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Nov 2019 07:05:18 -0800

Hi, Tony,

> On Nov 11, 2019, at 6:37 AM, Tony Finch <[email-masked]> wrote:
> 

They’re a bit like Schrodinger’s cat - they jump only whey you look at them (or would need to). IMO, they are time scales for that reason.

> clear that you meant something else.

Will do.

> the other ones in the draft. (It differs from Unix time by the number of

I haven’t found a public reference with enough detail on this. The only one I’ve found is Wikipedia, which has errors in its description of Unix time.

> It's a widely-available timescale,

I’m not sure I would agree with that - everything I’ve found says it’s limited to specialized industrial nets and systems; that’s another reason it’s not necessarily useful to add. 

> like many of the others listed in that

The dichotomy is accurate - either time units are a physical constant or they’re defined relative to celestial events.

Civil time is just a time scale adopted by a government (or other type of group of people). I’m not aware of a civil time scale that isn’t based on one of those two.

> nor the contents of the page it refers to.

Ahh - wrong ref. Google developed it earlier but didn’t turn it on for public use until 2017:
https://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/ <https://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/>

I’ll correct that.

> from such bad representations.

That’s perhaps another RFC.

> Perhaps you could re-word it to make that more clear.

Will do.

---

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Nov 2019 18:57:53 -0800

A little more about PTP, found here:
https://www.iol.unh.edu/sites/default/files/knowledgebase/1588/ptp_overview.pdf

>> the other ones in the draft. (It differs from Unix time by the number of

The source above claims PTP tries to coordinate the local clock to TAI.

That doc confirms it isn’t a time scale, as I originally indicated.

Joe

---

From: Steve Allen <[email-masked]>
Date: Mon, 11 Nov 2019 23:47:16 -0800

> That doc confirms it isn’t a time scale, as I originally indicated.

In many cases it does not really matter whether a particular instance
of PTP is trying to match TAI or any other atomic time scale.

The issues of Bulletin Horaire show that the value of TAI is based on
re-setting all atomic time scales so that they all had
UT2(BIH) - A3 = -1.4123 s
at the epoch 1961-01-01T20:00:00 UT2.
https://www.ucolick.org/~sla/leapsecs/taiepoch.html

The offsets of GPS and other satellite systems are also arbitrary, so
the value of any atomic time scale is unrelated to any observable
phenomenon.

What matters is that the time scale used by a PTP implementation is
uniform within the scope of its systems.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Nov 2019 13:32:51 +0000

> That doc confirms it isn’t a time scale, as I originally indicated.

I'm struggling to understand why things like NTP and Unix and GPS are in
scope but PTP is not.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
people involved in running their communities

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Nov 2019 13:37:51 +0000

Joe Touch <[email-masked]> wrote:

> They’re a bit like Schrodinger’s cat - they jump only whey you look at
> them (or would need to). IMO, they are time scales for that reason.

Perhaps the terminology section should make it clear that your definition
of time is extended in this way.

> The dichotomy is accurate - either time units are a physical constant or
> they’re defined relative to celestial events.

Except for Lamport clocks or vector clocks. And civil time is not
either/or wrt physical constants and celestial events, it's a mashup of
both.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: Variable 3 to 5, becoming west 6 to gale 8, perhaps severe gale 9 later.
Very rough or high. Showers. Moderate.

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Nov 2019 06:30:41 -0800

> On Nov 12, 2019, at 5:32 AM, Tony Finch <[email-masked]> wrote:
> 

Unix is included as a time scale. 

The others are not time scales. I see your point that PTP could be included there but it’s not intended for wide-scale deployment over the public Internet. Synchronous Ethernet isn’t listed either. I can add a note that there are other protocols - but I do think it’s reasonable to focus on those that are ~6 orders of magnitude more widely deployed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Nov 2019 06:33:59 -0800

> On Nov 12, 2019, at 5:37 AM, Tony Finch <[email-masked]> wrote:
> 

Will do.

> either/or wrt physical constants and celestial events, it's a mashup of

Agree with your point about Lamport and vector clocks, but they’re never presented as measuring the passage of time. Unix is. And civil time isn’t a time scale in of itself - it’s a designation of a time scale or combination of time scales. I can add that.

Note that this is down in the weeds of what this document is trying to accomplish. It isn’t intended to be THE definitive document about ways to keep time. It’s about *picking* a time scale and not trying to create your own.

Joe