Re: [gentoo-user] Re: Latest unstable ntp not generating ntp.drift file.

[Dale]

Francesco Talamona wrote:
> On Thursday 06 January 2011, Dale wrote:
>
>> Francesco Talamona wrote:
>>
>>> On Wednesday 05 January 2011, Dale wrote:
>>>
>>>> Now on my old system, it would adjust the drift file and the
>>>> adjustments  would get smaller and smaller.  On the new rig, as
>>>> you can see it stays about the same.  I would like it to get to a
>>>> point where it doesn't have to sync so often.  I read on the
>>>> website where they are needing more servers to help with the load
>>>> and I don't want to be one of the ones putting a load on it.
>>>>
>>> Maybe you copied over /etc/adjtime from the previous machine. I
>>> would try to regenerate it...
>>>
>>> Ciao
>>>
>>> 	Francesco
>>>
>> I'm sure I didn't copy that.  I copied ntp.conf but that is all.  I
>> didn't even notice that one being there.  I got to see what purpose
>> that has.
>>
>> I may delete it tho and see what happens.  It would generate a new
>> one if I restart the service correct?
>>
>> Dale
>>
>> :-)  :-)
>>
> It makes the hardware clock take care of the systematic drift. If a
> wrong value is stored in it, it can interfere with ntp in the way you
> described: every time ntp runs it always corrects for the same amount.
>
>  From man 8 hwclock:
>
> "The  Hardware  Clock  is usually not very accurate.  However, much of
> its inaccuracy is completely predictable - it gains or loses the same
> amount of time every day.
>         This is called systematic drift.  hwclock's "adjust" function
> lets you make systematic corrections to correct the systematic drift."
>
> and:
> "It is good to do a hwclock --adjust just before the hwclock --hctosys
> at system startup time, and maybe periodically while the system is
> running via cron."
>
> This is my "recipe":
> let ntpdate sync your clock, then /sbin/hwclock --systohc
> and you are done. From that moment on ntp takes care of the non
> systematic error, while the drift is zeroed "by hwclock".
>
> Somewhere it is suggested to run /sbin/hwclock --adjust once a year.
>
> I experienced what you describe when I built my new machine, I had
> copied /etc/adjtime (without knowing what it was) from the previous, it
> took me a good deal of googling...
>
> BTW I don't have ntp.drift, I only use ntpdate and the clock is always
> correct.
>
> HTH
> 	Francesco
>
>

Well, I tried openntp for a good while last night and it was worse than 
ntp.  It was adjusting the clock by something like 20 seconds at a 
time.  Even ntp wasn't that bad.  I went back to plain ntp.  This is 
what ntp has sent to messages overnight while I was napping:

Jan  6 00:13:21 localhost ntpd[23712]: ntpd 4.2.6p3@1.2290-o Thu Jan  6 
05:41:55 UTC 2011 (1)
Jan  6 00:13:21 localhost ntpd[23713]: proto: precision = 0.102 usec
Jan  6 00:13:21 localhost ntpd[23713]: Listen and drop on 0 v4wildcard 
0.0.0.0 UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: Listen and drop on 1 v6wildcard 
:: UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: Listen normally on 2 lo 127.0.0.1 
UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: Listen normally on 3 eth0 
192.168.2.5 UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: Listen normally on 4 eth0 
fe80::1e6f:65ff:fe4c:91c7 UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: Listen normally on 5 lo ::1 UDP 123
Jan  6 00:13:21 localhost ntpd[23713]: peers refreshed
Jan  6 00:13:21 localhost ntpd[23713]: Listening on routing socket on fd 
#22 for interface updates
Jan  6 09:09:31 localhost ntpd[23713]: Attempting to register mDNS
Jan  6 09:09:31 localhost ntpd[23713]: *** WARNING *** The program 
'ntpd' uses the Apple Bonjour compatibility layer of Avahi.
Jan  6 09:09:31 localhost ntpd[23713]: *** WARNING *** Please fix your 
application to use the native API of Avahi!
Jan  6 09:09:31 localhost ntpd[23713]: *** WARNING *** For more 
information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=ntpd>
Jan  6 09:09:31 localhost ntpd[23713]: mDNS service registered.
root@fireball / #

It doesn't show that it is doing anything but the clock is somewhat 
accurate but it is still having to adjust it like before.  I use ntpdate 
to see how far the clock is off.  If I run it every few minutes, I can 
see it drift further away from the correct time then when ntp syncs, it 
resets it again.  It did generate the ntp.drift file but it is still not 
adjusting the clock like on my other rig.

I also read where the caps USE flag should be enabled.  I did  but it 
doesn't appear to have helped any.

I deleted the /etc/adjtime but it has not been recreated.  What creates 
this file?  I deleted it a couple days ago and nothing has brought it 
back yet.

I'm about ready to see what Linux would be like with no freaking clock 
at all.  lol   Now to see what I am going to try next.

Dale

:-)  :-)