From owner-p4-projects Fri Jan 3 11: 9:35 2003 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id BCC5F37B413; Fri, 3 Jan 2003 11:09:32 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A44F37B405; Fri, 3 Jan 2003 11:09:32 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8CB43EA9; Fri, 3 Jan 2003 11:09:23 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 044292A8A8; Fri, 3 Jan 2003 11:09:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marcel Moolenaar Cc: John Baldwin , Perforce Change Reviews Subject: Re: PERFORCE change 23029 for review In-Reply-To: <20030102201437.GB616@dhcp01.pn.xcllnt.net> Date: Fri, 03 Jan 2003 11:09:18 -0800 From: Peter Wemm Message-Id: <20030103190918.044292A8A8@canning.wemm.org> Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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