[ntp:questions] Number of Stratum 1 & Stratum 2 Peers
Martin Burnicki
martin.burnicki at meinberg.de
Wed Dec 17 09:35:39 UTC 2014
Phil W Lee wrote:
> 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.
>>
>> 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.
Yes you do. With only a version number "consumers" like ntpd would not
be able to know if the information is outdated, or not.
Of course, if leap seconds should be abolished it would be useful to
support a pseudo expiration date meaning "until further notice".
> 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).
This is once more a different file format than the format used by
tzdata, or NIST/NTP. :-(
A service like a tzdist client, or a simple script which might look for
and download updated files, could report an error if the URL is not
reachable, and thus it can't even *check* if a new "version" of the file
is available.
However, similarly as not every tiny NTP client node should query the
time directly from NIST and similar servers but should use pool servers
instead, not every tiny embedded system should try to download a leap
second file directly from the primary server.
If they use secondary servers an older version of the file may me
available, but outdated. No way to check this without an expiration date.
There are companies with a whole (sub-)network without access to the
internet, so it may be required to update DST rules and leap second
information manually. An easy way to do this could be to set up a tzdist
or FTP (or whatever) server which can provide the internal clients with
the update.
If no one cares about those updates then applications like ntpd can
output a warning if the expiration date has been passed. With only a
version information this isn't possible.
> It would also be useful if they used SSL, and changed the url to
> https://etc.
Agreed.
Martin
More information about the questions
mailing list