On Mar 19, 2010, at 1:19 PM, Joe Wulf wrote: > Group, > > With due humbleness and respect to both 'cnoyes2' (the original author) and > Steve Kosteke---I would think he (cnoyes2) isn't concerned with whether the > clocks are monotonic (whatever that is).
It means whether the clock values always increase. Some hardware clocks are sufficiently broken that they might "jump backwards" which can cause logic errors in programs which assume that time always increases; good platforms check for and try to avoid using broken clocks. It's also hard to imagine a circumstance where someone would care about whether a clock is sync'ed to something else *and* not care about whether the clock is working at all. > I understand and fully agree that unmanaged clocks, which are not > sync'd to an authoritative time-source will drift, and it can get > horrible and other bad things can happen. Got that. > > What seems to get lost, and admittedly not explained very well---hence > my attempt here.... is that there are many situations these days where > folks are developing, working, troubleshooting real-world problems in > environments big and small that are deliberately isolated (and rightfully > so)---and > just don't have the luxury of an authoritative time-source -- but just want > time to 'work' and be sync'd. OK, that's fine. The best advice I can think of is to solve the right problem. In most cases, it is easier to solve the problem of sync'ing all computers to a correct timesource (and thus all be mutually in sync), then it is to setup a bunch of truly & completely isolated machines which happen to stay in sync. If I really had to solve the latter problem, I would likely connect the machines to a valid NTP timesource long enough to calibrate each machines' intrinsic drift from realtime, and then run time in standalone mode against their local clock. (I'd be much likelier to see whether I can cheat that extreme restriction my using a modem line to callout to a timesource, or hit up a GPS receiver, or WWVB receiver, etc.) Regards, -- -Chuck _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
