[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 440FX PCI CHIPSET performance




On 09 Sep 96, LEROUXJ@tmmrdf1.rennes.tcetbs1.thomson.fr wrote:

> for the moment we experiment the AMMC S5933 controller PCI bus
> in bus mastering mode with the Triton 430FX chip set: data transfer
> between the DRAM of the PC and the S5933 chip with use of the
> AMMC developer's kit to which we added our own breadboard daughter card.
> Transfer rate: up to 115MByte/s
> 
> QUESTION 1:
> We move to a new Natoma 440FX based Pentium Pro PC
> motherboard = the transfer rate falls dramatically.
> Does anyone may give us informations on the topic?

I have a very similar experience. I have a PCI mastering card that is
capable of testing sustained PCI accesses at rates between 1 and
133 mbytes/sec, using full speed MRM/MWI bursts of up to 256 cycles.
(It uses the PLX 9060SD chip)

I have successfully tested an Intel Pentium system using conventional
RAM and the 430VX PCI chipset at sustained rates of between 50 and 75
Mbytes/sec for both reads and writes, 

I have tested two Pentium Pro based systems that use the 440FX chipset,
and had very disappointing results.

One system has two Pentium Pro processors and conventional RAM, while
the other has one processor and EDO RAM.

For much of the time these systems seem to have comparable (or better)
performance to the 430VX based system, but for certain periods of time,
(e.g. when there is any slight CPU activity) available PCI <-> DRAM
bandwidth drops alarmingly. 

Bruce Young wrote:

> well. The 440FX will disconnect a plain old Memory Read at the first cache line 
> boundary. The 440FX may also disconnect MRL & MRM at cache line boundaries due 
> to extremely heavy CPU bus congestion but will almost always allow them to 
> continue until a 4k page boundary. The 440FX behaves differently than the 430 
> family due to the increased complexity of the Pentium Pro bus.

I don't know if there is "extremely heavy CPU bus congestion", but the
impact on PCI<->DRAM bandwidth is dramatic. I have measured periods
of up to 4 msec (that's milliseconds) where available bandwidth was
less than 10 Mbytes/sec.

During these periods I see the following activity on the PCI bus:

Start:
  Request PCI bus, and are granted it in 1 cycle
  Assert FRAME and IRDY
  After 31 cycles, the 440FX asserts STOP for 2 cycles [ Retry ]

  De-assert FRAME, IRDY and REQ.

  Request PCI bus, and are granted it in 1 cycle
  Assert FRAME and IRDY
  After 17 cycles, the 440FX asserts TRDY for 8 cycles [Transfer 8 32 bit words]
  TRDY goes inactive for 2 cycles.
  The 440FX asserts STOP for 2 cycles. [ Retry ]

  De-assert FRAME, IRDY and REQ.

  Loop to start.

This goes on for most of the 1-4 msec. With this behavior, the PCI bus is
100% utilized at 15 Mbytes/sec. Occasionally there will be longer bursts
than 8 words, but these bursts will have TRDY de-asserted for over
50 % of the normal data transfer time. As soon as another PCI bus master
wants some bandwidth (or the CPU needs to get onto the PCI bus), the
bandwidth drops some more.

Has anyone got some ideas on how to avoid this behavior, and
get the performance of the 440FX up to the level it should be at ?

Graeme Gill
graeme@digideas.com.au

Digital Ideas P.L.

Ï0