From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <609fa6e57786ca89ae54d85144ba7630@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rio and acme scrolling
From: Sape Mullender <sape@huygens.org>
In-Reply-To: <466a2993c3a0232a58065be590e2a716@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Sat, 27 Mar 2004 10:07:12 -0500
Topicbox-Message-UUID: 44c4a92c-eacd-11e9-9e20-41e7f4b1d025

> The clock (timer 2) speeds up by a factor of 5 or so.
> I can only assume that the firmware uses it for something
> to do with detecting the lid opening again.
> 
> Timesync doesn't change the local hardware, it just
> tweaks the kernel's idea of what time it is and of
> what the clock frequency is.  It would cope with
> the clock change except that I made timesync ignore any huge
> swings (anything more than 25%) because I had assumed that
> would only be the result of a samplng mistake.
> 
> I changed the limits and timesync will now put up with such a
> change, though it will take some minutes to latch onto
> the exact new value (needs enough of a time base to
> compare to).
> 
> Tell me if this is a problem.  Short of actually
> implementing ACPI, I think this is as good as we can
> do.

Does this work if timesync doesn't have an external time source to synchronize to?

	Sape