Brian Utterback wrote:
Thanks a lot for your suggestions, progress is made. :-) :-)
Here is what I suggest. First lose the LOCAL refclock. It does nothing
for you.
Yes, it seemed to have caused the oscillating behavior. Without that, no
oscillations any more. But the clock doesn't really synchronize either. From the
ntp log:
8 May 17:13:03 xntpd[1333]: offset 0.194995 sec freq 389.284 ppm poll 6
8 May 18:13:03 xntpd[1333]: offset 0.194909 sec freq 389.284 ppm poll 6
8 May 19:13:03 xntpd[1333]: offset 0.194867 sec freq 389.284 ppm poll 6
8 May 20:13:03 xntpd[1333]: offset 0.194832 sec freq 389.284 ppm poll 6
8 May 21:13:03 xntpd[1333]: offset 0.194676 sec freq 389.284 ppm poll 6
8 May 22:13:03 xntpd[1333]: offset 0.194871 sec freq 389.284 ppm poll 6
8 May 23:13:03 xntpd[1333]: offset 0.194898 sec freq 389.284 ppm poll 6
9 May 00:13:03 xntpd[1333]: offset 0.194732 sec freq 389.284 ppm poll 6
9 May 01:13:03 xntpd[1333]: offset 0.194737 sec freq 389.284 ppm poll 6
9 May 02:13:03 xntpd[1333]: offset 0.194801 sec freq 389.284 ppm poll 6
9 May 03:13:03 xntpd[1333]: offset 0.194734 sec freq 389.284 ppm poll 6
9 May 04:13:03 xntpd[1333]: offset 0.194635 sec freq 389.284 ppm poll 6
9 May 05:13:03 xntpd[1333]: offset 0.194613 sec freq 389.284 ppm poll 6
9 May 06:13:03 xntpd[1333]: offset 0.194687 sec freq 389.284 ppm poll 6
9 May 07:13:03 xntpd[1333]: offset 0.195019 sec freq 389.284 ppm poll 6
9 May 08:13:03 xntpd[1333]: offset 0.194609 sec freq 389.284 ppm poll 6
9 May 09:13:03 xntpd[1333]: offset 0.194732 sec freq 389.284 ppm poll 6
9 May 10:13:03 xntpd[1333]: offset 0.194741 sec freq 389.284 ppm poll 6
9 May 11:13:03 xntpd[1333]: offset 0.194706 sec freq 389.284 ppm poll 6
I.e., the frequency seems to be below 500 ppm. That is the range that ntp can
handle, isn't it? And the series above looks like
Btw, the poll interval remains at 64 seconds and doesn't go up either.
May it be that this is the case that is mentioned in the Sun Blueprint? (I got
the link from the NTP Wiki, at
http://ntp.isc.org/bin/view/Main/DocumentationIndex.) There it reads:
Systems using Solaris™ Operating Environment (Solaris OE) 8 with patch
109667-01, 109667-02, or 109667-03 (109668 on x86) always slew the clock.
This prevents the clock from shifting suddenly or stepping backwards, but
could result in an extremely lengthy synchronization process.
It goes on and tells that in that case one has to add "disable pll" to ntp.conf.
Well, you wrote:
Second, unless you are using the slewalways option, lose the "disable pll".
Does that mean that it might be worth a try to add both "slewalways yes" and
"disable pll" to ntp.conf and see if time converges faster?
I have to say that I don't actually understand what "disable pll" does. While
the Sun Blueprint says "This forces the system to use NTP’s clock setting
discipline directly, rather than having NTP interact with the kernel’s clock
setting discipline and is necessary as a side effect of the patch." the man page
tells me about the pll flag: "Enables the server to adjust its local clock. If
not set, the local clock free-runs at its intrinsic time and frequency offset."
I would like to understand that: When one uses "disable pll", is the Unix system
time now updated or not? I.e., is the "local clock" that is "free-running" the
system time or is that something else?
Best,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: [EMAIL PROTECTED]
Roedermark, Germany
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
