Date: Fri, 03 Jan 2003 11:09:18 -0800 From: Peter Wemm <peter@wemm.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: John Baldwin <jhb@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 23029 for review Message-ID: <20030103190918.044292A8A8@canning.wemm.org> In-Reply-To: <20030102201437.GB616@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > On Thu, Jan 02, 2003 at 10:59:30AM -0500, John Baldwin wrote: > > > > On 01-Jan-2003 Marcel Moolenaar wrote: > > > http://perforce.freebsd.org/chv.cgi?CH=23029 > > > > > > Change 23029 by marcel@marcel_nfs on 2003/01/01 14:03:34 > > > > > > While here, reload cr.itm (interval timer match register) > > > based on the old value of cr.itm and not cr.itc (interval > > > timer counter). The value of cr.itc is non-deterministicly > > > close to the value of cr.itm at the time of the interrupt. > > > The SDM clearly states that they are not guaranteed to be > > > identical, even though the interrupt is triggered when > > > cr.itc equals cr.itm). Reloading cr.itm based on the value > > > of cr.itc will therefore introduce a non-deterministic error > > > in the clocks. This will also reduce clock skew due to > > > interrupt latency. > > > > Cool. Peter says the Linux code does something similar but goes > > to extra efforts to handle the case of missing entire ticks and > > what not.w > > Yeah, that hit me after committing and I noticed that sparc64 does > that too. As you have probably seen, I reverted the change for now. > A missed clock interrupt is worse than a slight error. > > Doug got me a bit confused though, so I won't touch the code until > I deconfused myself :-) I've half done something based on what the linux folks did. What they do is check that they do not set the new cr.itm to be too close to the current cr.itc. They keep per-cpu track of when they're expecting the next tick to happen and "catch up" if needed. They never set the new cr.itm to less than half of the tick interval away from the current cr.itc. However, they also use this for keeping data about each cpu's cr.itc in sync for use as a timecounter so they need to go to the extra trouble. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030103190918.044292A8A8>