On Thu, 2008-08-07 at 11:15 -0400, Todd Denniston wrote:
> 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@veri:/var/log$ date
> >>> Wed Aug 6 16:41:41 BST 2008
> >>>
> >>> mkb@veri:/var/log$ ssh michael@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@ratty date'
okay with you now...
> >
> >> 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
well what I get now is
mkb@veri:~$ /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
+maverick.mcc.ac 193.62.22.98 2 u 24 64 377 0.311 19.721
0.321
130.88.200.98 .STEP. 16 u - 1024 0 0.000 0.000
0.000
*utserv.mcc.ac.u 193.62.22.98 2 u 49 64 377 0.334 23.639
0.629
meonis.mc.man.a .STEP. 16 u - 1024 0 0.000 0.000
0.000
(not sure where/how those extra servers came from)
NB this is after 0.5 day's downtime last night.
For above I now get
[root@veri mkb]# date && \
> ntpdate -d ntp2.mcc.ac.uk && \
> ntpdate -d utserv.mcc.ac.uk && \
> hwclock --show && \
> date
Mon Aug 11 12:43:07 BST 2008
11 Aug 12:43:07 ntpdate[5738]: ntpdate 4.2.4p2@xxxxxxxx Tue Aug 21
13:58:55 UTC 2007 (1)
Looking for host ntp2.mcc.ac.uk and service ntp
host found : utserv.mcc.ac.uk
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
server 130.88.200.6, port 123
stratum 2, precision -17, leap 00, trust 000
refid [130.88.200.6], delay 0.02588, dispersion 0.00002
transmitted 4, in filter 4
reference time: cc4aa1b2.758d7cf3 Mon, Aug 11 2008 12:32:02.459
originate timestamp: cc4aa44b.b67144bb Mon, Aug 11 2008 12:43:07.712
transmit timestamp: cc4aa44b.b0bcad9a Mon, Aug 11 2008 12:43:07.690
filter delay: 0.02649 0.02626 0.02588 0.02588
0.00000 0.00000 0.00000 0.00000
filter offset: 0.022213 0.022088 0.022145 0.022143
0.000000 0.000000 0.000000 0.000000
delay 0.02588, dispersion 0.00002
offset 0.022145
11 Aug 12:43:07 ntpdate[5738]: adjust time server 130.88.200.6 offset
0.022145 sec
11 Aug 12:43:07 ntpdate[5739]: ntpdate 4.2.4p2@xxxxxxxx Tue Aug 21
13:58:55 UTC 2007 (1)
Looking for host utserv.mcc.ac.uk and service ntp
host found : utserv.mcc.ac.uk
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
receive(130.88.200.6)
transmit(130.88.200.6)
server 130.88.200.6, port 123
stratum 2, precision -17, leap 00, trust 000
refid [130.88.200.6], delay 0.02586, dispersion 0.00000
transmitted 4, in filter 4
reference time: cc4aa1b2.758d7cf3 Mon, Aug 11 2008 12:32:02.459
originate timestamp: cc4aa44b.d20b161e Mon, Aug 11 2008 12:43:07.820
transmit timestamp: cc4aa44b.cc56a37a Mon, Aug 11 2008 12:43:07.798
filter delay: 0.02597 0.02586 0.02586 0.02586
0.00000 0.00000 0.00000 0.00000
filter offset: 0.022169 0.022142 0.022142 0.022143
0.000000 0.000000 0.000000 0.000000
delay 0.02586, dispersion 0.00000
offset 0.022142
11 Aug 12:43:07 ntpdate[5739]: adjust time server 130.88.200.6 offset
0.022142 sec
Mon 11 Aug 2008 12:43:08 BST -0.210030 seconds
Mon Aug 11 12:43:08 BST 2008
[root@veri mkb]#
err... is that good??!?
Not sure what I've "fixed"...
> <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.
yes, I run vmware on this machine (for XP) but all the ntpdate stuff is
external to vmware
> 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'll try this next time I power off the machine
> 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.
Not sure I follow all that. Surely, the hwclock must also use battery in
order to track the time?
Thanks for all your expert help,
M
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
