e...@thyrsus.com said: > I'm not pulling this estimate out of a hat. "It will last about as long as > it already has" is, as it turns out, a pretty good heuristic for systems > that evolve under selection.
I don't think that is the question I was trying to ask. The case I was interested in is user takes a snapshot, then never updates. (Let's assume there are no major security issues.) > Apparently you don't understand the solution Dave Mills already embedded in > the design. This surprises me. > Here's how I think it works: > Instances of ntpd with different pivot points can synchronize because > maximum time skew between servers is much smaller than the modulus of the > NTP calendar. Above certain skew, the code says "uh oh, looks like I'm > hearing from a server with an epoch other that mine. That means I need to do > calendar aithmetic to figure out which epoch assuption will minimze the > skew". I think we are on the same wavelength. Or close enough. I think your "calendar aithmetic" is misleading. It's epoch arithmetic, a simple add. The reason I got started on this line of thought is that I haven't found the code that deals with the pivot point. Yes, if we had working pivot point code things would keep working forever as long as it was updated occasionally. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
