On 2013-04-27, Harlan Stenn <[email protected]> wrote: > unruh writes: >> On 2013-04-26, Harlan Stenn <[email protected]> wrote: >> > unruh writes: >> >> Define occasionally. Unfortuneately ntpd requires about 5-10 hours to >> >> rediscipline a clock to ultimate accuracy when the connection comes up >> >> again, so if the connection time is shorter than that, chrony (assuming >> >> you run linux or some unix) is a better choice ( faster lock and >> >> discipline time). It also allows you to "trim by hand". Ie, if you can >> >> phone into the device, and find it is say 1 min off, you can tell chrony >> >> to correct that offset by hand. >> > >> > And Bill's statement above also depends on your definition of "better". >> > >> > My understanding is chrony will do an excellent job of tracking the >> > upstream source it is listening to. That is not necessarily the same as >> > maintaining better system time. >> >> Sorry, what other definition do you have of "better system time"? All >> anything can do is to use a source and assume that that sourc is a good >> source. > > I haven't looked in a while. What does chrony do about selecting > between multiple servers? What about clockhopping? > > For some, "better" may mean "My clock frequency is stable and I am > tracking the middle of the clique" as opposed to "I am tighty latched > to the server I am currently listening to."
Not sure myself. I am always running with one server being the local gps server which is what gets selected. I have not spent time looking at chrony's handling of which external clock it tracks, or exactly what it does to select the time that it tracks. So I have not seen clockhopping, but that says not much. And as far as I know this has not received any attention in the past 5-10 years. > > H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
