On Wed, 2008-08-06 at 08:56 +0100, michael wrote:
> 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
>
> sudo /etc/init.d/ntpd stop
> sudo /usr/sbin/ntpdate 130.88.200.6
>
> then it resets it to the correct time, so how come it's losing time?
>
> I was expecting to see stats in /var/log/ntpstats (as per my Debian box)
> but that dir doesn't exist on this Fed box...
>
> Any ideas folks? Ta, M
>
Are you running NetworkManager? If so ntp will not run without some
extra finagling since the network has not been created when the init.d
script for ntpd is run.
--
================================================== =====================
One can never consent to creep when one feels an impulse to soar. --
Helen Keller
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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
> >> by "a local time machine" do you mean:
> >> server 127.127.1.0
> >> ???
> >>
> >> or
> >> server 130.88.200.6 burst
> >> restrict 130.88.200.6 mask 255.255.255.255 nomodify notrap noquery
> >> ???
> >
> >
> > I didn't mean 127.127.1.0 (no idea what that means...) and yes I did
>
> 127.127.1.0 = local _system_ clock ... not a real accurate time source...
> please don't use it until you understand it.
>
> > mean 130.88.200.6 although I've no idea what those server/restrict cmds
> > are about
>
> From the data you got from ntpq below, you don't need to change what you
> have right now.
>
> >

{}

> > okay, restarted ntpd from cmd line, waiting 15 mins and here's ntpq =p
> > gives:
> > mkb@veri:/var/log$ sudo /usr/sbin/ntpq -p
>
> I don't think you have to be super user to do ntpq -p.
>
> > 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

> 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

[root@veri tmp]# service ntpd stop
Shutting down ntpd: [ OK ]
[root@veri tmp]# ntpdate ntp2.mcc.ac.uk && hwclock --systohc
7 Aug 15:37:07 ntpdate[30359]: step time server 130.88.200.6 offset
1060.330035 sec


[root@veri tmp]#
[root@veri tmp]#
[root@veri tmp]# service ntpd start
Starting ntpd: [ OK ]
[root@veri tmp]# sleep 128 && /usr/sbin/ntpq -p
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
[root@veri tmp]# sleep 10
[root@veri tmp]# exit
exit

mkb@veri:/tmp$



> >
> > and ntpd reports in /var/log/messages:
> >
> > Aug 6 16:14:35 veri ntpd[13480]: ntpd 4.2.4p2@1.1495-o Tue Aug 21
> > 13:58:55 UTC 2007 (1)
> > Aug 6 16:14:35 veri ntpd[13481]: precision = 1.000 usec
> > Aug 6 16:14:35 veri ntpd[13481]: Listening on interface #0 wildcard,
> > 0.0.0.0#123 Disabled
> > Aug 6 16:14:35 veri ntpd[13481]: Listening on interface #1
> > wildcard, ::#123 Disabled
> > Aug 6 16:14:35 veri ntpd[13481]: Listening on interface #2 vmnet8,
> > fe80::250:56ff:fec0:8#123 Enabled
> <SNIP>
> > Aug 6 16:14:35 veri ntpd[13481]: Listening on interface #10 vmnet8,
> > 172.16.232.1#123 Enabled
> > Aug 6 16:14:35 veri ntpd[13481]: kernel time sync status 0040
> > Aug 6 16:14:35 veri ntpd[13481]: frequency initialized 197.849 PPM
> > from /var/lib/ntp/drift
> >
>
> Wow that's a lot of interfaces.


yeah I thought that but I think that's all due to VMWARE


>
> >
> >
> >>> I was expecting to see stats in /var/log/ntpstats (as per my Debian box)
> >>> but that dir doesn't exist on this Fed box...
> >>>
> >> You have to config ntpd (in /etc/ntp.conf) to keep the stats, which are most
> >> times not needed, and I don't remember what config items have to be set to
> >> keep those stats.
> >
> > arg, was looking at /etc/sysconfig/ntpd
> >
>
> you _might_ add the -s whereIwantStats in /etc/sysconfig/ntpd OPTIONS=

I'll try that.

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

ta, M

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Wed, 2008-08-06 at 18:16 +0200, Björn Persson wrote:
> michael wrote:
> > mkb@veri:~$ sudo /usr/sbin/ntpq -p
> > remote refid st t when poll reach delay offset
> > jitter
> > ================================================== =========================
> >===
> > utserv.mcc.ac.u 193.62.22.98 2 u 7 64 1 2.575 348421.
> > 0.001
> >
> > but not sure what that means....
>
> · Your time is not synchronized yet, as the line begins with a space. If NTPD
> thinks the server seems reliable it will synchronize to it, and an asterisk
> should appear before the server's name.
> · remote: NTPD is talking to utserv.mcc.ac.u... (The name is truncated.)
> · refid: utserv is synchronized to 193.62.22.98.
> · st: utserv is at stratum 2, so you'll be at stratum 3.
> · I'm not sure about the "t" field. It might mean type of timesource.
> · when: NTPD latest queried utserv 7 seconds ago.
> · poll: The interval between queries is currently 64 seconds. This will
> gradually increase to 1024 seconds if the communication works well.
> · reach appears to be an array of eight bits represented as an octal number.
> It keeps track of whether responses were received to the eight latest
> queries. As you just started NTPD there's only been one query so far. If no
> packets are lost the value will eventually be 377.
> · delay: A roundtrip to utserv and back takes 2.575 milliseconds. I don't know
> if this is the latest roundtrip or some sort of average.
> · offset: Your time differs with 348.421 seconds from utserv's time. When
> synchronized, NTPD should be able to keep this below a tenth of a second.
> · jitter is, as far as I understand, a measure of the server's stability. If
> its time doesn't appear to be running uniformly, the jitter value will be
> high. (Varying delays in communication can cause this.)
>
> Björn Persson

most useful! thanks!!

M


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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'




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

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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

The various oscillators in a typical computer aren't high-precision clocks.
Without NTP you'll have to adjust the time frequently.

If you turn the computer off, and when you turn it on again it thinks it's the
first of January 1990 or something, then you probably need to replace the
battery.

> 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.

When NTPD is running, however, it will inform Linux that the system time is
synchronized to a time source, and Linux will then keep the hardware clock in
synch with the system time. You may need to run "hwclock --systohc" once if
it's off by half an hour or more, but after that it should stay correct as
long as NTPD is running. That way, if the system crashes the time should
still be reasonably right when it comes back up.

Björn Persson
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

---- "Björn Persson" <bjorn@xn--rombobjrn-67a.se> wrote:
> Todd Denniston wrote:
> > > One other bit of info, if I turn off ntpd over night, the clock loses
> > > time (new battery required?)
>
> The various oscillators in a typical computer aren't high-precision clocks.
> Without NTP you'll have to adjust the time frequently.
>
> If you turn the computer off, and when you turn it on again it thinks it's the
> first of January 1990 or something, then you probably need to replace the
> battery.
>

IIRC the startup scripts for ntpd used to make a call to ntpupdate (not sure if this is excatly the correct command name) which would set the local clock to something close to (a couple of seconds) the correct time and ten ntp would slowly synchronize the time to within a couple of milliseconds. ntpupdate has been depreciated and now the -g flag to ntpd does the same job. As long as you have an internet connection your time shouldn't be too far off. If you lose the internet, you'll fall back to using your local clock and start to drift from the correct time.

Steve


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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@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
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@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
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@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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@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@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@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@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Tue, 2008-08-12 at 10:32 -0400, Todd Denniston wrote:
> 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've seen some PCs where it's *only* run off the battery. i.e. There is
no mains supplied power to the clock when the PC is running.

--
[tim@localhost ~]$ uname -r
2.6.25.11-97.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list