From owner-freebsd-alpha Tue Nov 12 17:41:35 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 130E837B4CA for ; Tue, 12 Nov 2002 17:41:32 -0800 (PST) Received: from server07.icaen.uiowa.edu (server07.icaen.uiowa.edu [128.255.17.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE9C43E42 for ; Tue, 12 Nov 2002 17:41:31 -0800 (PST) (envelope-from michael-mackey@uiowa.edu) Received: from server11.icaen.uiowa.edu (server11.icaen.uiowa.edu [128.255.17.51]) by server07.icaen.uiowa.edu (8.9.3/8.9.3) with ESMTP id TAA09908 for sent by ; Tue, 12 Nov 2002 19:41:42 -0600 (CST) Received: from focaccia. (12-217-236-86.client.mchsi.com [12.217.236.86]) by server11.icaen.uiowa.edu (8.9.3/smtp-service-1.6) with ESMTP id TAA14640 for ; sent by ; Tue, 12 Nov 2002 19:41:21 -0600 (CST) Subject: RE: Extreme time drift in SMP mode From: "Michael A. Mackey" To: freebsd-alpha@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Nov 2002 19:41:18 -0600 Message-Id: <1037151683.28038.117.camel@focaccia.> Mime-Version: 1.0 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, I still don't think I understand. I just built a non-SMP version of the modified kernel (with only the single change previously described) and rebooted. Now, the system loses time (about 5 min every 10 minutes) and sleep 10 takes 20 seconds on an unloaded system. So, the dreaded slow-down is back, this time for a UP system. I will be receiving 2 more processors in a day or two, and then we can see if the two-processor case reported earlier can be generalized to the four-processor one. Nevertheless, I really don't see why the UP system loses time. On Tue, 2002-11-12 at 17:49, Terry Lambert wrote: > "Michael A. Mackey" wrote: > > I guess I don't understand the problem. > > Adjusting the timer frequency, as John suggested, would give the > appearance of a fix, but would not really fix the problem: if > you do that, you are assuming that an exactly equal number of > interrupts per interval come from each processor. This is true > statistically, but not overall. > > > > It seemed to me that the problem was that not all the interrupts were > > being delivered because the Lynx architecture expects each processor to > > generate interrupts. Before the fix, the system lost time by an amount > > which was equivalent to throwing away half of the interrupts. After my > > modification, each processor is allowed to generate clock interrupts, > > and the system receives the complete set of interrupts, yielding the > > result that the system keeps time correctly. > > Yes. IMO, your modification is the correct one; John's suggested > change would be statistical in nature, at best. The disadvantage > of your approach is that it implies that the clock interrupt > handling code needs to be reentrant, which it might not be, since > there is an implicit expectation of only a single hardware clock > interrupt source. > > > > I'm sure that this is a naive picture of what's going on (and I'm not a > > kernel developer), but it works. I realize that it is probably specific > > to the Lynx architecture, and I of course would be happy for a 'correct' > > way to allow this old box to happily crank along solving PDE's. > > As I implied in my previous posting, I think your fix is the > correct one, and John's would be a statistical fix, at best, > which I would not trust. > > An interesting question would be whether or not you can have > different clock rates for different CPU's on the box, and what > happens in that case (whether the answer is right or not). > > As the clock is calibrated on a single CPU at startup, it's a > problem of interrrupt routing being symmetric vs. generation > being symmetric; if it's the former, then you're OK, and if it's > the latter, then John's fix is better, even if it is only > statistical. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message