diff for duplicates of <492C55FC.2040506@free.fr> diff --git a/a/1.txt b/N1/1.txt index 9221b14..513322f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,20 +1,15 @@ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 -=46elix Fietkau a =E9crit : +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 causin= -g -> issues like this. I've seen similar behaviour a long time ago when te= -sting -> iwl3945 against a Broadcom AP with exactly the same throughput drop (= -500- +> 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 retransmission= -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. @@ -22,18 +17,15 @@ 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 t= -he +> 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. ->=20 -> Johannes, does that sound like a probable cause? If so, it should be = -easy +> +> Johannes, does that sound like a probable cause? If so, it should be easy > to fix. ->=20 +> > - Felix ->=20 +> Regards, Benoit @@ -42,11 +34,6 @@ Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLFX8OR6EySwP7oIRAp2pAJ0batdz64sh9L82CIKzkmVcLyANygCeOq5q -D18DQ/Ko9ggdGn5lmshlMJs=3D -=3D3efH +D18DQ/Ko9ggdGn5lmshlMJs= +=3efH -----END PGP SIGNATURE----- --- -To unsubscribe from this list: send the line "unsubscribe linux-wireles= -s" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 442b005..8767c96 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,7 +10,7 @@ "To\0Felix Fietkau <nbd@openwrt.org>\0" "Cc\0Maxim Levitsky <maximlevitsky@gmail.com>" Derek Smithies <derek@indranet.co.nz> - ath5k-devel@lists.ath5k.org + ath5k-devel@venema.h4ckr.net linux-wireless@vger.kernel.org linux-kernel@vger.kernel.org ipw3945-devel@lists.sourceforge.net @@ -21,20 +21,15 @@ "-----BEGIN PGP SIGNED MESSAGE-----\n" "Hash: SHA1\n" "\n" - "=46elix Fietkau a =E9crit :\n" + "Felix Fietkau a \303\251crit :\n" "> While reading the code for calculating the frame duration, i noticed\n" "> something odd: It doesn't seem to be taking into account the short\n" - "> vs long preamble distinction for ERP rates. IMHO this might be causin=\n" - "g\n" - "> issues like this. I've seen similar behaviour a long time ago when te=\n" - "sting\n" - "> iwl3945 against a Broadcom AP with exactly the same throughput drop (=\n" - "500-\n" + "> vs long preamble distinction for ERP rates. IMHO this might be causing\n" + "> issues like this. I've seen similar behaviour a long time ago when testing\n" + "> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-\n" "> 600 kbits/s).\n" - "> When I analyzed the problem with an extra monitor mode card, I found =\n" - "out\n" - "> that the throughput drop is caused by a huge number of retransmission=\n" - "s,\n" + "> When I analyzed the problem with an extra monitor mode card, I found out\n" + "> that the throughput drop is caused by a huge number of retransmissions,\n" "\n" "In the test I've done, there was no retransmission at all (no\n" "duplicates). I don't save a capture file, so I cannot tell for sure.\n" @@ -42,18 +37,15 @@ "What is the code computing frame duration you are referring to? How it\n" "could affect the hardware behavior?\n" "\n" - "> and if I remember correctly (I didn't look for this specifically back=\n" - " then),\n" - "> the retransmissions went down the rate scaling table until they hit t=\n" - "he\n" + "> and if I remember correctly (I didn't look for this specifically back then),\n" + "> the retransmissions went down the rate scaling table until they hit the\n" "> first non-ERP rate and that one worked on the first try.\n" - ">=20\n" - "> Johannes, does that sound like a probable cause? If so, it should be =\n" - "easy\n" + "> \n" + "> Johannes, does that sound like a probable cause? If so, it should be easy\n" "> to fix.\n" - ">=20\n" + "> \n" "> - Felix\n" - ">=20\n" + "> \n" "\n" "Regards,\n" "Benoit\n" @@ -62,13 +54,8 @@ "Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n" "\n" "iD8DBQFJLFX8OR6EySwP7oIRAp2pAJ0batdz64sh9L82CIKzkmVcLyANygCeOq5q\n" - "D18DQ/Ko9ggdGn5lmshlMJs=3D\n" - "=3D3efH\n" - "-----END PGP SIGNATURE-----\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-wireles=\n" - "s\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "D18DQ/Ko9ggdGn5lmshlMJs=\n" + "=3efH\n" + -----END PGP SIGNATURE----- -e2b0dd20714092a00450f57c56e84bd4b41943b429b4c14bb29a006fe21eb259 +f029c1aa4f917ac99e9be2f2ba96801f89b7174ae4395584a2d565cf63ce2c1b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.