ntpd still not working

vince <nobody RemoveThis @home.invalid> wrote:
> On Mon, 2 Nov 2009 15:46:55 +0000 (UTC), root <NoEMail RemoveThis @home.org>
> wrote:
>
>>After everyone's help, the damned thing still
>>isn't working.
>
> I'm far from an expert, but since nothing has worked to this point,
> try removing or commenting out these two lines
> server 127.127.1.0 # local clock
> fudge 127.127.1.0 stratum 10
>

Thanks, but I have tried that.

Could you please post your entire ntp.conf again? Did you remove or
comment out the multicast and broadcast lines? Those lines should probably
be removed or commented out.

You could try the following file:

-8<---------------------
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
pidfile /var/run/ntpd.pid
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
server tick.ucla.edu
-8<---------------------

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

root <NoEMail.TakeThisOut@home.org> wrote in news:hcnesr$b4n$1@news.albasani.net:

> vince <nobody.TakeThisOut@home.invalid> wrote:
>> On Mon, 2 Nov 2009 15:46:55 +0000 (UTC), root <NoEMail.TakeThisOut@home.org>
>> wrote:
>>
>>>After everyone's help, the damned thing still
>>>isn't working.
>>
>> I'm far from an expert, but since nothing has worked to this point,
>> try removing or commenting out these two lines
>> server 127.127.1.0 # local clock
>> fudge 127.127.1.0 stratum 10
>>
>
> Thanks, but I have tried that.

Use OpenNTP, not ISC ntpd. You'll be glad you switched.
--
buck

Henrik Carlqvist <Henrik.Carlqvist.RemoveThis@deadspam.com> wrote:
> Could you please post your entire ntp.conf again? Did you remove or
> comment out the multicast and broadcast lines? Those lines should probably
> be removed or commented out.
>
> You could try the following file:
>
> -8<---------------------
> server 127.127.1.0 # local clock
> fudge 127.127.1.0 stratum 10
> driftfile /etc/ntp/drift
> pidfile /var/run/ntpd.pid
> server 0.pool.ntp.org
> server 1.pool.ntp.org
> server 2.pool.ntp.org
> server 3.pool.ntp.org
> server tick.ucla.edu
> -8<---------------------
>
> regards Henrik

Your file was identical to my last attempt, except
that I had omitted the fudge line. I just restarted
the daemon with your conf file. As was suggested earlier
I added a log file to the invocation of ntpd. Here
is the resulting file:
2 Nov 22:55:48 ntpd[4766]: logging to file /tmp/ntp.log
2 Nov 22:55:48 ntpd[4766]: precision = 4000.000 usec
2 Nov 22:55:48 ntpd[4766]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2 Nov 22:55:48 ntpd[4766]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
2 Nov 22:55:48 ntpd[4766]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
2 Nov 22:55:48 ntpd[4766]: Listening on interface #2 eth0, 10.0.0.3#123 Enabled
2 Nov 22:55:48 ntpd[4766]: kernel time sync status 0040
2 Nov 22:55:48 ntpd[4766]: frequency initialized 1.211 PPM from /etc/ntp/drift
2 Nov 22:59:01 ntpd[4766]: synchronized to LOCAL(0), stratum 10
2 Nov 22:59:01 ntpd[4766]: kernel time sync status change 0001

Someone else had line in his log file that said his kernel
was synched to one of the servers. I have no such line.


Here is the result of ntpq -p:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 6 64 37 0.000 0.000 3.906
ntp.pbx.org 192.5.41.40 2 u - 64 37 78.773 121166. 1671.51
ns1.your-site.c 10.1.11.62 3 u 64 64 17 82.288 118730. 1317.26
phoenix.netserv 64.113.44.54 2 u - 64 37 72.498 120571. 1180.28
valkyrie.netser 64.113.44.54 2 u 61 64 17 66.549 119336. 868.405
tick.ucla.edu .GPS. 1 u 60 64 17 11.436 119369. 877.524

I was told that the poll entry above should gradually increase to
1024. In fact I have never seen it change from 64. The jitter entry changes.

Somewhere along the line my drift entry was changed from 0.000 to 1.211
but I failed to notice when it changed and what the config file
was when it changed. I might have had a working ntpd at that instant
and walked away from it. Regardless, I have never seen ntpd improve
the timekeeping.

Thanks for your continued help Henrik.

buck <buck DeleteThis @private.mil> wrote:
>
> Use OpenNTP, not ISC ntpd. You'll be glad you switched.
> --
> buck

I am running 12.2, what did Patrick choose?
Why would I be glad to switch, is the Open
version a plug in replacement?

root <NoEMail.TakeThisOut@home.org> wrote:
>After over two hours of operation
>I had drifted by 84 seconds, which is just the
>drift I had always been getting.

So, the rate of your clock is about 1170 ppm too fast or too slow. ntpd can
fix the rate only if it's less than 500 ppm off if I remember right.

Try this: first kill ntpd, then "adjtimex -f 0" to reset the frequency
offset. Then give either "tickadj 10117" or "tickadj 9883" depending on
whether your clock was 1170 ppm too slow or too fast. Don't start ntpd yet.
Use the eyeball-and-wristwatch method to check if the clock is better now.
Now ntpd should be able to control the clock.

root <NoEMail.RemoveThis@home.org> wrote:
>After over two hours of operation
>I had drifted by 84 seconds, which is just the
>drift I had always been getting.

So, the rate of your clock is about 11700 ppm too fast or too slow. ntpd can
fix the rate only if it's less than 500 ppm off if I remember right.

Try this: first kill ntpd, then "adjtimex -f 0" to reset the frequency
offset. Then give either "tickadj 10117" or "tickadj 9883" depending on
whether your clock was 11700 ppm too slow or too fast. (10000 is the default
value for tickadj). Don't start ntpd yet. Use the eyeball-and-wristwatch
method to check if the clock is better now. Now ntpd should be able to
control the clock.

Petri Kaukasoina <kaukasoina802n54jc045 DeleteThis @sci.fi> wrote:
>root <NoEMail DeleteThis @home.org> wrote:
>>After over two hours of operation
>>I had drifted by 84 seconds, which is just the
>>drift I had always been getting.
>
>So, the rate of your clock is about 11700 ppm too fast or too slow.

By the way, which clock source are you using?

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

For example, if you are not using "acpi_pm" but if it is available, you
could try to use it (as root):

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

root <NoEMail.RemoveThis@home.org> wrote:
>
> I was told that the poll entry above should gradually increase to
> 1024. In fact I have never seen it change from 64. The jitter entry changes.
>

The system has been running for 3 hours now. ntpq -p yields:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 60 64 377 0.000 0.000 3.906
perturb.org 69.25.96.13 2 u 1013 1024 377 35.927 86638.8 9604.60
router.w0ss.com 67.128.71.65 3 u 1010 1024 377 88.084 86658.5 9632.20
rikku.vrillusio 64.236.96.53 2 u 42 1024 377 80.385 95739.1 9598.11
li4-205.members 132.239.1.6 2 u 35 1024 377 14.733 86180.4 9626.63
tick.ucla.edu .GPS. 1 u 37 1024 377 11.808 95789.4 9620.79

And all the external polls have risen to 1024. I synched time just before
I started ntpd. It has been running 3 hours now and the time has drifted
off by 154 seconds: I think it is drifting more than without ntpd.

It was suggested that I should set the kernel option for high precision
time resolution. I didn't do that. Is it possible that there is some
kernel option I should set for ntpd to work?

I would have designed ntpd to set the time immediately after invocation
(which it doesn't). I would have ntpd poll the servers at some frequency
and keep track of the acccumulated error while computing and updating
the drift factor. Over time I would expect the drift factor would
stabilize and I would decrease the frequency at which I polled the
servers. I don't see any of this behavior, the drift factor has remained
at 1.211 since it was changed, whenever it was changed. The time
is never set correctly after ntpd is started. I shut the machine down
every day, it is never up for longer than 15 hours at a time. Does
ntpd assume the machine is on 24/7 and that it can take days before
the timekeeping corrects itself?

Petri Kaukasoina <kaukasoina802n54jc045.DeleteThis@sci.fi> wrote:
> root <NoEMail.DeleteThis@home.org> wrote:
>>After over two hours of operation
>>I had drifted by 84 seconds, which is just the
>>drift I had always been getting.
>
> So, the rate of your clock is about 1170 ppm too fast or too slow. ntpd can
> fix the rate only if it's less than 500 ppm off if I remember right.
>
> Try this: first kill ntpd, then "adjtimex -f 0" to reset the frequency
> offset. Then give either "tickadj 10117" or "tickadj 9883" depending on
> whether your clock was 1170 ppm too slow or too fast. Don't start ntpd yet.
> Use the eyeball-and-wristwatch method to check if the clock is better now.
> Now ntpd should be able to control the clock.

OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
I will repost when the machine has run an hour.

Is the tickadj tick=xxx preserved over reboot. If so,
I will screw around until the timekeeping is good enough.

Thanks.

Petri Kaukasoina <kaukasoina802n54jc045.TakeThisOut@sci.fi> wrote:
> Petri Kaukasoina <kaukasoina802n54jc045.TakeThisOut@sci.fi> wrote:
>>root <NoEMail.TakeThisOut@home.org> wrote:
>>>After over two hours of operation
>>>I had drifted by 84 seconds, which is just the
>>>drift I had always been getting.
>>
>>So, the rate of your clock is about 11700 ppm too fast or too slow.
>
> By the way, which clock source are you using?
>
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>
> For example, if you are not using "acpi_pm" but if it is available, you
> could try to use it (as root):
>
> echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

The first gives me jiffies. The second says I can use
jiffies or tsc.

root <NoEMail.DeleteThis@home.org> wrote:
>OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
>I will repost when the machine has run an hour.
>
>Is the tickadj tick=xxx preserved over reboot. If so,
>I will screw around until the timekeeping is good enough.

It's reset in reboot. If the line helps, you could put it for example in
/etc/rc.d/rc.local or maybe in /etc/rc.d/rc.M just before the line starting
/etc/rc.d/rc.ntpd. Preferably with the whole path:

/usr/sbin/tickadj 10117

root <NoEMail.DeleteThis@home.org> wrote:
>
> OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
> I will repost when the machine has run an hour.
>
> Is the tickadj tick=xxx preserved over reboot. If so,
> I will screw around until the timekeeping is good enough.
>
> Thanks.

The adjtimex man page was a gift, thanks. I played around
with various tick values. It turns out you need not run
the system for any longer than 10 minutes with a given
tick value to resolve the "correct" value to within +/- 1
After trying your original value, I found I needed to
correct 10117 to 10094. Finally I had to change that to
10093:
10094 after 10 min -.208 sec
10093 after 10 min .022 sec

It's a very easy process. I put the tick setting in
rc.local, and I also call ntpdate to set the clock
when I power up.

I have restarted ntpd, and will check after running
100 minutes.

Thanks again.