Okay if nobody has anything else rolling I need hard numbers on what to implement. What are we going with...?
Let's try to keep this from flaming each other and keep it constructive if possible. Either way this issue must change for 1.1. Scott On 5/27/06, Randy B <[EMAIL PROTECTED]> wrote:
Not I, said the fly... Just as I thought I'd get some development time at home, my job made a big shift. I did encourage Joshua to go ahead and pursue it and not wait for me, but I've not seen anything since. The easiest way would probably be OpenNTP - it's incredibly lightweight and simple. However, there seems to be some concern about it abusing NTP servers; I have no personal experience with that, so I leave that answer to those who do. RB On 5/26/06, Scott Ullrich <[EMAIL PROTECTED]> wrote: > Anyone have any luck with this? Msntp has some serious problems > resolving custom dns names it seems. It's gotta go. ;) > > On 4/11/06, Bill Marquette <[EMAIL PROTECTED]> wrote: > > On 4/11/06, Randy B <[EMAIL PROTECTED]> wrote: > > > > > > On 4/5/06, Vivek Khera <[EMAIL PROTECTED]> wrote: > > > > ISC's ntp is well known and understood and considered very accurate. > > > > I see no other choice. > > > > > > > > > > > > After Running OpenNTP for a while now, I feel less uncomfortable with it - > > > after the first 12 hours or so, the clock swings (+/-12ms) evened out, and > > > it's staying quite comfortably within +/- 2-3ms with very little jitter. In > > > the following output of 'ntpq -c peers', the system in question is > > > 'balrog-priv'; note the odd reference clock - I think that's an artifact of > > > the minimal implementation that doesn't allow that level of querying. In > > > fact, for the most part it seems to stay well within 1ms (it refers to > > > no-such-system, dies-irae, and the local system I'm querying from). > > > > I might have to give it a try on my boxes (running OpenBSD) at work. > > ISC ntpd can't keep the clock sync'd when you have lots of jitter > > (which we do - due to traffic loads on the box trying to be sync'd). > > It eventually gives up attempting to sync the clock. A ntp daemon > > "that works" it better than an ntp daemon that when it works, is > > millisecond precise, but "doesn't work". FWIW, when a carp pair gets > > it's dates out of sync by more than a second or two, hilarity ensues > > and it's _not_ a pretty sight (that was my joy first thing yesterday > > morning). > > > > --Bill > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
