Throughput is not changed when setting to a much higher bit rate

Throughput is not changed when setting to a much higher bit rate

[Dongas]

Hi ALL,

I'm doing the performance profiling of our WiFi module with iperf.
The module is based on Marvell 8686 chipset with Libertas driver.

A strange issue i encounterred is that even i changed to a higher bit
rate ,the result of iperf seems that the bandwidth/troughput is still
not changed.

Details are as follows:
1. First test with default Bit Rate -1Mb/s
# iwconfig
eth1      IEEE 802.11b/g  ESSID:"dlink"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:24:01:25:18:8A
          Bit Rate:1 Mb/s   Tx-Power=13 dBm
          Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Power Management:off
          Link Quality=100/100  Signal level=-22 dBm  Noise level=-93 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:125310
          Tx excessive retries:1120  Invalid misc:2988   Missed beacon:0
#

# iperf -c 172.31.42.51 -i 5 -t 60
------------------------------------------------------------
Client connecting to 172.31.42.51, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 172.31.42.218 port 33228 connected with 172.31.42.51 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec    792 KBytes  1.30 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  5.0-10.0 sec    680 KBytes  1.11 Mbits/sec
……

The bandwidth tested out with iperf is around 1.1Mb/s.

2.  Change to a higner Bit Rate (11Mb/s) and re-test
# iwconfig eth1 rate 11M fixed
# iwconfig
eth1      IEEE 802.11b/g  ESSID:"dlink"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:24:01:25:18:8A
          Bit Rate=11 Mb/s   Tx-Power=13 dBm
          Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Power Management:off
          Link Quality=100/100  Signal level=-22 dBm  Noise level=-94 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:125610
          Tx excessive retries:1120  Invalid misc:2988   Missed beacon:0

# iperf -c 172.31.42.51 -i 5 -t 60
------------------------------------------------------------
Client connecting to 172.31.42.51, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 172.31.42.218 port 33229 connected with 172.31.42.51 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec    776 KBytes  1.27 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  5.0-10.0 sec    720 KBytes  1.18 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 10.0-15.0 sec    680 KBytes  1.11 Mbits/sec

The bandwidth tested out with iperf is still around 1.1Mb/s.

Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
Any thing wrong?

Thanks

Regards
Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[John W. Linville]

On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:

> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
> Any thing wrong?

More errors at higher bit rate, resulting in more retries?  Just a
thought...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Throughput is not changed when setting to a much higher bit rate

[Dongas]

2009/5/20 John W. Linville <linville@tuxdriver.com>:
> On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>
>> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>> Any thing wrong?
>
> More errors at higher bit rate, resulting in more retries?  Just a
> thought...
>
Is there a quick way to verify this possible reason? I'm using Libertas driver.

BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
Could this be the cause of such poor performance?
(However I just can't believe the performance is so poor ,only around
1.1Mbps, with polling mode of SDIO IRQ)

Thanks a lot for the reply.

Regards
Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[Dan Williams]

On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
> >
> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
> >> Any thing wrong?
> >
> > More errors at higher bit rate, resulting in more retries?  Just a
> > thought...
> >
> Is there a quick way to verify this possible reason? I'm using Libertas driver.
> 
> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
> Could this be the cause of such poor performance?

Definitely.  With libertas, the largest class of issues by *far* that
we've seen are controller related.  I seem to recall that I've pulled
about 6Mbps through the card using a normal Ricoh controller from a
Fujitsu laptop.  I can recheck that.

> (However I just can't believe the performance is so poor ,only around
> 1.1Mbps, with polling mode of SDIO IRQ)

What specific kernel version are you using?  There have been some
latency fixes in recent kernels, but would be good to know just to make
sure.

Dan


> Thanks a lot for the reply.
> 
> Regards
> Dongas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Throughput is not changed when setting to a much higher bit rate

[Dongas]

2009/5/21 Dan Williams <dcbw@redhat.com>:
> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>> >
>> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>> >> Any thing wrong?
>> >
>> > More errors at higher bit rate, resulting in more retries?  Just a
>> > thought...
>> >
>> Is there a quick way to verify this possible reason? I'm using Libertas driver.
>>
>> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>> Could this be the cause of such poor performance?
>
> Definitely.  With libertas, the largest class of issues by *far* that
> we've seen are controller related.  I seem to recall that I've pulled
> about 6Mbps through the card using a normal Ricoh controller from a
> Fujitsu laptop.  I can recheck that.

AFAIK, most old laptop ,including my x61, doesn't support SDIO in HW.
So did Ricoh controller you tested use polling mode to handle SDIO IRQ?
Which clock of controller and which bit rate did you test?

>> (However I just can't believe the performance is so poor ,only around
>> 1.1Mbps, with polling mode of SDIO IRQ)
>
> What specific kernel version are you using?  There have been some
> latency fixes in recent kernels, but would be good to know just to make
> sure.

I'm using kenrel 2.6.25.

Thanks

Regards
Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[Andrey Yurovsky]

On Wed, May 20, 2009 at 5:00 PM, Dongas <dongas86@gmail.com> wrote:
> 2009/5/21 Dan Williams <dcbw@redhat.com>:
>> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>>> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>>> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>>> >
>>> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>>> >> Any thing wrong?
>>> >
>>> > More errors at higher bit rate, resulting in more retries?  Just a
>>> > thought...
>>> >
>>> Is there a quick way to verify this possible reason? I'm using Libertas driver.
>>>
>>> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>>> Could this be the cause of such poor performance?
>>
>> Definitely.  With libertas, the largest class of issues by *far* that
>> we've seen are controller related.  I seem to recall that I've pulled
>> about 6Mbps through the card using a normal Ricoh controller from a
>> Fujitsu laptop.  I can recheck that.

For what it's worth, we've seen higher throughput: 20Mbps UDP and
14.7Mbps TCP using SDIO on a ThinkPad with the Ricoh controller.

  -Andrey

Re: Throughput is not changed when setting to a much higher bit rate

[Dan Williams]

On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
> 2009/5/21 Dan Williams <dcbw@redhat.com>:
> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
> >> >
> >> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
> >> >> Any thing wrong?
> >> >
> >> > More errors at higher bit rate, resulting in more retries?  Just a
> >> > thought...
> >> >
> >> Is there a quick way to verify this possible reason? I'm using Libertas driver.
> >>
> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
> >> Could this be the cause of such poor performance?
> >
> > Definitely.  With libertas, the largest class of issues by *far* that
> > we've seen are controller related.  I seem to recall that I've pulled
> > about 6Mbps through the card using a normal Ricoh controller from a
> > Fujitsu laptop.  I can recheck that.
> 
> AFAIK, most old laptop ,including my x61, doesn't support SDIO in HW.
> So did Ricoh controller you tested use polling mode to handle SDIO IRQ?
> Which clock of controller and which bit rate did you test?

Actually, most of the older machines *can* do SDIO, those made from
about 2006 - 2009.  These days a lot of the SD "controllers" are
actually USB-based mass-storage converters and cannot do SDIO, they are
essentially 10-in-1 cardreaders.

What is the 'lspci' output for your Thinkpad?  If the controller isn't
in 'lspci' but is in 'lsusb', then it's quite unlikely to work because
of the above reason, I think.

Dan

> >> (However I just can't believe the performance is so poor ,only around
> >> 1.1Mbps, with polling mode of SDIO IRQ)
> >
> > What specific kernel version are you using?  There have been some
> > latency fixes in recent kernels, but would be good to know just to make
> > sure.
> 
> I'm using kenrel 2.6.25.
> 
> Thanks
> 
> Regards
> Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[Andrey Yurovsky]

On Thu, May 21, 2009 at 3:38 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
>> 2009/5/21 Dan Williams <dcbw@redhat.com>:
>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>> >> >
>> >> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>> >> >> Any thing wrong?
>> >> >
>> >> > More errors at higher bit rate, resulting in more retries?  Just a
>> >> > thought...
>> >> >
>> >> Is there a quick way to verify this possible reason? I'm using Libertas driver.
>> >>
>> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>> >> Could this be the cause of such poor performance?
>> >
>> > Definitely.  With libertas, the largest class of issues by *far* that
>> > we've seen are controller related.  I seem to recall that I've pulled
>> > about 6Mbps through the card using a normal Ricoh controller from a
>> > Fujitsu laptop.  I can recheck that.
>>
>> AFAIK, most old laptop ,including my x61, doesn't support SDIO in HW.
>> So did Ricoh controller you tested use polling mode to handle SDIO IRQ?
>> Which clock of controller and which bit rate did you test?
>
> Actually, most of the older machines *can* do SDIO, those made from
> about 2006 - 2009.  These days a lot of the SD "controllers" are
> actually USB-based mass-storage converters and cannot do SDIO, they are
> essentially 10-in-1 cardreaders.
>
> What is the 'lspci' output for your Thinkpad?  If the controller isn't
> in 'lspci' but is in 'lsusb', then it's quite unlikely to work because
> of the above reason, I think.

Right, you need a real SDIO (vs. SD storage) controller on the PCI
bus.  However I can confirm that the ThinkPad X61 (and T61) controller
does full SDIO and you can plug Libertas SDIO cards into it.  The
older X-series ThinkPads (I tried the X40 and X41) work great too.

>> >> (However I just can't believe the performance is so poor ,only around
>> >> 1.1Mbps, with polling mode of SDIO IRQ)
>> >
>> > What specific kernel version are you using?  There have been some
>> > latency fixes in recent kernels, but would be good to know just to make
>> > sure.
>>
>> I'm using kenrel 2.6.25.
>>
>> Thanks
>>
>> Regards
>> Dongas
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Throughput is not changed when setting to a much higher bit rate

[Andrey Yurovsky]

On Thu, May 21, 2009 at 4:49 PM, benson.dong <benson.dong@infomax.com.tw> wrote:
> <20090519175336.GF2691@tuxdriver.com>
> <60ce8d250905200748p5984df0bl1984f0d3bdaf79b5@mail.gmail.com>
> <1242854588.7048.13.camel@localhost.localdomain>
> <60ce8d250905201700v13fe1394l6a9704bb02be3807@mail.gmail.com>
> <1242945500.6444.24.camel@localhost.localdomain> <45e8e6c40905211611q256a71f1pb08e2014f7ed0775@mail.gmail.com>
> Message-ID: <a12bc4a4a4cdf5f2ec75810d8e113d92@infomax.com.tw>
> X-Sender: benson.dong@infomax.com.tw
> Received: from 34.141.227.121.broad.sz.js.dynamic.163data.com.cn
>        [121.227.141.34] with HTTP/1.1 (POST); Fri, 22 May 2009 07:49:59
>        +0800
> User-Agent: INFOMAX Webmail/0.1
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
> On Thu, 21 May 2009 16:11:17 -0700, Andrey Yurovsky <andrey@cozybit.com>
> wrote:
>> On Thu, May 21, 2009 at 3:38 PM, Dan Williams <dcbw@redhat.com> wrote:
>>> On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
>>>> 2009/5/21 Dan Williams <dcbw@redhat.com>:
>>>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>>>> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>>>> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>>>> >> >
>>>> >> >> Why the bandwidth is not changed when bit rate is changed to
>> 11Mb/s?
>>>> >> >> Any thing wrong?
>>>> >> >
>>>> >> > More errors at higher bit rate, resulting in more retries?  Just
>> a
>>>> >> > thought...
>>>> >> >
>>>> >> Is there a quick way to verify this possible reason? I'm using
>> Libertas driver.
>>>> >>
>>>> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>>>> >> Could this be the cause of such poor performance?
>>>> >
>>>> > Definitely.  With libertas, the largest class of issues by *far*
>> that
>>>> > we've seen are controller related.  I seem to recall that I've
>> pulled
>>>> > about 6Mbps through the card using a normal Ricoh controller from a
>>>> > Fujitsu laptop.  I can recheck that.
>>>>
>>>> AFAIK, most old laptop ,including my x61, doesn't support SDIO in HW.
>>>> So did Ricoh controller you tested use polling mode to handle SDIO IRQ?
>>>> Which clock of controller and which bit rate did you test?
>>>
>>> Actually, most of the older machines *can* do SDIO, those made from
>>> about 2006 - 2009.  These days a lot of the SD "controllers" are
>>> actually USB-based mass-storage converters and cannot do SDIO, they are
>>> essentially 10-in-1 cardreaders.
>>>
>>> What is the 'lspci' output for your Thinkpad?  If the controller isn't
>>> in 'lspci' but is in 'lsusb', then it's quite unlikely to work because
>>> of the above reason, I think.
>>
>> Right, you need a real SDIO (vs. SD storage) controller on the PCI
>> bus.  However I can confirm that the ThinkPad X61 (and T61) controller
>> does full SDIO and you can plug Libertas SDIO cards into it.  The
>> older X-series ThinkPads (I tried the X40 and X41) work great too.
>
> Great, since the os running on x61 is windows vista, i just run linux in
> vmware.
> So do you know whether the windows driver for x61 supports full SDIO
> well(including SDIO interrupt in HW)?

Oh.  Well, you need to run Linux right on the hardware (ie: not in
VMWare or any visualization software) for SDIO to work.  I don't know
anything about Windows.  I can confirm, from personal experience, that
the X61's SDIO works fine for Libertas in Linux.

>>>> >> (However I just can't believe the performance is so poor ,only
>> around
>>>> >> 1.1Mbps, with polling mode of SDIO IRQ)
>>>> >
>>>> > What specific kernel version are you using?  There have been some
>>>> > latency fixes in recent kernels, but would be good to know just to
>> make
>>>> > sure.
>>>>
>>>> I'm using kenrel 2.6.25.
>>>>
>>>> Thanks
>>>>
>>>> Regards
>>>> Dongas
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>

Re: Throughput is not changed when setting to a much higher bit rate

[Dongas]

2009/5/22 Andrey Yurovsky <andrey@cozybit.com>:
>> On Thu, 21 May 2009 16:11:17 -0700, Andrey Yurovsky <andrey@cozybit.com>
>> wrote:
>>> On Thu, May 21, 2009 at 3:38 PM, Dan Williams <dcbw@redhat.com> wrote:
>>>> On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
>>>>> 2009/5/21 Dan Williams <dcbw@redhat.com>:
>>>>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>>>>> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>>>>> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>>>>> >> >
>>>>> >> >> Why the bandwidth is not changed when bit rate is changed to
>>> 11Mb/s?
>>>>> >> >> Any thing wrong?
>>>>> >> >
>>>>> >> > More errors at higher bit rate, resulting in more retries?  Just
>>> a
>>>>> >> > thought...
>>>>> >> >
>>>>> >> Is there a quick way to verify this possible reason? I'm using
>>> Libertas driver.
>>>>> >>
>>>>> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>>>>> >> Could this be the cause of such poor performance?
>>>>> >
>>>>> > Definitely.  With libertas, the largest class of issues by *far*
>>> that
>>>>> > we've seen are controller related.  I seem to recall that I've
>>> pulled
>>>>> > about 6Mbps through the card using a normal Ricoh controller from a
>>>>> > Fujitsu laptop.  I can recheck that.
>>>>>
>>>>> AFAIK, most old laptop ,including my x61, doesn't support SDIO in HW.
>>>>> So did Ricoh controller you tested use polling mode to handle SDIO IRQ?
>>>>> Which clock of controller and which bit rate did you test?
>>>>
>>>> Actually, most of the older machines *can* do SDIO, those made from
>>>> about 2006 - 2009.  These days a lot of the SD "controllers" are
>>>> actually USB-based mass-storage converters and cannot do SDIO, they are
>>>> essentially 10-in-1 cardreaders.
>>>>
>>>> What is the 'lspci' output for your Thinkpad?  If the controller isn't
>>>> in 'lspci' but is in 'lsusb', then it's quite unlikely to work because
>>>> of the above reason, I think.
>>>
>>> Right, you need a real SDIO (vs. SD storage) controller on the PCI
>>> bus.  However I can confirm that the ThinkPad X61 (and T61) controller
>>> does full SDIO and you can plug Libertas SDIO cards into it.  The
>>> older X-series ThinkPads (I tried the X40 and X41) work great too.
>>
>> Great, since the os running on x61 is windows vista, i just run linux in
>> vmware.
>> So do you know whether the windows driver for x61 supports full SDIO
>> well(including SDIO interrupt in HW)?
>
> Oh.  Well, you need to run Linux right on the hardware (ie: not in
> VMWare or any visualization software) for SDIO to work.  I don't know
> anything about Windows.  I can confirm, from personal experience, that
> the X61's SDIO works fine for Libertas in Linux.

OK.Thanks for your info.
BTW, do you know whether the X61's SD/SDIO controller supports SDIO IRQ in HW?
Or it just works on polling mode for SDIO IRQ?

Regards
Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[Dongas]

2009/5/21 Dan Williams <dcbw@redhat.com>:
> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>> >
>> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>> >> Any thing wrong?
>> >
>> > More errors at higher bit rate, resulting in more retries?  Just a
>> > thought...
>> >
>> Is there a quick way to verify this possible reason? I'm using Libertas driver.
>>
>> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>> Could this be the cause of such poor performance?
>
> Definitely.  With libertas, the largest class of issues by *far* that
> we've seen are controller related.  I seem to recall that I've pulled
> about 6Mbps through the card using a normal Ricoh controller from a
> Fujitsu laptop.  I can recheck that.
>

Thanks for your info,Dan.
For Libertas driver , do you know which reason would be the cause of
the issue i encounterred?
Basically if i set the bit rate of Marvell card to a much higher value
such as 11Mb/s or even 48Mb/s, the HW should be capable of
transferring in hign bit rate.
However , the result from iperf indicates that the real bandwidth is
remain around 1.1Mbps, even no improvement.
It seems Marvell 8686 WiFi module will adjust the bit rate according
to the real situation.
So the bottleneck would be host side , HW or driver, right?
If there a way for me to debug this issue in libertas driver to find
out the root reason?
If the issue is related to our HW, we would like to take some
modifications on it.

>> (However I just can't believe the performance is so poor ,only around
>> 1.1Mbps, with polling mode of SDIO IRQ)
There must be something wrong.

Regards
Dongas

Re: Throughput is not changed when setting to a much higher bit rate

[Dan Williams]

On Fri, 2009-05-22 at 08:27 +0800, Dongas wrote:
> 2009/5/21 Dan Williams <dcbw@redhat.com>:
> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
> >> >
> >> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
> >> >> Any thing wrong?
> >> >
> >> > More errors at higher bit rate, resulting in more retries?  Just a
> >> > thought...
> >> >
> >> Is there a quick way to verify this possible reason? I'm using Libertas driver.
> >>
> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
> >> Could this be the cause of such poor performance?
> >
> > Definitely.  With libertas, the largest class of issues by *far* that
> > we've seen are controller related.  I seem to recall that I've pulled
> > about 6Mbps through the card using a normal Ricoh controller from a
> > Fujitsu laptop.  I can recheck that.
> >
> 
> Thanks for your info,Dan.
> For Libertas driver , do you know which reason would be the cause of
> the issue i encounterred?
> Basically if i set the bit rate of Marvell card to a much higher value
> such as 11Mb/s or even 48Mb/s, the HW should be capable of
> transferring in hign bit rate.
> However , the result from iperf indicates that the real bandwidth is
> remain around 1.1Mbps, even no improvement.
> It seems Marvell 8686 WiFi module will adjust the bit rate according
> to the real situation.
> So the bottleneck would be host side , HW or driver, right?
> If there a way for me to debug this issue in libertas driver to find
> out the root reason?
> If the issue is related to our HW, we would like to take some
> modifications on it.

Tests with my *unshielded* 8686 dev module with 15 other APs in the
area, running v9 firmware from the linux-firmware git tree, pulling a
240123904 byte file off a host connected via ethernet to a Netgear
WGR614 802.11g router using WPA-PSK:

HP EliteBook 2530p  (1.40 MB/s)
------------------------------
Core 2 Duo LV 1.86GHz
2.6.29.3-140.fc11.x86_64
Ricoh R5C822 (rev 22)

Fujitsu Lifebook P7230  (1015 KB/s)
------------------------------
Core Duo LV 1.2GHz
2.6.29.2-126.fc11.i586
Ricoh R5C822 (rev 17)

Fujitsu LifeBook P1510  (1.26 MB/s)
------------------------------
Pentium M 1.2GHz
2.6.27.15-170.2.24.fc10.i686
Ricoh R5C822 (rev 13)


So that's up to 11Mbps (bursting to 12.5 Mbps) on the Ricoh controller,
which is a pretty sane, standard SDIO controller on many laptops.
Unfortunately, all I have to test with are Ricoh controllers...

In the past, most of the issues we've had are due to the host controller
used, not really the libertas driver or the chip itself.  Yes, there are
deficiencies in the driver, but apparently speed isn't one of them when
it's used in combination with a Ricoh controller on a laptop.  There
were some questions earlier about speed with embedded controllers being
correlated to HZ somehow, but I think we took care of that with
9b02f419a7dbd956b2c293e5cb1790b6b687f367 in February.

Dan

Re: Throughput is not changed when setting to a much higher bit rate

[Dongas]

2009/5/22 Dan Williams <dcbw@redhat.com>:
> On Fri, 2009-05-22 at 08:27 +0800, Dongas wrote:
>> 2009/5/21 Dan Williams <dcbw@redhat.com>:
>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> >> 2009/5/20 John W. Linville <linville@tuxdriver.com>:
>> >> > On Wed, May 20, 2009 at 01:48:32AM +0800, Dongas wrote:
>> >> >
>> >> >> Why the bandwidth is not changed when bit rate is changed to 11Mb/s?
>> >> >> Any thing wrong?
>> >> >
>> >> > More errors at higher bit rate, resulting in more retries?  Just a
>> >> > thought...
>> >> >
>> >> Is there a quick way to verify this possible reason? I'm using Libertas driver.
>> >>
>> >> BTW, my sdio host driver is using polling mode to handle SDIO IRQ.
>> >> Could this be the cause of such poor performance?
>> >
>> > Definitely.  With libertas, the largest class of issues by *far* that
>> > we've seen are controller related.  I seem to recall that I've pulled
>> > about 6Mbps through the card using a normal Ricoh controller from a
>> > Fujitsu laptop.  I can recheck that.
>> >
>>
>> Thanks for your info,Dan.
>> For Libertas driver , do you know which reason would be the cause of
>> the issue i encounterred?
>> Basically if i set the bit rate of Marvell card to a much higher value
>> such as 11Mb/s or even 48Mb/s, the HW should be capable of
>> transferring in hign bit rate.
>> However , the result from iperf indicates that the real bandwidth is
>> remain around 1.1Mbps, even no improvement.
>> It seems Marvell 8686 WiFi module will adjust the bit rate according
>> to the real situation.
>> So the bottleneck would be host side , HW or driver, right?
>> If there a way for me to debug this issue in libertas driver to find
>> out the root reason?
>> If the issue is related to our HW, we would like to take some
>> modifications on it.
>
> Tests with my *unshielded* 8686 dev module with 15 other APs in the
> area, running v9 firmware from the linux-firmware git tree, pulling a
> 240123904 byte file off a host connected via ethernet to a Netgear
> WGR614 802.11g router using WPA-PSK:
>
> HP EliteBook 2530p  (1.40 MB/s)
> ------------------------------
> Core 2 Duo LV 1.86GHz
> 2.6.29.3-140.fc11.x86_64
> Ricoh R5C822 (rev 22)
>
> Fujitsu Lifebook P7230  (1015 KB/s)
> ------------------------------
> Core Duo LV 1.2GHz
> 2.6.29.2-126.fc11.i586
> Ricoh R5C822 (rev 17)
>
> Fujitsu LifeBook P1510  (1.26 MB/s)
> ------------------------------
> Pentium M 1.2GHz
> 2.6.27.15-170.2.24.fc10.i686
> Ricoh R5C822 (rev 13)
>
>
> So that's up to 11Mbps (bursting to 12.5 Mbps) on the Ricoh controller,
> which is a pretty sane, standard SDIO controller on many laptops.
> Unfortunately, all I have to test with are Ricoh controllers...

Thanks for the info you provided , Ricoh controller seems work well
with Libertas.

I think the throughput should be related to the running bit rate of wifi card,
from the command "iwlist eth0 rate", i can see the maximum supported
bit rate of my card is 54Mb/s.However, its default bit rate when
associating with a AP is alway 1Mb/s which seems a little
strange.Thus, i'd like to know how does libertas driver select the
default bit rate for Marvell 8686 card when it associates with a AP?

> In the past, most of the issues we've had are due to the host controller
> used, not really the libertas driver or the chip itself.  Yes, there are
> deficiencies in the driver, but apparently speed isn't one of them when
> it's used in combination with a Ricoh controller on a laptop.  There
> were some questions earlier about speed with embedded controllers being
> correlated to HZ somehow, but I think we took care of that with
> 9b02f419a7dbd956b2c293e5cb1790b6b687f367 in February.
>
I believe the issue may lies on our host side ,either HW or driver and
i'm going to find it out.
Since my host driver is using polling mode to handle SDIO IRQ and the
performance of the adaptive SDIO IRQ polling algorism of Linux SDIO
Stack is related with HZ and high resolution timer, i'm going to check
if our GPTimer driver in kernel supports HRTimer well.

Thanks

Regards
Dongas