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