From owner-freebsd-alpha Tue Nov 12 13:15:29 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 5D35B37B401; Tue, 12 Nov 2002 13:15:27 -0800 (PST) Received: from server07.icaen.uiowa.edu (server07.icaen.uiowa.edu [128.255.17.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D9943E6E; Tue, 12 Nov 2002 13:15:26 -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 PAA03220 sent by ; Tue, 12 Nov 2002 15:15:35 -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 PAA26334; sent by ; Tue, 12 Nov 2002 15:15:17 -0600 (CST) Subject: Re: Extreme time drift in SMP mode From: "Michael A. Mackey" To: jhb@freebsd.org Cc: 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 15:15:14 -0600 Message-Id: <1037135718.27957.17.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 guess I got really lucky.... I seem to have fixed the time drift problem, based on a hunch. Drew, after what you said about the boot processor alone driving the timing, I decided to allow both processors to drive the timer. So, I changed the code in the function 'alpha_clock_interrupt ()' in /usr/src/sys/alpha/alpha/interrupt.c (actually I only added an #undef SMP statement on line 467 and redefined it before the 'critical_exit()' call). And now, the SMP system keeps proper track of the time. In a couple of days, I have two more processors arriving. Then I can really test if this fix works. Thanks for your help - and I hope others can verify my results. On Tue, 2002-11-12 at 11:13, Andrew Gallatin wrote: > > Andrew Gallatin writes: > > > > Roberto de Iriarte writes: > > > > > Hmmm. my dmesg reads differently > > > BTW, my system has only one CPU, and the clock has never drifted. > > > > > > > That's the thing. The 2100 is unlike all other alphas, and handles > > clocks differently in MP mode. > > To elaborate on the above, I think most MP alphas tie the clock > interrupt to the boot cpu, and it ticks at hz. > > I think the 2100 round-robins the clock interrupt to all running cpus, > therefore the boot cpu only ticks at hz/mp_ncpus. > > Currently, we pay attention only to the boot CPU. From > alpha_clock_interrupt() in sys/alpha/alpha/interrupt.c > <...> > critical_enter(); > #ifdef SMP > /* > * Only one processor drives the actual timer. > */ > if (PCPU_GET(cpuid) == boot_cpu_id) { > #endif > (*platform.clockintr)(framep); > /* divide hz (1024) by 8 to get stathz (128) */ > if ((++schedclk2 & 0x7) == 0) > statclock((struct clockframe *)framep); > #ifdef SMP > } else { > mtx_lock_spin(&sched_lock); > hardclock_process(curthread, TRAPF_USERMODE(framep)); > if ((schedclk2 & 0x7) == 0) > statclock_process(curkse, TRAPF_PC(framep), > TRAPF_USERMODE(framep)); > mtx_unlock_spin(&sched_lock); > } > #endif > critical_exit(); > <...> > > > Given that I know zippo about how timekeeping works, I don't know > what a good fix might be. If I had a machine in front of me, > I'd be tempted to try dividing the a frequency by 2 in sys/alpha/alpha/clock.c, > but I'm not sure which one, or if it can be adjusted as additional processors > are found and started. (which would be slightly less wrong..). > > Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message