--=_courier-15858-1048280736-0001-2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Fri, 2003-03-21 at 00:01, george anzinger wrote:
> Joel Becker wrote:
> > If the system is delayed (udelay() or such) by a driver or=20
> > something for 10 seconds, then you have this (assume gettimeofday is
> > in seconds for simplicity):
> >=20
> > 1 gettimeofday =3D 1000000000
> > 2 driver delays 10s
> > 3 gettimeofday =3D 1000000000
> > 4 timer notices lag and adjusts
>=20
> Uh, how is this done? At this time there IS correction for delays up=20
> to about a second built into the gettimeofday() code. You seem to be=20
> assuming that we can do better than this with clock monotonic. Given=20
> the right hardware, this may even be possible, but why not correct=20
> gettimeofday in the same way?
Because to to it properly is slow. Right now gettimeofday is all done
with 32bit math. However this bounds us to ~2 seconds of counting time
before we overflow the low 32bits of the TSC on a 2GHz cpu. Rather then
slowing down gettimeofday with 64bit math to be able to handle the crazy
cases where timer interrupts are not handled for more then 2 seconds, we
propose a new interface (monotonic_clock) that provides increased
corner-case accuracy at increased cost.=20
thanks
-john
--=_courier-15858-1048280736-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQA+e3vHMDAZ/OmgHwwRAtTMAKCYEYJ2ObO4kPXVE5WB7i64f5ZRegCffMnu
q5lR/TlByZcnDZMHbBB8k0Y=
=vuPI
-----END PGP SIGNATURE-----
--=_courier-15858-1048280736-0001-2--