Hi,
sorry for cross-posting, but this issue really spans both iwl3945 and ath5k.
I have two laptops (acer 5720, and aspire one) and I see some strange speed issues.
I initially blamed iwl3945, then thought it got fixed, but now I have ath5k, and speeds are low
and I suspect that both drivers has bugs regarding to speed.
Walter Francis, once reported similar issue, so I cc'ed him too.
He says that 2.6.25 works fine for iwl3945.
I'll test this, and bisect if necessary.
So here it goes:
System setup:
a wired desktop connected to a router, I call it just router
as wired connection there is 100 Mbits/s and this can't
be the bottleneck.
two laptops, both are close to the router, signal strength is -50 dBm on laptop
and -55 dBm on aspire one (they are really close, they are on same desktop).
Also I did try to bring both laptops to router, and this really didn't help much.
Only one of laptops was on when I did speed tests between a laptop and router.
I did those tests several times, and interleaved them in different order.
For data transfers, contents of /dev/zero were send to /dev/null via TCP connection,
using netcat.
So here are the speeds:
router->iwl3945 = 2.3 Mbytes/s, solid speed, never dropped much, was consistent across tests.
iwl3945->router = 1.0 Mbytes/s max, on first test, it dropped often to 300 Kbytes/s
Then in another test for whole session it stayed at 200 Kbytes/s, it was same upload speed
to ath5k too, the speed varied a lot too.
router->ath5k = 1.4 Mbytes/s max, was pretty solid, also noticed that
iwconfig shows maximum 18M, although my router supports all B/G speeds.
attempts to set higher speed resulted in full connection loss.
also association was dropping often, and that resulted in few minutes of no transfer
at all.
ath5k->router = 1.4 Mbytes/s max, also the same 18 Mbytes/s issue ,
and same association issue.
And now for the worst part:
ath5k->iwl3945 = 800 Kbytes/s, but speed very often dropped to 600 Kbytes/s, and once it did drop to around 80~100 Kbytes/s
I did see same association drops, but they were rare.
iwl3945->ath5k = 500 Kbytes/s and often drops to 300 Mbytes/s.
Best regards,
Maxim Levitsky
On Fri, Nov 21, 2008 at 10:28:29PM +0200, Maxim Levitsky wrote:
> I initially blamed iwl3945, then thought it got fixed, but now I have
> ath5k, and speeds are low
> and I suspect that both drivers has bugs regarding to speed.
Quite possible, but both use mac80211 for rate control. Which rate
control algorithm are you using?
--
Bob Copeland %% http://www.bobcopeland.com
Hi,
to verify that it is a rate control issue, there is one very simple and
very practical test.
Take both ends of your link, and set them to fixed rate, and at the rate
you think it should be achieving.
If you can achieve significantly higher throughputs with fixed rate, you
know that the rate control algorithm (or interface with rate algorithm)
has failed.
Derek.
On Fri, 21 Nov 2008, Bob Copeland wrote:
> On Fri, Nov 21, 2008 at 10:28:29PM +0200, Maxim Levitsky wrote:
>> I initially blamed iwl3945, then thought it got fixed, but now I have
>> ath5k, and speeds are low
>> and I suspect that both drivers has bugs regarding to speed.
>
> Quite possible, but both use mac80211 for rate control. Which rate
> control algorithm are you using?
>
>
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: [email protected]
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
2008/11/21 Maxim Levitsky <[email protected]>:> sorry for cross-posting, but this issue really spans both iwl3945 and ath5k.
I've no idea if this can be related, but recently there was somereport about ath5k && b43. Maybe it's some bug in ath5k?
https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/008315.html
-- Rafał Miłecki????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Derek Smithies wrote:
> Hi,
> to verify that it is a rate control issue, there is one very simple and
> very practical test.
>
> Take both ends of your link, and set them to fixed rate, and at the rate
> you think it should be achieving.
> If you can achieve significantly higher throughputs with fixed rate, you
> know that the rate control algorithm (or interface with rate algorithm)
> has failed.
>
> Derek.
>
> On Fri, 21 Nov 2008, Bob Copeland wrote:
>
>> On Fri, Nov 21, 2008 at 10:28:29PM +0200, Maxim Levitsky wrote:
>>> I initially blamed iwl3945, then thought it got fixed, but now I have
>>> ath5k, and speeds are low
>>> and I suspect that both drivers has bugs regarding to speed.
>>
>> Quite possible, but both use mac80211 for rate control. Which rate
>> control algorithm are you using?
Hi,
Well, iwl3945 was showing 54M all the time in iwconfig,
also it doesn't support setting fixed rate, at least not using iwconfig.
ath5k never shows higher that 18M, and supports setting fixed rate, but if I set it to anything higher that 18M,
speeds drop to 0Kbytes/s immediately.
Speeds lower that 18M work, and affect throughput accordantly
For most of tests speeds are ether 18M or lower, but then when I set them to 18M this didn't increase throughput.
iwl3945 was always at 54M
Best regards,
Maxim Levitsky
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maxim Levitsky a ?crit :
> Derek Smithies wrote:
>> Hi,
>> to verify that it is a rate control issue, there is one very simple and
>> very practical test.
>>
>> Take both ends of your link, and set them to fixed rate, and at the rate
>> you think it should be achieving.
>> If you can achieve significantly higher throughputs with fixed rate, you
>> know that the rate control algorithm (or interface with rate algorithm)
>> has failed.
>>
>> Derek.
>>
>> On Fri, 21 Nov 2008, Bob Copeland wrote:
>>
>>> On Fri, Nov 21, 2008 at 10:28:29PM +0200, Maxim Levitsky wrote:
>>>> I initially blamed iwl3945, then thought it got fixed, but now I have
>>>> ath5k, and speeds are low
>>>> and I suspect that both drivers has bugs regarding to speed.
>>> Quite possible, but both use mac80211 for rate control. Which rate
>>> control algorithm are you using?
> Hi,
>
> Well, iwl3945 was showing 54M all the time in iwconfig,
> also it doesn't support setting fixed rate, at least not using iwconfig.
>
> ath5k never shows higher that 18M, and supports setting fixed rate, but if I set it to anything higher that 18M,
> speeds drop to 0Kbytes/s immediately.
> Speeds lower that 18M work, and affect throughput accordantly
> For most of tests speeds are ether 18M or lower, but then when I set them to 18M this didn't increase throughput.
>
> iwl3945 was always at 54M
>
>
>
> Best regards,
> Maxim Levitsky
I did a similar test here and results is very strange. AP was my good
old linksys WRT54G running an iperf server. Client was a laptop running
either ath5k or madwifi/trunk and an iperf client. Channel is 5. Both
drivers show the same behaviour.
At the beginning, throughput was very low : 500 - 600 kbit/s. Suddenly
(after few minutes), it jumps to 15 - 17 Mbit/s and then few minutes
later (let's say 10 - 20 minutes maybe), it jumps back to 500 - 600
kbit/s. Using a fixed rate has no effect.
I used my latest wireless monitoring tools and I did not saw lost of
duplicates or lost packets. The only difference was the number of
packets sent by seconds....
Looking a my syslog, I just saw few messages, unrelated in time with the
throughput going up or down. They were:
- - ath5k : unsupported jumbo
- - switching to short barker preamble
- - switching to long barker preamble
I can repeat the same test with iwl3945 as well, if needed.
Regards,
Beno?t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJKlkTOR6EySwP7oIRAnR1AJ0UCiENM0qtZwQYngkVpiLvrKtgLACfRKPz
Wi/HreSX4NV+kfyeS+RMFaY=
=RKcV
-----END PGP SIGNATURE-----
Benoit PAPILLAULT wrote:
> I did a similar test here and results is very strange. AP was my good
> old linksys WRT54G running an iperf server. Client was a laptop running
> either ath5k or madwifi/trunk and an iperf client. Channel is 5. Both
> drivers show the same behaviour.
>
> At the beginning, throughput was very low : 500 - 600 kbit/s. Suddenly
> (after few minutes), it jumps to 15 - 17 Mbit/s and then few minutes
> later (let's say 10 - 20 minutes maybe), it jumps back to 500 - 600
> kbit/s. Using a fixed rate has no effect.
>
> I used my latest wireless monitoring tools and I did not saw lost of
> duplicates or lost packets. The only difference was the number of
> packets sent by seconds....
>
> Looking a my syslog, I just saw few messages, unrelated in time with the
> throughput going up or down. They were:
> - ath5k : unsupported jumbo
> - switching to short barker preamble
> - switching to long barker preamble
>
> I can repeat the same test with iwl3945 as well, if needed.
While reading the code for calculating the frame duration, i noticed
something odd: It doesn't seem to be taking into account the short
vs long preamble distinction for ERP rates. IMHO this might be causing
issues like this. I've seen similar behaviour a long time ago when testing
iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
600 kbits/s).
When I analyzed the problem with an extra monitor mode card, I found out
that the throughput drop is caused by a huge number of retransmissions,
and if I remember correctly (I didn't look for this specifically back then),
the retransmissions went down the rate scaling table until they hit the
first non-ERP rate and that one worked on the first try.
Johannes, does that sound like a probable cause? If so, it should be easy
to fix.
- Felix
On Mon, 2008-11-24 at 10:43 +0100, Felix Fietkau wrote:
> Benoit PAPILLAULT wrote:
> > I did a similar test here and results is very strange. AP was my good
> > old linksys WRT54G running an iperf server. Client was a laptop running
> > either ath5k or madwifi/trunk and an iperf client. Channel is 5. Both
> > drivers show the same behaviour.
> >
> > At the beginning, throughput was very low : 500 - 600 kbit/s. Suddenly
> > (after few minutes), it jumps to 15 - 17 Mbit/s and then few minutes
> > later (let's say 10 - 20 minutes maybe), it jumps back to 500 - 600
> > kbit/s. Using a fixed rate has no effect.
> >
> > I used my latest wireless monitoring tools and I did not saw lost of
> > duplicates or lost packets. The only difference was the number of
> > packets sent by seconds....
> >
> > Looking a my syslog, I just saw few messages, unrelated in time with the
> > throughput going up or down. They were:
> > - ath5k : unsupported jumbo
> > - switching to short barker preamble
> > - switching to long barker preamble
> >
> > I can repeat the same test with iwl3945 as well, if needed.
> While reading the code for calculating the frame duration, i noticed
> something odd: It doesn't seem to be taking into account the short
> vs long preamble distinction for ERP rates. IMHO this might be causing
> issues like this. I've seen similar behaviour a long time ago when testing
> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
> 600 kbits/s).
> When I analyzed the problem with an extra monitor mode card, I found out
> that the throughput drop is caused by a huge number of retransmissions,
> and if I remember correctly (I didn't look for this specifically back then),
> the retransmissions went down the rate scaling table until they hit the
> first non-ERP rate and that one worked on the first try.
>
> Johannes, does that sound like a probable cause? If so, it should be easy
> to fix.
I have no idea. Shouldn't that be easy to tell from the monitor? And if
the short/long switching was _unrelated_ in time it seems like it
wouldn't be a problem?
johannes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Felix Fietkau a ?crit :
> While reading the code for calculating the frame duration, i noticed
> something odd: It doesn't seem to be taking into account the short
> vs long preamble distinction for ERP rates. IMHO this might be causing
> issues like this. I've seen similar behaviour a long time ago when testing
> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
> 600 kbits/s).
> When I analyzed the problem with an extra monitor mode card, I found out
> that the throughput drop is caused by a huge number of retransmissions,
In the test I've done, there was no retransmission at all (no
duplicates). I don't save a capture file, so I cannot tell for sure.
What is the code computing frame duration you are referring to? How it
could affect the hardware behavior?
> and if I remember correctly (I didn't look for this specifically back then),
> the retransmissions went down the rate scaling table until they hit the
> first non-ERP rate and that one worked on the first try.
>
> Johannes, does that sound like a probable cause? If so, it should be easy
> to fix.
>
> - Felix
>
Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJLFX8OR6EySwP7oIRAp2pAJ0batdz64sh9L82CIKzkmVcLyANygCeOq5q
D18DQ/Ko9ggdGn5lmshlMJs=
=3efH
-----END PGP SIGNATURE-----
Benoit PAPILLAULT wrote:
> Felix Fietkau a ?crit :
>> While reading the code for calculating the frame duration, i noticed
>> something odd: It doesn't seem to be taking into account the short
>> vs long preamble distinction for ERP rates. IMHO this might be causing
>> issues like this. I've seen similar behaviour a long time ago when testing
>> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
>> 600 kbits/s).
>> When I analyzed the problem with an extra monitor mode card, I found out
>> that the throughput drop is caused by a huge number of retransmissions,
>
> In the test I've done, there was no retransmission at all (no
> duplicates). I don't save a capture file, so I cannot tell for sure.
Which test specifically? iwl3945 or ath5k?
If ath5k doesn't show any retransmissions, the problem might not be
related. Please do make some logs of the throughput issue and then
some more of the same kind of traffic without throughput issues
(same card, same driver).
> What is the code computing frame duration you are referring to? How it
> could affect the hardware behavior?
I looked at it again and now I don't think it's the cause anymore. I
did some comparisons against other stacks/drivers and this part
seems correct after all.
- Felix
On Fri, 2008-11-21 at 12:28 -0800, Maxim Levitsky wrote:
> sorry for cross-posting, but this issue really spans both iwl3945 and ath5k.
>
> I have two laptops (acer 5720, and aspire one) and I see some strange speed issues.
>
> I initially blamed iwl3945, then thought it got fixed, but now I have ath5k, and speeds are low
> and I suspect that both drivers has bugs regarding to speed.
We just posted some fixes to iwl3945 rate scaling. Could you please test
with http://marc.info/?l=linux-wireless&m=122824880823630&w=2 ?
Thank you
Reinette
On Wed, 2008-12-03 at 08:55 -0800, reinette chatre wrote:
> On Fri, 2008-11-21 at 12:28 -0800, Maxim Levitsky wrote:
>
> > sorry for cross-posting, but this issue really spans both iwl3945 and ath5k.
> >
> > I have two laptops (acer 5720, and aspire one) and I see some strange speed issues.
> >
> > I initially blamed iwl3945, then thought it got fixed, but now I have ath5k, and speeds are low
> > and I suspect that both drivers has bugs regarding to speed.
>
> We just posted some fixes to iwl3945 rate scaling. Could you please test
> with http://marc.info/?l=linux-wireless&m=122824880823630&w=2 ?
>
> Thank you
>
> Reinette
>
>
I''l test this, but for all my tests rate on iwl3945 was already 54M,
could this still help?
Best regards,
Maxim Levitsky
On Wed, 2008-12-03 at 09:09 -0800, Maxim Levitsky wrote:
> On Wed, 2008-12-03 at 08:55 -0800, reinette chatre wrote:
> > On Fri, 2008-11-21 at 12:28 -0800, Maxim Levitsky wrote:
> >
> > > sorry for cross-posting, but this issue really spans both iwl3945 and ath5k.
> > >
> > > I have two laptops (acer 5720, and aspire one) and I see some strange speed issues.
> > >
> > > I initially blamed iwl3945, then thought it got fixed, but now I have ath5k, and speeds are low
> > > and I suspect that both drivers has bugs regarding to speed.
> >
> > We just posted some fixes to iwl3945 rate scaling. Could you please test
> > with http://marc.info/?l=linux-wireless&m=122824880823630&w=2 ?
> >
> > Thank you
> >
> > Reinette
> >
> >
> I''l test this, but for all my tests rate on iwl3945 was already 54M,
> could this still help?
>
Yes. Please test with netcat as you did previously to see if you get
better performance.
Thanks
Reinette