Well, you cannot design protocols around broken platforms since the spec needs to hold up for 20 years, the platforms are fixed daily.
Is the leap second etc. dramatic`? Today definitely NOT but who knows where the stuff goes including satellites in the future ;-) I read the comment on the “just use epoch and burn the bytes” though I’m not too happy about it practically speaking. There are some customers that are squeaking last bytes out the encoding today, sometimes during complex migrations caused by redistributions and given more and more “garbage trucking” to paraphrase the other Tony the bytes are precious. However, if majority of folks feels that way, we could sway to 5 bytes timestamp (need to do the math on rollover first) and some better resolution on msecs and precision, probably a byte each which puts us at roughly 5msec resolution which is far beyond what practically will matter ever I think — Tony > On 26 Jul 2024, at 10:44, David 'equinox' Lamparter <equi...@diac24.net> > wrote: > > [External Email. Be cautious of content] > > > Hi all, > > > I haven't quite been able to express what I meant at the mic, sorry. I > was trying to point out that at least one IS-IS implementation (ours, > FRRouting) will occasionally get the PTP timestamp wrong due to having > an incorrect leap seconds offset. > > The only reliable timestamp on a Linux system is the unix timestamp. To > get a PTP timestamp, I need to apply the constant offset *and* also the > TAI-UTC offset aka leap seconds count. On a *correctly configured* > system, this will be in clock_adjtime()'s result (timex->tai) and/or I > can query CLOCK_TAI rather than CLOCK_REALTIME. > > ... unfortunately this is configured by other userspace software beyond > our control. If the system is running a PTP daemon[note 1], it > *hopefully* retrieves the tzdb leap-seconds file and loads it into the > kernel. Some other system components (systemd, ntpd) may load it but > don't update it[note 2] (which is, honestly, worse than having nothing > loaded, because then you can recognize it's 0, which is not an invalid > offset but at least an "unlikely" one.) > > If we were talking about a core protocol feature here, I'd raise this as > a serious concern. For a debugging feature - I think we'll be OK, maybe > it's a chance to get the distro builders to fix their shit re. > leap-seconds updates. (It's been getting better, but not quite there > yet I'd say.) > > Also, if the IERS follows through on their decision to stop doing leap > seconds, this will become irrelevant... ...in 2035. > > Regards, > > > equi > (David) > > > [note 1] a PTP daemon is _not_ part of FRRouting. There are >= 2 > implementations but FRRouting doesn't know if anything is running. > > [note 2] they rely on updating the file through regular system package > updates, which happen whenever the system operator feels like it. _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
