[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