>
> On Wed, 29 Jul 1998, Alan Cox wrote:
>
> > Also I have an Ingo project - Ingo can you write a PCI bus speed measurer
> > for the kernel - is it possible.
>
> i think it's quite hard to find a generic method. On SMP it's easy, the
> PCI bus speed is half of the APIC bus speed. (and we already calculate the
> APIC bus clock speed)
I don't have any SMP board, but I have always doubted very much the
figures seen on the bootlogs of the mailing list for at least 2 reasons:
- there is an Pentium specification clarification somewhere saying that
some processor APIC clock inputs is very sensitive to reflections although
the APIC bus has quite alow frequency.
- the specifications of PICCLK for Pentium give a frequency range of 2 to
16.67 MHz (60 to 500 ns period). For the PPro and PII the max frequency
has been raised to 33.33 MHz (30 ns period). (All the figure from Intel's
doc which can't be that wrong).
Note that what is measured in arch/i386/smp.c is the APIC timer frequency,
the documentation clearly states that it bears no relationship with the
APIC bus clock: "The time base is derived from the *processor's* bus
clock, divided by a value specified in the divide configuration register."
So the message printed on boot is at best misleading...
(I have the
feeling that measuring the APIC bus clock frequency is impossible except
perhaps indirectly with the remote read function).
> on UP it's hard as we do not have an APIC (or enabled). We might be able
> to measure the memory bus speed, but the multiplier between the PCI bus
> and the memory bus is not necessarily 2.0. (think 100MHz Super7
> motherboards, BX chipsets, etc.)
>
> so the only thing left is to poke the PCI bus directly and measure that
> speed. Unfortunately i have found no way to create some reliable
> nonintrusive transaction on the PCI bus that can be measured. maybe
> reading the config space takes some constant number of PCI cycles?
The only thing which has a well defined timming on a PCI bus is the
timeout, i.e., accessing a non present device generating a master abort.
(AFAIR if DEVSEL# is not asserted 8 clocks after FRAME#). Taking into
account all HW layers (bus arbitration, host bridge...), the best would
perhaps be to measure the difference in time between an access to the
configuration space of the host bridge (which does _not_ go to the PCI
bus) and an access to the configuration space of a nonexistent device.
But even then I don't think that you can reliably measure the PCI bus
clock frequency, especially since the difference you want to measure (37.5
vs 33.33 MHz) is only 12.5%: the access to internal configuration
space of the host bridge could be quite slow for any reason (it's not
performance critical at all).
Gabriel.
-
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.altern.org/andrebalsa/doc/lkml-faq.html