[ntp:questions] Number of Stratum 1 & Stratum 2 Peers

Harlan Stenn stenn at ntp.org
Wed Dec 17 11:49:15 UTC 2014

Phil W Lee writes:
> Martin Burnicki <martin.burnicki at meinberg.de> considered Tue, 16 Dec
> 2014 14:23:15 +0100 the perfect time to write:
> >Harlan Stenn wrote:
> >> An alternative is that we get enough support to advance NTF's General
> >> Timestamp API, and then we can run systems on either TAI or UTC and
> >> these conversions will happen automatically.
> >>
> >> Since timescale files in the GTSAPI are "versioned", one could still use
> >> an obsolete leapsecond file, and while those UTC timestamps would be
> >> "wrong" if a new leapsecond was added, these timestamps would be
> >> correctable when a new version of the UTC timescale file was available.
> >
> >Hm, that may not really help if the API returns a wrong UTC time stamp 
> >which is then used to set the system time wrong.

While a "traditional" timestamp would have problems, if the system time
uses the GTSAPI structure the "wrong" UTC timestamp would not be
"wrong", it would just be using the older timescale version.  These can
be remapped as needed.  This is equivalent to the case where we want to
"do something in the future" with an absolute UTC timestamp.

> >The tzdist protocol could also be helpful here to provide the 
> >information required to do the conversion correctly. An expiration date 
> >could be used for versioning.
> >
> >Martin
> You don't need an expiry date if you have a version number and/or an
> authoritative source for any new version that may be available - you
> just compare the two, and use the newest available.

As long as you have the timescale versions for the timestamps you are
tracking, one can do the conversions.

> As long as the IERS stays at the same URL, you could just use their
> file at http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second.dat
> (although it would be useful if that file was more complete, with a
> version number and checksum).
> It would also be useful if they used SSL, and changed the url to
> https://etc.

There are several timescales available there.

Right now it's looking like we can use TAI as a canonical timescale and
map that into different UTC timescales (they "version" every 6 months'
or so) and we can do similarly with IERS-A timescales (which "version"
every week).  Then there are folks who will apply leap-seconds

This is to be expected, and must be dealt with.  From what we've seen,
this is doable.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!

More information about the questions mailing list