lkml.org 
[lkml]   [1999]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Alpha Timekeeping - Hardware Questions
On May 14, 12:15am, Jay.Estabrook@digital.com wrote:
>
> >>> "David S. Miller" said:
> > Date: Thu, 13 May 1999 09:16:56 -0700
> > From: Richard Henderson <rth@cygnus.com>
> >
> > I have no definitive answer, but I would strongly suspect we cannot
> > rely on tick mechanisms with SMP.
> >
> > Unless Alpha's support different clock rate cpus mixed into a single
> > machine, you can use something like Ingo's tick calibration code at
> > boot time to make sure all cpu's have synchronized tick values.
>
> I don't believe that any of our boxes support CPUs at different clocks
> at the same time... ;-}
>
> But that's a good idea, WRT those patches, as I have been seeing one
> effect of routing all interrupts to CPU #0: its tick-count (IRQ #8)
> lags behind the counts in the other CPUs... :-\

[ ... ]

I'm sorry to keep harping on this, but I still don't know the answer to
the original main question.

In late November I submitted a patch to arch/alpha/kernel/time.c to fix
some obvious problems and to try to stabilize timekeeping. A non-obvious
consequence of this patch was that timekeeping was now based on the
cycle counter, instead of the RTC or PIT. The RTC/PIT was still used as
a "wakeup", but not as the actual basis for kernel jiffies.

This patch was added to the kernel, but I missed it when scanning the
patch files, so I assumed it had been rejected. In the meantime I found
some cases I had overlooked (mostly in settimeofday()) and updated my
local patches to fix these.

At the end of December I rechecked and discovered that the original patch
had been accepted, so I submitted the second fix with a note that perhaps
it should wait until 2.3, as I thought 2.3 was imminent.

The second patch was rejected, leaving timekeeping still broken, although
perhaps not quite as badly as it had been.

Around the beginning of March I had correspondence with another Alpha user
who was quite dissatisfied with the timekeeping. The main symptom was
that time-of-day sometimes jumped backward. After much email I found
most of the remaining problems. I submitted another patch but included
the suggestion/request that the original patch be backed-out, as by then
I had read the claim that SMP Alpha CPUs have unsynchronized clocks.

This patch was also rejected or perhaps missed, as I sent it only to the
list in hope of clarification from someone.

Around the end of April someone else (Thorsten Kranzkowski) submitted a
patch fixing part of the lost-tick accounting, which was in patch three.
Someone else referred Thorsten to my earlier message, and he resubmitted
that patch with some changes.

The point of this long harangue is that Alpha kernels currently use the
cycle counter for timekeeping. If SMP Alpha clocks are unsynchronized,
this is a Bad Thing. Please note that "unsynchronized" refers to the
frequencies, and not phase differences. To restate this, as there may be
some confusion, a frequency difference implies that the offsets between
different CPU cycle counters *change* over time. For example, a frequency
difference of one part-per-million would cause a drift of one jiffy in
about fifteen minutes.

The only way frequency differences can be avoided is to use a common
clock source across CPUs. This could either be the actual clock used as
input to the CPU, or it could be a slower clock that is phase-locked to
the CPU input clock.

So the question remains: Do SMP Alpha CPUs have synchronized input clocks?

If they are not sychronized, this code must be replaced with something
else.

If they are synchronized, SMP timekeeping can be fixed by either resetting
the cycle counters via PalCode at boot time, or by measuring the offsets
at boot time.

Assuming synchronized clocks, the pros and cons for using the cycle counter
appear (to me) to be:

Con:

The underlying clock may be less stable than the RTC or PIT. Assuming
synchronized CPU clocks, I would expect the PIT to be derived from the
same source.

Pro:

The cycle counter provides two orders-of-magnitude better resolution than
the PIT. The PIT counter can be accessed, giving about one microsecond
resolution.

The cycle counter provides five orders-of-magnitude better resolution than
the RTC. The RTC offers no resolution beyond the fact that an interrupt
occurred.

--
B. D. Elliott bde@nwlink.com (Seattle)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.043 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site