🚀 go-pugleaf

"Arnaud Fran�ois" <francoia@enertec.avicore.com#NOSPAM> wrote:

> In 440 BX platform, i have observed all write bursts being
disconnected at 8
> dwords (32 bytes) by the host bridge.

You are lucky. In fact, this is the first time I heard about PCI burst
with the 440BX chipset. What CPU-FSB is driven the bridge?

The limit of 8 bytes, may be, is due to the Master Latency Timer
Register. As 82443BX datasheet MLT is "an 8-bit register that controls
the amount of time the 82443BX, as a PCI bus master, can burst data on
the PCI Bus". This is one of the few registers available to configure
the PCI bus with this chipset.

> On my card (internal product), i use a component AMCC S5933 and this
card
> works at full speed (120 MBytes/s) on systems with 82439HX or 82439TX.

Really??, I had seen similar behavior for HX and BX chipsets. So your
information is amazing. I think I am going to know anymore about AMCC
S5933.

> Any idea ?

You are working with a NT driver. However, I insist that the bad "PCI
burst - PCI read" performance is not OS-dependent. CPU sees all memory
space as a whole. CPU writes-reads to memory space without knowing if it
is PCI, AGP or physical memory. The bridge is in charge to detect the
required space and manage the feasible bus procedures. Therefore, CPU
(and OS) does not know anything about it.

I think it is valuable to see again the PCI analysis (supplied by
niessene@natlab.research.phiphs.com)

Write transactions got by PCI analyzer
======================================
Sample TimeRel State C/BE#
TRIG:  0.0ns Addr MemWri
1: 30.1ns TW 0000
2: 30.1ns Data 0000
3:4: 30.1ns .... 0000 Two cycles without bus activity
5: 30.1ns Addr MemWri
6: 30.1ns TW 0000
7: 30.1ns Data 0000
8:9: 30.1ns .... 0000 Two cycles without bus activity

Read transactions got by PCI analyzer
======================================
Sample TimeRel State C/BE#
TRIG: 0.0ns Addr MemRd
1: 30.1ns TW 0000
2: 30.1ns TW 0000
3: 30.1ns TW 0000
4: 30.1ns Data 0000
5:18 30.1ns .... 0000 Fourteen!! cycles without bus activity
19: 30.1ns TW 0000
20: 30.1ns TW 0000
21: 30.1ns TW 0000
22: 30.1ns Data 0000
23:38 30.1ns .... 0000 Fourteen!! cycles without bus activity

The above data show up PCI burst never happens. But the bad PCI read
performace is even a worse problem. My own data is exactly the same.

You can see the delays do NOT happen within the PCI transfer. The delays
happen AMONG transfers.

The big question: Why???, what on the hell are doing the CPU or the
bridge during these time intervals? Besides these time intervals are
huge (14 cycles at 33MHz are 140 clocks of a 330MHz CPU).

Well..., every one must be conscious of this problem is not another more
one. This problem is a central concern about real PCI capability to
manage multimedia drivers. For instance, PCI readings are limited to
9MBs bandwidth. It is unbeliveable that 500MHz-boxes only can cope with
9MBs transfers.

Regards,



Sent via Deja.com http://www.deja.com/
Before you buy.