From owner-freebsd-alpha Tue Nov 12 15:50:57 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 5FF6537B401 for ; Tue, 12 Nov 2002 15:50:56 -0800 (PST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id F021543E3B for ; Tue, 12 Nov 2002 15:50:55 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0050.cvx22-bradley.dialup.earthlink.net ([209.179.198.50] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18Bko1-00076z-00; Tue, 12 Nov 2002 15:50:53 -0800 Message-ID: <3DD19384.5355662E@mindspring.com> Date: Tue, 12 Nov 2002 15:49:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael A. Mackey" Cc: freebsd-alpha@freebsd.org Subject: Re: Extreme time drift in SMP mode References: <3DD180E3.80D3C4F6@mindspring.com> <1037142521.27992.41.camel@focaccia.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 "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