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
