Hi Micheal,
On 2014-11-03 02:43 AM, michael.deckers via LEAPSECS wrote:
On 2014-10-31 17:39, Brooks Harris wrote:
Yes. Its primary timescale, sometimes called "PTP Time", more
properly the "PTP
Timescale", is a "TAI-like" counter (uninterrupted incrementing count of
seconds). Note its origin, or epoch, is 1969-12-31T23:59:50Z, ten
seconds before
the POSIX "the Epoch" (if you take that to mean two years (2 x 365 x
86400)
seconds before 1972-01-01T00:00:00Z (UTC), as NTP does).
Just nitpicking:
In [IEC 61588 of 2009-02. section 7.2.2] we read:
"The PTP epoch is 1 January 1970 00:00:00 TAI,
which is 31 December 1969 23:59:51.999918 UTC."
So you are off by about 2 s.
CAUTION about the PTP Epoch. Its not "just nitpicking".
I have been involved with a standards body attempting to use 1588/PTP.
There was a (long!) debate about what the PTP Epoch actually is. This
discussion included several participants with experience using 1588/PTP.
The conclusion is that the PTP Epoch is 1970-01-01T00:00:00 (TAI) which
*must be treated as* 1969-12-31T23:59:50Z (UTC), *not* "1969
23:59:51.999918 UTC" as stated in the 1588/PTP document. The reason is
to maintain an integral-second alignment between the PTP Timescale and
the UTC timescale.
The relationship between the PTP timescale, POSIX, and UTC are discussed
in some detail in the document. Unfortunately it is confusing,
misleading, and arguably wrong.
Quoting [IEEE Std 1588™-2008, IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control Systems]
7.2 PTP timescale, 7.2.1 General - "The timescale PTP: In normal
operation, the epoch is the PTP epoch and the timescale is continuous;
see 7.2.4. The unit of measure of time is the SI second as realized on
the rotating geoid."
This describes a "TAI-like" timescale - an uninterrupted incrementing
count of seconds, and specifically " the SI second as realized on the
rotating geoid.". That is the primary counting mechanism, appropriate to
the main objective as stated in the title - "for Networked Measurement
and Control Systems".
7.2.2 Epoch states "The PTP epoch is 1 January 1970 00:00:00 TAI, which
is 31 December 1969 23:59:51.999918 UTC."
Here we wade into the debate and confusion produced by the historical
TAI/UTC relationship before 1972. In the same section, we read -
"NOTE 1— The PTP epoch coincides with the epoch of the common Portable
Operating System Interface (POSIX) algorithms for converting elapsed
seconds since the epoch to the ISO 8601:2004 printed representation of
time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17]."
Here we wade into the debate and confusion about POSIX's "The Epoch". In
the same section, we also read -
"NOTE 2— See Annex B for information on converting between common
timescales."
In "Annex B (informative) Timescales and epochs in PTP" we find a long,
detailed, discussion of timescales, especially PTP, TAI, POSIX, and UTC,
and character representation via 8601. Note the entire annex is
(informative).
The discussion attempts to resolve the question about what the TAI/UTC
relationship was *before* 1972-01-01T00:00:00Z and how this is related
to POSIX and represented by 8601. Of course, as often discussed and
debated on this [LEAPSECS] list, the term "UTC" may or may not be
applicable to date-time before 1972 and what portions of the historical
record might be interpreted as "proleptic" and exactly what that means.
One could argue the entire section is very confusing.
At the end of Annex B we find a table - Table B.1 - Relationships
between timescales. Note the values of the relationships amongst the
timescales in this table are all *integral second* values. This seems to
be in contradiction to much of the discussion in Annex B and to the
statement of the PTP Epoch in paragraph "7.2.2 Epoch".
If we parse that sentence (7.2.2 Epoch" - The PTP epoch is 1 January
1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC.")
carefully, the first part, "1 January 1970 00:00:00 TAI" is clear
enough, but exactly what to make of "31 December 1969 23:59:51.999918
UTC"? That value might be correct depending on how you interpret the
historical record of TAI/UTC offsets and exactly what you mean by some
"proleptic UTC timescale".
We've been advised by PTP experts that A) yes, its confusing, and B)
most implementations use a integral-second interpretation, as in Table
B.1. I understand the "escape clause" they use to justify this is the
"(POSIX) algorithms" phrase in Note 1 of 7.2.2 Epoch. By "(POSIX)
algorithms" they mean "gmtime()" and (strict) POSIX "ticks" at 1Hz, so,
integral seconds. In any event its really the only interpretation that
yields a manageable, practical, implementation that is consistent with
TAI and UTC, NTP, and common-use of POSIX.
However, while its said "most" implementations follow this approach, it
doesn't mean every one does. I fear there are already implementations of
1588/PTP that do not match each other in this crucial respect.
-Brooks
Michael Deckers.
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
