[ntp:questions] Number of Stratum 1 & Stratum 2 Peers
Brian.Inglis at SystematicSw.ab.ca
Fri Dec 19 03:03:08 UTC 2014
On 2014-12-18 14:27, Phil W Lee wrote:
> Martin Burnicki <martin.burnicki at meinberg.de> considered Wed, 17 Dec
> 2014 10:35:39 +0100 the perfect time to write:
>> 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.
>>> 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.
> So make the download dependent on the stratum of the ntp server -
> mandatory for stratum 1, optional for 2, disabled below that (or some
> such system - that's only a suggestion, although obviously I think it
> has merit).
>> 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
Perhaps NTP V5 could support all current leap second file source types,
specification of URIs and file paths for all types; with an optional leap
second packet extension, added only to early association establishment
packets once a server version is known, or whenever a source update is
The leap second packet extension would be optional only for V < 5 or stratum > 1,
and give the last/next leap second time announced, the expiration time, now
available in all sources, and source file type, to allow for different expiration
times, unless NIST and IERS agree on expiration times.
If the leap second and expiration times announced agree, the packet extension
returns the same values, otherwise the later leap second time and/or earlier
expiration time, if the leap second time agrees, is adopted by the lower stratum
system and returned in the reply, indicating adoption, then the extension can be
dropped from subsequent packets.
Lack of agreement and/or adoption should always be logged by lower stratum systems,
could optionally be logged by equal stratum systems acting as clients or peers, and
could optionally be logged only once by higher stratum systems.
Other requirements will undoubtedly need to be added to cover all possible scenarios,
including false-leapers, false-expirers, and dropped packets.
Take care. Thanks, Brian Inglis
More information about the questions