The reason I suggested just using 64 bits which then provides nanosecond resolution (whether we need it today or not), is it seems KISS, which makes me feel warm inside — people aren’t going to screw up the unit values; we really aren’t going to need to revisit this anytime soon for different resolution or have to “just deal” with resolution not being quite what we want for some future use, and we’re talking about 3 out of ~1500 octets here. Using fractions of fractions to count things to save a 3 octets and possibly have to change it again someday just seems a bit overly careful. If 3 octets matter the user is in need of one of the LSP space expanding solutions at this point I guess.
Thanks, Chris. > On Jul 26, 2024, at 11:18 AM, Antoni Przygienda > <prz=40juniper....@dmarc.ietf.org> wrote: > > 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
