←back to thread

Please donate to keep Network Time Protocol up – Goal 1k

(www.ntp.org)
301 points gastonmorixe | 2 comments | 12 Nov 25 07:56 UTC | HN request time: 0.436s | source
Show context
mhovd ◴[12 Nov 25 10:53 UTC] No.45898645[source]▶
I am surprised that NTP project is not funded, fully or partially, by larger organizations or governments, given the criticality of the project.
replies(8): >>45898658 #>>45898731 #>>45898775 #>>45898921 #>>45899060 #>>45899179 #>>45899269 #>>45899540 #
nickelpro ◴[12 Nov 25 12:19 UTC] No.45899269[source]▶
The reference implementation, while historically important, has largely been displaced by more secure/performant implementations (ntpsec, chrony), or by in-house implementations (Amazon, Google).

Notably NTPd doesn't support leap-smear, which means those who absolutely must have monotonic time can't use it at all.

replies(3): >>45899310 #>>45899969 #>>45900271 #
1. throw0101d ◴[12 Nov 25 14:00 UTC] No.45900271[source]▶
> Notably NTPd doesn't support leap-smear, which means those who absolutely must have monotonic time can't use it at all.

It should be noted that there currently exists no standard, technical or statutory, for how to do leap smearing. If an event happens and you need to tie your timestamped event logs to the 'greater reality' in some legally binding way there's (AIUI) no way to do that.

A few years ago there was a draft on the idea:

* https://datatracker.ietf.org/doc/draft-stenn-ntp-leap-smear-...

And the currently-draft NTPv5 has something about:

* https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/

Though the flag simply says that the timescale is smeared and not (AFAICT) how it is being done.

See also perhaps RFC 8633 § 2.7.1:

    […]

    Operators who have legal obligations or other strong requirements to
    be synchronized with UTC or civil time SHOULD NOT use leap smearing
    because the distributed time cannot be guaranteed to be traceable to
    UTC during the smear interval.

    […]

    Any use of leap-smearing servers should be limited to within a
    single, well-controlled environment.  Leap smearing MUST NOT be used
    for public-facing NTP servers, as they will disagree with non-
    smearing servers (as well as UTC) during the leap smear interval, and
    there is no standardized way for a client to detect that a server is
    using leap smearing.  However, be aware that some public-facing
    servers may be configured this way in spite of this guidance.
* https://datatracker.ietf.org/doc/rfc8633/
replies(1): >>45901551 #
2. colechristensen ◴[12 Nov 25 15:43 UTC] No.45901551[source]▶
>If an event happens and you need to tie your timestamped event logs to the 'greater reality' in some legally binding way there's (AIUI) no way to do that.

TAI (Temps Atomique International), is UTC without leap seconds and is the source of truth for "what time is it"

I'm finding conflicting reports of being able to actually use TAI on linux but there are several claims of at least specialty setups existing. You would absolutely not want smearing or anything like that in your time synchronization software in this case.