time/ntp[d]

[Todd Denniston]

michael wrote, On 08/07/2008 10:47 AM:
> On Wed, 2008-08-06 at 15:40 -0400, Todd Denniston wrote:
>> michael wrote, On 08/06/2008 11:42 AM:
>>> On Wed, 2008-08-06 at 09:20 -0400, Todd Denniston wrote:
>>>> michael wrote, On 08/06/2008 03:56 AM:
>>>>> It seems my clock is losing time but yet I have 'enable Network Time
>>>>> Protocol' enabled and set to a local time machine. If I
<SNIP>
>>> Password:
>>>      remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> ==============================================================================
>>>  utserv.mcc.ac.u 193.62.22.98     2 u   14   64  377    0.303  369608.
>>> 3831.40
>>>
>>> but it's still out:
>>>
>>> mkb at veri:/var/log$ date
>>> Wed Aug  6 16:41:41 BST 2008
>>>
>>> mkb at veri:/var/log$ ssh michael at ratty date
>>> Wed Aug  6 16:47:57 BST 2008
>>>
>> 16:41:41 + 0:6:9 =~ 16:47:50 so it took you ~7 seconds to type the ssh over to 
>> ratty? :)
>> i.e., matches roughly with what ntpd is indicating.
> 
> it's 6 mins 16 secs diff and no, I did the second cmd within seconds to
> show that there is a diff in times

Exactly what I meant.
offset (from ntp) = 369608 =~ 6 minutes 9 seconds
and it took you another 7 seconds to type 'ssh michael at ratty date'

> 
>> try doing the as root (i.e., `su -` and then run the) following:
>> service ntpd stop
>> ntpdate && hwclock --systohc
>> service ntpd start
>> sleep 128 && /usr/sbin/ntpq -p
>> sleep 10
>> exit
> 
> okay, had to give it a timeserver but here's the o/p
> 
<SNIP>
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  utserv.mcc.ac.u 193.62.22.98     2 u    3   64    7    0.537  1812.41
> 1353.83

Has the offset settled down yet? (i.e., dropped below 128)

BTW assuming ntpd is still running it might be interesting to run
date && \
ntpdate -d ntp2.mcc.ac.uk && \
ntpdate -d utserv.mcc.ac.uk && \
hwclock --show && \
date

<SNIP>
>> Wow that's a lot of interfaces.
> 
> 
> yeah I thought that but I think that's all due to VMWARE
> 
I hope you mean that there are VMWARE instances running ON this server, not 
that this server is running IN a VMWARE instance.

Reason: it is a known problem that OSs inside VMWARE are not able to keep good 
time with ntp.

<SNIP>
> One other bit of info, if I turn off ntpd over night, the clock loses
> time (new battery required?)

no, unlike MS, Unix system clock uses the frequency ticker on the CPU to keep 
time, which is independent of the battery backed TOY clock.
i.e., after shutting ntpd off run:
date;/sbin/hwclock --show;date
then after you have slept
date;/sbin/hwclock --show;date

I expect the time from the date commands to have drifted as you are seeing, 
but the time from hwclock will have drifted differently.
date -> returns system time
hwclock -> returns TOY clock time.




-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter