Date: 12 Nov 2002 19:41:18 -0600 From: "Michael A. Mackey" <michael-mackey@uiowa.edu> To: freebsd-alpha@freebsd.org Subject: RE: Extreme time drift in SMP mode Message-ID: <1037151683.28038.117.camel@focaccia.>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1037151683.28038.117.camel>