4 ms·
We've seen time and time again that it doesn't matter what the spec says, if it works now, noncompliance will be there. Heck we're stuck with TCP & UDP because
by dtech 5y ago
We've seen time and time again that it doesn't matter what the spec says, if it works now, noncompliance will be there. Heck we're stuck with TCP & UDP because routers and firewalls will break anything else. If it works long enough, ossification makes it the new reality.
How many NTP implementations don't consider era or contain bugs if era != 0?
- fanf2 5y agoThere will almost certainly be failures in devices without battery-backed clocks (eg, Raspberry Pi) that boot in 1970 and rely on NTP to get the correct time, because NTP can’t tell them they are in Era 1 not Era 0. To fix this you need a persistent low water mark on the time, compiled into the NTP program and/or stored in the filesystem (eg the timestamp on the NTP drift file). Then NTP timestamps can be interpreted as spanning the 136 years after the low water mark, using modular arithmetic.
- asgeirn 5y agoFrom https://docs.ntpsec.org/latest/warp.html https://docs.ntpsec.org/latest/warp.html: > The NTP protocol will synchronize correctly, regardless of era, as long as the system clock is set initially within 68 years (a half-era) of the correct time Which means 2036 will appear to work just fine, as 1970 is only 66 years away. Now jump forward to 2038, and this would not be the case..
- Unklejoe 5y ago> To fix this you need a persistent low water mark on the time Yep, this is what many GPS receivers do to deal with the 20 year issue. They burn their manufacturing date, so they know which "cycle" they're in.