time/ntp[d]
Todd Denniston
Todd.Denniston at ssa.crane.navy.mil
Tue Aug 12 14:32:54 UTC 2008
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 at 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 at 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 at 1.1495-o 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 at 1.1495-o 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 at 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
More information about the fedora-list
mailing list