On 2007-12-04, Dan B. Phung <[EMAIL PROTECTED]> wrote: > Hi, I'm trying to sync two machines, one as the server the other > as the client, both sitting on a private switched network. After > ntp settles in, the client has a 10-30 ms offset that continues to > increase in offset, but what I'm doing requires the two machines to be > off by no more than 500 us. I've gone through the NTP debug routine > and my PPM error is pretty small (see below) also, what's the huffpuff > filter, I didn't try playing with that yet, and can't find much info > on the web about it. > > Below is some info to help assess my situation, please let me know if > there's more info I can provide.
> server (larry) conf: ><ntp.conf> > driftfile /var/lib/ntp/ntp.drift > statistics loopstats peerstats clockstats > filegen loopstats file loopstats type day enable > filegen peerstats file peerstats type day enable > filegen clockstats file clockstats type day enable > server 127.127.1.1 > fudge 127.127.1.1 stratum 10 > restrict 127.0.0.1 > restrict ::1 ></ntp.conf> You have not provided your server with a stable timebase. So you don't really know if the server clock is drifting slowly in one direction or the other or swinging back and forth. This may, or may not, contribute to the problem you're experiencing. BTW: Your restrict lines are meaningless (and harmless) since you have not defined a default restriction. > client (moe) conf: > server larry As an enhancement you could append 'iburst' to that server line to speed up initial sync. > debugging info on larry: [snip] >remote refid st t when poll reach delay offset jitter >================================================================ >*LOCAL(1) .LOCL. 10 l 29 64 377 0.000 0.000 0.001 That looks normal. > debugging info on moe: [snip] >remote refid st t when poll reach delay offset jitter >================================================================ >*larry LOCAL(1) 11 u 6 64 377 0.175 -15.448 5.771 Keep in mind that this is only a snap shot and conveys more information when compared with other peer status billboards over time. [snip] > clockË004b8a.3864b86c Tue, Dec 4 2007 16:56:26.220, state=2, ntpd is not fully synchronised until the state equals 4. ntpd spends about 20 minutes training the clock at start up if no drift file is present. During this time you may observe the clock being slewed back and forth. You need to allow ntpd to run long enough (~ 1 hour) for a drift file to be created. Has a drift file been created on moe? The states are (taken from ./ntpd/ntp_loopfilter.c): #define S_NSET 0 /* clock never set */ #define S_FSET 1 /* frequency set from the drift file */ #define S_SPIK 2 /* spike detected */ #define S_FREQ 3 /* frequency mode */ #define S_SYNC 4 /* clock synchronized */ -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
