Yes, there is a risk that systems will drift due to accumulated leap seconds without updates.We worked throuugh the details... http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf but keeping time accurately and continuously (temperature extremes causing drift, power loss) is likely more of an issue in many use cases. The background assumption here is the NASA interplanetary internet use case (and first RG before DTNRG), where a spacecraft without a clock is useless, the clock is a critical component and sync'd with updates continuously somehow, all hail the clock. DTN doesn't scale beyond that to other use cases that well.
Lloyd [email protected] On Friday, November 8, 2019, 11:35 pm, Stewart Bryant <[email protected]> wrote: Hi Magnus I will address the other points in a later email, but on this I am concerned that WG have a misunderstanding of the timebase they are using. UNIX/POSIX time does have leap seconds it just handles them silently so you will get double increments. However since my follow-up note yesterday, I was wondering how the remote remote system knew to add a leap second in order to keep in track with the local system? Isn’t there a risk that the two systems will drift apart as leap seconds are added locally? Also there is the rollover problem to worry about. I think the section needs to go to a specialist group for review such as TicToc/NTP to verify that it works exactly as the WG expect.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
