7 ms·

The reference implementation, while historically important, has largely been displaced by more secure/performant implementations (ntpsec, chrony), or by in-hous

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.

mananaysiempre 11mo ago
> Those who absolutely must have monotonic time ... shouldn’t be using a Unix timestamp, or anything else that’s not a count of SI seconds elapsed since a fixed reference point, to begin with.
- bobmcnamara 11mo ago
  Pitch: TAI
  - mananaysiempre 11mo ago
    Kind of. If you “absolutely must” have monotonic time, though, and also care about NTP, then just pointing to TAI (in DJB’s naïve definition) or GPS time is not enough. You need to make decisions on whether you, for example, would prefer your imprecise seconds to be more even individually or for the aggregate count to be more accurate (NTP of course gets you the latter by default). Dear Sir[1], you have done metrology. [1] https://people.csail.mit.edu/rachit/post/you-have-built-a-compiler/ https://people.csail.mit.edu/rachit/post/you-have-built-a-co..., https://news.ycombinator.com/item?id=29891428 https://news.ycombinator.com/item?id=29891428
    - bobmcnamara 11mo ago
      I really just want the software time to be as good as the underlying hardware clock... ...rather than setting a rather awful minimum performance spec of 10ppm smearing over a leap second day. Three lies: Universal - multiple smear implementations, linear vs cosine off the top of my head. Coordinated - whose in charge here? Google? Facebook? Time - doesn't even try for 1s/s UTC is, for all intents and purposes, yet another human readable time zone. And should be treated as such. The underlying hardware problems I have and understand. Don't need the software making it worse.
tptacek 11mo ago
Who's running ntpsec?
- exasperaited 11mo ago
  At least in part, someone you really don't want to be running a fork of an important project: ESR.
  - tptacek 11mo ago
    Oh, no, I mean, I know who's actually behind the project, I'm just wondering if there are any major deployments of it.
  - chocalot 11mo ago
    I'm out of the loop. What's the issue with using a project that ESR contributes to? I am vaguely aware he has some unpopular political beliefs (though exactly what I don't know). Is that it?
    - akerl_ 11mo ago
      Insofar as racism, homophobia, and sexism are unpopular political beliefs: yes. Oh, also he doesn't really "contribute" to tech projects so much as "exists near/within them and writes long form ramblings".
      - chocalot 11mo ago
        Ah, the person I responded to suggests he runs the project. If he just "exists near", I see even less of a case why someone should avoid it. But horses for courses, people can choose to avoid for whatever reason.
        tptacek 11mo ago
        No, there's a long story behind ntpsec and it's all pretty exhausting and none of it has anything to do with ESR's personal life.
throw0101d 11mo ago
> 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-refid/ 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/ 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/ https://datatracker.ietf.org/doc/rfc8633/
- colechristensen 11mo ago
  >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.

mananaysiempre 11mo ago

> Those who absolutely must have monotonic time ... shouldn’t be using a Unix timestamp, or anything else that’s not a count of SI seconds elapsed since a fixed reference point, to begin with.

bobmcnamara 11mo ago
Pitch: TAI
- mananaysiempre 11mo ago
  Kind of. If you “absolutely must” have monotonic time, though, and also care about NTP, then just pointing to TAI (in DJB’s naïve definition) or GPS time is not enough. You need to make decisions on whether you, for example, would prefer your imprecise seconds to be more even individually or for the aggregate count to be more accurate (NTP of course gets you the latter by default). Dear Sir[1], you have done metrology. [1] https://people.csail.mit.edu/rachit/post/you-have-built-a-compiler/ https://people.csail.mit.edu/rachit/post/you-have-built-a-co..., https://news.ycombinator.com/item?id=29891428 https://news.ycombinator.com/item?id=29891428
  - bobmcnamara 11mo ago
    I really just want the software time to be as good as the underlying hardware clock... ...rather than setting a rather awful minimum performance spec of 10ppm smearing over a leap second day. Three lies: Universal - multiple smear implementations, linear vs cosine off the top of my head. Coordinated - whose in charge here? Google? Facebook? Time - doesn't even try for 1s/s UTC is, for all intents and purposes, yet another human readable time zone. And should be treated as such. The underlying hardware problems I have and understand. Don't need the software making it worse.

tptacek 11mo ago

Who's running ntpsec?

exasperaited 11mo ago
At least in part, someone you really don't want to be running a fork of an important project: ESR.
- tptacek 11mo ago
  Oh, no, I mean, I know who's actually behind the project, I'm just wondering if there are any major deployments of it.
- chocalot 11mo ago
  I'm out of the loop. What's the issue with using a project that ESR contributes to? I am vaguely aware he has some unpopular political beliefs (though exactly what I don't know). Is that it?
  - akerl_ 11mo ago
    Insofar as racism, homophobia, and sexism are unpopular political beliefs: yes. Oh, also he doesn't really "contribute" to tech projects so much as "exists near/within them and writes long form ramblings".
    - chocalot 11mo ago
      Ah, the person I responded to suggests he runs the project. If he just "exists near", I see even less of a case why someone should avoid it. But horses for courses, people can choose to avoid for whatever reason.
      - tptacek 11mo ago
        No, there's a long story behind ntpsec and it's all pretty exhausting and none of it has anything to do with ESR's personal life.

throw0101d 11mo ago

> 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-refid/ 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/ 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/ https://datatracker.ietf.org/doc/rfc8633/

colechristensen 11mo ago
>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.