[email protected] wrote:
> I have a server running NTP 4.2.2 (as part of the RedHat 5.7
release). Last night I changed it's /etc/ntp.conf file,
specifically the "server xyz" line to point to a new NTP
server.
>
> After doing this, the clock's offset was *increasing* after an
hour. Offset is measured by "ntpdate -q peer".
>
> From what I've gathered about NTP, it attempts to adjust clocks
"gently" and "slowly". What I'm doing now, and I'm sure this
will make some cringe, is to run "ntpdate -u -b peer" in a loop,
sleeping two seconds between runs. I understand this is the
opposite of slowly and gently.
>
You might as well keep using the date command and forget about
ntpd. You are fighting ntpd and have little chance of winning.
After a reboot my pcs usually are within 1 ms within 30 minutes,
and that's about the best they will do in my non temperature
controlled location. Periods better than 300 usec do happen but
they depend on the weather and the pcs being otherwise idle. Ntpd
relies on establishing a drift file, /var/db/ntp/ntpd.drift on
my systems. The drift file can take many hours to be established
and many days if you keep experimenting and making changes.
If you need to experiment then try a more recent version, I'm
using 4.2.6p5 on NetBSD (I've tried some 4.2.7 versions but had
no success).
David
> But is there a way to somehow combine the behavior of both? Be a
little more aggressive like ntpdate, but retain some of the "politeness"
of the daemon?
>
> For what it's worth, I've recently been playing with the open-source
PTPv2 dae
mon. It appears to "beat the system clock into submission" rather
quickly---I see syncs occurring typically in a matter of minutes. Is
there a way to make NTP act more like PTP with regards to getting clocks
sync'ed quickly?
>
> I know I'm using very figurative/non-specific terminology here... but
I'm tryi
ng to wade through all the NTP documentation, but it quickly gets over
my head, and I'm not sure what's applicable and what's not. Hopefully
this list can help me get a better handle on this stuff.
>
> Thanks,
> Matt
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
