Unusually low speeds with ath5k and iwl3945
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
Quoted 3 lines · Maxim Levitsky
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?
Signature · 1 line
Bob Copeland %% 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.
Quoted 9 lines · Bob Copeland
Quoted 3 lines · Maxim Levitsky
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?
Signature · 5 lines
Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [email protected] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
Quoted 4 lines · Derek Smithies
Hi,
to verify that it is a rate control issue, there is one very simple and
very practical test.
Quoted 14 lines
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.
Quoted 7 lines · Bob Copeland
Quoted 3 lines · Maxim Levitsky
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 =E9crit :
Quoted 3 lines
Quoted 2 lines · Derek Smithies
Hi,
to verify that it is a rate control issue, there is one very simple=
and=20
Quoted 3 lines
Quoted 3 lines
very practical test.
Take both ends of your link, and set them to fixed rate, and at the =
rate=20
Quoted 2 lines
Quoted 2 lines
you think it should be achieving.
If you can achieve significantly higher throughputs with fixed rate,=
you=20
Quoted 1 line
Quoted 1 line
know that the rate control algorithm (or interface with rate algorit=
hm)=20
Quoted 8 lines
Quoted 8 lines
has failed.
Derek.
Quoted 2 lines · Bob Copeland
Quoted 1 line · Maxim Levitsky
I initially blamed iwl3945, then thought it got fixed, but now I h=
ave
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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,
=20
Well, iwl3945 was showing 54M all the time in iwconfig, also it doesn't support setting fixed rate, at least not using iwconf=
ig.
Quoted 2 lines
=20
ath5k never shows higher that 18M, and supports setting fixed rate, b=
ut if I set it to anything higher that 18M,
Quoted 3 lines
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.
Quoted 7 lines
=20
iwl3945 was always at 54M
=20
=20
=20
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 th= e
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=EEt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJKlkTOR6EySwP7oIRAnR1AJ0UCiENM0qtZwQYngkVpiLvrKtgLACfRKPz Wi/HreSX4NV+kfyeS+RMFaY=3D
=3DRKcV
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 14 lines · Benoit PAPILLAULT
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....
Quoted 7 lines
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 preambleI 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
Quoted 34 lines · Felix Fietkau
Quoted 14 lines · Benoit PAPILLAULT
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....
Quoted 7 lines
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 preambleI 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.
Quoted 2 lines
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
=46elix Fietkau a =E9crit :
Quoted 3 lines
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 causin=
g
Quoted 1 line
issues like this. I've seen similar behaviour a long time ago when te=
sting
Quoted 1 line
iwl3945 against a Broadcom AP with exactly the same throughput drop (=
500-
Quoted 2 lines
600 kbits/s).
When I analyzed the problem with an extra monitor mode card, I found =
out
Quoted 1 line
that the throughput drop is caused by a huge number of retransmission=
s,
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?
Quoted 1 line
and if I remember correctly (I didn't look for this specifically back=
then),
Quoted 1 line
the retransmissions went down the rate scaling table until they hit t=
he
Quoted 3 lines
first non-ERP rate and that one worked on the first try. =20
Johannes, does that sound like a probable cause? If so, it should be =
easy
Quoted 4 lines
to fix.
=20
- Felix
=20
Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJLFX8OR6EySwP7oIRAp2pAJ0batdz64sh9L82CIKzkmVcLyANygCeOq5q D18DQ/Ko9ggdGn5lmshlMJs=3D
=3D3efH
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Benoit PAPILLAULT
Felix Fietkau a =E9crit :
Quoted 3 lines
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 causi=
ng
Quoted 1 line
Quoted 1 line
issues like this. I've seen similar behaviour a long time ago when t=
esting
Quoted 1 line
Quoted 1 line
iwl3945 against a Broadcom AP with exactly the same throughput drop =
(500-
Quoted 2 lines
Quoted 2 lines
600 kbits/s).
When I analyzed the problem with an extra monitor mode card, I found=
out
Quoted 1 line
Quoted 1 line
that the throughput drop is caused by a huge number of retransmissio=
ns,
Quoted 3 lines
=20
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).
Quoted 1 line
What is the code computing frame duration you are referring to? How i=
t
Quoted 1 line
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
MjAwOC8xMS8yMSBNYXhpbSBMZXZpdHNreSA8bWF4aW1sZXZpdHNreUBnbWFpbC5jb20+Ogo+IHNv cnJ5IGZvciBjcm9zcy1wb3N0aW5nLCBidXQgdGhpcyBpc3N1ZSByZWFsbHkgc3BhbnMgYm90aCBp d2wzOTQ1IGFuZCBhdGg1ay4KCkkndmUgbm8gaWRlYSBpZiB0aGlzIGNhbiBiZSByZWxhdGVkLCBi dXQgcmVjZW50bHkgdGhlcmUgd2FzIHNvbWUKcmVwb3J0IGFib3V0IGF0aDVrICYmIGI0My4gTWF5 YmUgaXQncyBzb21lIGJ1ZyBpbiBhdGg1az8KCmh0dHBzOi8vbGlzdHMuYmVybGlvcy5kZS9waXBl cm1haWwvYmNtNDN4eC1kZXYvMjAwOC1Ob3ZlbWJlci8wMDgzMTUuaHRtbAoKLS0gClJhZmHFgiBN acWCZWNraQo=
Quoted 6 lines · Maxim Levitsky
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
Quoted 9 lines · reinette chatre
Quoted 6 lines · Maxim Levitsky
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.
Quoted 8 lines
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
Quoted 13 lines · Maxim Levitsky
Quoted 12 lines · reinette chatre
Quoted 6 lines · Maxim Levitsky
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 ?
Quoted 8 lines
Quoted 5 lines
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