🚀 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.