On 09/07/11 10:37, Rob wrote: > When it is not your requirement, fine. But stop suggesting others > it is no good.
First, it really is a hack. It wasn't made for that purpose and isn't very good at it. Second, many people that use it, use it in the way they think it works and not the way it actually works. I'd say about 3 out of 5 times I see it used, it is actually doing nothing at all and could be left out without any change in behavior. Third, almost nobody *really* means it when they say they don't care about the real time and that they only care that the systems are in sync. What they really mean is that the systems must be very closely in sync with each other and they have a higher tolerance for sync with the real time. Once it gets a half-hour or more off of the real time, then they want to know how to get the entire cluster reset to UTC, while maintaining sync with each other and not having a time step. Oh, yea, we need it by tomorrow... I wish we had an official how-to and best practice document that covers this, but we don't, just the anecdotal evidence of the old-timers. It is hard to codify it because of the version skew. The best practice of yesterday is now the shunned practice of today. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding -----------------------------------------------------------------------| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:[email protected] _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
