michael wrote, On 08/11/2008 07:46 AM:
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:
<SNIP>
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)
multicast??? is there a -m in ntpd's command line?
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
<SNIP>
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
<SNIP>
HMM, looks like ntp2.mcc.ac.uk is utserv.mcc.ac.uk in disguise.
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??!?
Yes.
system time is within 0.022 seconds of a stratum 2 host [i.e., very good host],
and the hardware clock is within 0.21 seconds of system time.
Not sure what I've "fixed"...
Getting system time within the (IIRC) 1000 second window for ntpd and getting
the hardware clock set similar so that when a reboot occurs ntpd can go back
to work. :)
Look at the second paragraph of "How NTP Operates" in [1].
<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
You still have a small but fundamental understanding problem here.
The system time is the time in the kernel that is maintained by the frequency
of the CPU, turn off the cpu or drop back to bios and system time does not
EXIST, there is no battery backed system time.
The time-of-year (TOY)* or BIOS clock is THE hardware clock in MOST "PC"
equipment, and yes it is usually backed up by a battery.
*I just realized this moniker (time-of-year or TOY) is peculiar to DEC
equipment and some ntp documentation[1] and not a general usage thing. I will
now try to stop using it, sorry for the confusion.
[1] http://doc.ntp.org/4.1.0/ntpd.htm
http://doc.ntp.org/4.2.4/debug.html
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
