Re: Nasty suprise with uptime

[Tim Walberg]

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hmm... ever hear of NTP? My general rule of thumb:
Never trust any CMOS clock; let the kernel keep track
of time and periodically update the CMOS clock so
that you (hopefully) get a reasonable starting point
when you boot. Trusting any clock with a cheap power
source to provide accurate time-keeping is an exercise
in futility... (and it's not necessarily the power
source's fault - even an outrageously expensive power
source doesn't guarantee good time-keeping). I think
of a CMOS clock as kind of a book mark. If the book
mark gets lost, I can still find where I left off,
it just takes a little more work.

			tw

On 10/30/2001 15:47 +0100, GOMBAS Gabor wrote:
>>	On Tue, Oct 30, 2001 at 07:50:43AM -0600, Tim Walberg wrote:
>>=09
>>	> Wouldn't it be fairly simple for the kernel to just remember the (wall
>>	> clock) time at boot, and uptime just subtract that from the current
>>	> (wall clock) time?
>>=09
>>	So every people with faulty CMOS batteries would have 30+ years of
>>	uptime. And if the CMOS date is ahead of the real one and the admin
>>	sets it back, you will get negative uptimes etc. If you want such
>>	amusements, it is far easier to write an uptime program that just calls
>>	random() instead of asking the kernel :)
>>=09
>>	Gabor
>>=09
>>	--=20
>>	Gabor Gombas                                       Eotvos Lorand Univers=
ity
>>	E-mail: [e-mail]                        Hungary
End of included message

--=20
[e-mail]

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBO97Jn8PlnI9tqyVmEQK8rwCeLqVi5rGs5+O0mvzv5dlV4zcsLgIAnRbv
PNkbeg/FP4YMiJRU4ZEikh1+
=w6qh
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--