Date: Tue, 12 Nov 2002 16:44:59 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: "Michael A. Mackey" <michael-mackey@uiowa.edu> Cc: freebsd-alpha@freebsd.org Subject: Re: Extreme time drift in SMP mode Message-ID: <XFMail.20021112164459.jhb@FreeBSD.org> In-Reply-To: <1037135718.27957.17.camel@focaccia.>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12-Nov-2002 Michael A. Mackey wrote:
> 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.
Well, that's not really an ideal fix for the problem. :( Adjusting
the timer frequency in the SMP case instead would be preferred.
> 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
>
>
>
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.20021112164459.jhb>