Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

[Nigel Cunningham <ncunningham@linuxmail.org>]

Hi.

On Wed, 2005-02-02 at 11:27, john stultz wrote:
> > We call the suspend and resume methods because the suspend is supposed
> > to achieve atomicity, and the resume is necessary for us to be able to
> > write the image. (Remember that these calls are invoked as part of the
> > drivers_suspend and drivers_resume code). Until recently the
> > sysdev_suspend and resume methods weren't called and things did still
> > work, but that was an omission and we did then run into time issues.
> 
> Ah! Ok, thanks for the summary.

No problem.

> > > > > I've only lightly tested the suspend code, but on my system I didn't see
> > > > > very much drift appear. Regardless, it should be better then what the
> > > > > current suspend/resume code does, which doesn't keep any sub-second
> > > > > resolution across suspend.
> > > > 
> > > > My question is, "Is there a way we can get sub-second resolution without
> > > > waiting for the start of a new second four times in a row?" I'm sure
> > > > there must be.
> > > 
> > > Well, I'm not sure what else we could use for the persistent clock, but
> > > I'd be happy to change the read/set_persistent_clock function to use it.
> > 
> > Is it possible to still use the persistent clock, but do the math for
> > the portions of seconds?
> 
> I'm not sure what you mean? Given the patch Tim just sent, it seems the
> issue is the CMOS only gives us second resolution, so we try to increase
> our accuracy by aligning the reads so we return when the second changes.
> We can avoid the read-alignment which speeds things up, but introduces
> up to a second worth of drift. If that's ok, then the trade off is worth
> it.
> 
> Alternative persistent clocks like the efi clock might provide better
> resolution and could then avoid this issue. Although I don't know for
> sure.

Ah. Okay. I hadn't looked that closely so that I realised the CMOS only
gives the accuracy we're using. Humble apologies. So then, I agree: it
would be best if we can move to something with greater precision and
make mileage from it. Is that an option on all x86 machines though? I
guess cmos is the lowest common denominator :<

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574