From owner-p4-projects Thu Jan 2 7:59:34 2003 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 0925B37B40C; Thu, 2 Jan 2003 07:59: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 7014D37B405 for ; Thu, 2 Jan 2003 07:59:25 -0800 (PST) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id AACDC43EB2 for ; Thu, 2 Jan 2003 07:59:24 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 8781 invoked from network); 2 Jan 2003 15:59:26 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Jan 2003 15:59:26 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h02FxMUT059859; Thu, 2 Jan 2003 10:59:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200301012203.h01M3nKH028011@repoman.freebsd.org> Date: Thu, 02 Jan 2003 10:59:30 -0500 (EST) From: John Baldwin To: Marcel Moolenaar Subject: RE: PERFORCE change 23029 for review Cc: Perforce Change Reviews 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 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 -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message