hmur...@megapathdsl.net said: > "as soon as they arrive" seems ugly to me, but maybe that's just because > I've been thinking of using l_fp to compute an offset and using the offset > to adjust the time with an effective pivot of "now".
After thinking about it some more... I think that doing the pivot "as soon as they arrive" is a good idea. After a packet exchange, there are 4 time stamps; 2 local and 2 remote. We get the local times as timespecs before turning them into l_fp. We'll have to save those local timespecs in order to avoid a bogus pivot. The point is that there is no pivot anywhere near the main body of timekeeping. And no hidden pivot like requiring the system time to be close enough. Note that the pivot time isn't critical. Being off by a few years or even a few dozen is not a problem. It would be perfectly reasonable to use the release date rather than the build time. (We may want the build time for GPS pivot.) We might want to include a sanity check in the pivot code. The full range of 32 bits of seconds is 136 years. Most of that range doesn't make sense. Does it make sense to set the clock to 100 years after the build time? More likely you are talking to a confused server. Maybe that filter should be part of the BOGON filtering. ------- Note that there are actually 2 packet processing paths to consider. The above is the client side. I think the server side is trivial - no pivot involved. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
