[lwlan-devel] DMA support for Prism 2.5?

Thu, 4 Apr 2002 10:18:38 +0100

This is a multipart message in MIME format.
--=_alternative 0033EAAD80256B91_=
Content-Type: text/plain; charset="us-ascii"

Hi all,

I'm currently looking around for the best 802.11b silicon to use in a 
prototype system. However, I'm finding
that nearly all currently available silicon is let down due to the 
interface between the host CPU and
the MAC. At first I put this down to most of the cards I tried being 
PCMCIA cards. However, it seems that
even native PCI cards (like the D-Link 520) show a similar slow speed.

How bad is it? Well, I've just put my PCI analyser in the system - it 
shows (on the D-Link card + using
the latest linux-wlan-ng drivers) that it takes 23 PCI cycles for a write 
to the card to occur. A single write
is 16 bits. What is worse is that the turnaround time (i.e. time from 
start of one write to the start of the next) is 70
PCI cycles. This means that the absolute maximum bitrate achievable 
(between the CPU & the card) is:

        bitrate = (16/70)*33000000 = 7500000

What is more the processor may actually be busy just waiting for each of 
these accesses for a lot of this
time, and since this is dependent on PCI clock speed not CPU speed it 
doen't matter how fast your
processor is, your still going to see a hit.

Then on top of this is that if the processor is quite busy then we can't 
even guarantee the 7.2 mbps, we get
something lower. On the input side, I believe, this can occasionally lead 
to dropping some packets that
actually make it across the air OK, but overrun the input buffer of the 
MAC.

So my questions are:

- Does the Prism 2.5 chipset support a better (ideally DMA) mechanism of 
getting data in and out of the IC?
- Has any one started to look into this? If not, where could I get the 
best information to start to put some effort
into it?

Thanks,

Richard

Richard Miller-Smith
Project Leader, Interactive Systems Group
Philips Research Laboratories, Redhill
--=_alternative 0033EAAD80256B91_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">I'm currently looking around for the best 802.11b silicon to use in a prototype system. However, I'm finding</font>
<br><font size=2 face="sans-serif">that nearly all currently available silicon is let down due to the interface between the host CPU and</font>
<br><font size=2 face="sans-serif">the MAC. At first I put this down to most of the cards I tried being PCMCIA cards. However, it seems that</font>
<br><font size=2 face="sans-serif">even native PCI cards (like the D-Link 520) show a similar slow speed.</font>
<br>
<br><font size=2 face="sans-serif">How bad is it? Well, I've just put my PCI analyser in the system - it shows (on the D-Link card + using</font>
<br><font size=2 face="sans-serif">the latest linux-wlan-ng drivers) that it takes 23 PCI cycles for a write to the card to occur. A single write</font>
<br><font size=2 face="sans-serif">is 16 bits. What is worse is that the turnaround time (i.e. time from start of one write to the start of the next) is 70</font>
<br><font size=2 face="sans-serif">PCI cycles. This means that the absolute maximum bitrate achievable (between the CPU &amp; the card) is:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; bitrate = (16/70)*33000000 = 7500000</font>
<br>
<br><font size=2 face="sans-serif">What is more the processor may actually be busy just waiting for each of these accesses for a lot of this</font>
<br><font size=2 face="sans-serif">time, and since this is dependent on PCI clock speed not CPU speed it doen't matter how fast your</font>
<br><font size=2 face="sans-serif">processor is, your still going to see a hit.</font>
<br>
<br><font size=2 face="sans-serif">Then on top of this is that if the processor is quite busy then we can't even guarantee the 7.2 mbps, we get</font>
<br><font size=2 face="sans-serif">something lower. On the input side, I believe, this can occasionally lead to dropping some packets that</font>
<br><font size=2 face="sans-serif">actually make it across the air OK, but overrun the input buffer of the MAC.</font>
<br>
<br><font size=2 face="sans-serif">So my questions are:</font>
<br>
<br><font size=2 face="sans-serif">- Does the Prism 2.5 chipset support a better (ideally DMA) mechanism of getting data in and out of the IC?</font>
<br><font size=2 face="sans-serif">- Has any one started to look into this? If not, where could I get the best information to start to put some effort</font>
<br><font size=2 face="sans-serif">into it?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Richard<br>
<br>
Richard Miller-Smith<br>
Project Leader, Interactive Systems Group<br>
Philips Research Laboratories, Redhill</font>
--=_alternative 0033EAAD80256B91_=--