Magnus Danielson writes: > The drift-file-accelerated lock-in isn't robust. Current behavior of > response isn't very useful for most people experiencing it.
I'm not sure I'd agree with the word "most". It's certainly worked very well on hundreds of machines where I've run it, and the feedback I've had from people when I've told them about iburst and drift files has been positive except when they've had Linux kernels that calculate a different clock frequency on a reboot. There are at least 2 other issues here. One goes to "robust", and yes, we can do better with that. It's not yet clear to me that in the wider perspective this effort will be worthwhile. The other goes to the amount of time it takes to adequately determine the offset and drift. With a good driftfile and iburst, ntpd will sync to a handful of PPM in about 11 seconds' time. We've been working on a project to produce sufficiently accurate offset and drift measurements at startup time, and the main problem here is that it can take minutes to figure this out well, and there is a significant need to get the time in the right ballpark at startup in less than a minute. These goals are mutually incompatible. The intent is to find a way to "get there" as well as possible, as quickly as possible. H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions