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
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
[email protected] might be all we have. Be ready.
2009/5/21 Dan Williams <[email protected]>:
> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> 2009/5/20 John W. Linville <[email protected]>:
>> > 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
On Thu, May 21, 2009 at 3:38 PM, Dan Williams <[email protected]> wrote:
> On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
>> 2009/5/21 Dan Williams <[email protected]>:
>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> >> 2009/5/20 John W. Linville <[email protected]>:
>> >> > 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
2009/5/21 Dan Williams <[email protected]>:
> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> 2009/5/20 John W. Linville <[email protected]>:
>> > 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
On Thu, 2009-05-21 at 08:00 +0800, Dongas wrote:
> 2009/5/21 Dan Williams <[email protected]>:
> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> >> 2009/5/20 John W. Linville <[email protected]>:
> >> > 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
On Wed, May 20, 2009 at 5:00 PM, Dongas <[email protected]> wrote:
> 2009/5/21 Dan Williams <[email protected]>:
>> On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>>> 2009/5/20 John W. Linville <[email protected]>:
>>> > 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
On Fri, 2009-05-22 at 08:27 +0800, Dongas wrote:
> 2009/5/21 Dan Williams <[email protected]>:
> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> >> 2009/5/20 John W. Linville <[email protected]>:
> >> > 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
2009/5/20 John W. Linville <[email protected]>:
> 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
On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
> 2009/5/20 John W. Linville <[email protected]>:
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
2009/5/22 Dan Williams <[email protected]>:
> On Fri, 2009-05-22 at 08:27 +0800, Dongas wrote:
>> 2009/5/21 Dan Williams <[email protected]>:
>> > On Wed, 2009-05-20 at 22:48 +0800, Dongas wrote:
>> >> 2009/5/20 John W. Linville <[email protected]>:
>> >> > 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