On 2014-12-18 14:27, Phil W Lee wrote:
Martin Burnicki <martin.burni...@meinberg.de> considered Wed, 17 Dec
2014 10:35:39 +0100 the perfect time to write:
Phil W Lee wrote:
Martin Burnicki <martin.burni...@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
https://etc.
Agreed.
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
detected.
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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
