My rt3070 USB card works flawlessly when connected to an 802.11N AP. Excellent throughput, speed and reliability.
When connected to a 54G AP however, there is significant packet loss and duplicates.
I can confirm this to be happening with two older 54G APs, and not with a single N AP.
Does anyone else have the same problem?
Oh, forgot the mention - the results are with the latest CW.
> -0800, Walter Goldens wrote:
> > My rt3070 USB card works flawlessly when connected to
> an 802.11N AP. Excellent throughput, speed and reliability.
> >
> > When connected to a 54G AP however, there is
> significant packet loss and duplicates.
> > I can confirm this to be happening with two older 54G
> APs, and not with a single N AP.
> >
> > Does anyone else have the same problem?
>
> Usually we have opposite problem, 11g works, 11n does not.
>
> Are you using the lates wireless-testing tree? If not, try
> that
> i.e using compat-wireless package there are some pending
> radio chip
> programing fixes, I think they may help with packet lost.
>
> Stanislaw???
>
> > My rt3070 USB card works flawlessly when connected to
> an 802.11N AP. Excellent throughput, speed and reliability.
> >
> > When connected to a 54G AP however, there is
> significant packet loss and duplicates.
> > I can confirm this to be happening with two older 54G
> APs, and not with a single N AP.
> >
> > Does anyone else have the same problem?
>
> Usually we have opposite problem, 11g works, 11n does not.
>
> Are you using the lates wireless-testing tree? If not, try
> that
> i.e using compat-wireless package there are some pending
> radio chip
> programing fixes, I think they may help with packet lost.
>
> Stanislaw???
Hi Stanislaw,
This is from an N AP:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.47 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.952 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=11.1 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=7.06 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=12.8 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=13.5 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=2.79 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=61.7 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=13.2 ms
64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=6.46 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=7.03 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=8.16 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=6.80 ms
64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=8.15 ms
64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=6.34 ms
^C
--- 192.168.1.1 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15023ms
rtt min/avg/max/mdev = 0.952/10.582/61.742/13.795 ms
No problems whatsoever.
And these are from 54G AP:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=63 time=8.56 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=63 time=1.67 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=63 time=2.94 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=63 time=1.64 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=63 time=1.67 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=63 time=3.70 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=1.80 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=2.22 ms (DUP!)
64 bytes from 192.168.1.1: icmp_req=8 ttl=63 time=9.59 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=63 time=10.1 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=63 time=7.02 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=63 time=7.03 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=63 time=10.0 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=63 time=7.22 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=63 time=7.74 ms (DUP!)
64 bytes from 192.168.1.1: icmp_req=15 ttl=63 time=9.14 ms
64 bytes from 192.168.1.1: icmp_req=16 ttl=63 time=8.16 ms
^C
--- 192.168.1.1 ping statistics ---
16 packets transmitted, 15 received, +2 duplicates, 6% packet loss, time 15029ms
rtt min/avg/max/mdev = 1.640/5.904/10.166/3.228 ms
If I use the STA drivers, no such problem occurres with either N or G APs.
This, for me, has been a long-standing problem.
Walter
--- On Sat, 2/18/12, Stanislaw Gruszka <[email protected]> wrote:
> From: Stanislaw Gruszka <[email protected]>
> Subject: Re: [rt2x00] rt2800usb and RT3070 issues with 54G AP
> To: "Walter Goldens" <[email protected]>
> Cc: [email protected], "Ivo van Doorn" <[email protected]>
> Date: Saturday, February 18, 2012, 6:56 PM
> Hi.
>
> On Sat, Feb 18, 2012 at 04:11:36AM -0800, Walter Goldens
> wrote:
> > This is from an N AP:
> >
> > PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> > 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.47
> ms
> > 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.45
> ms
> > 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.952
> ms
> > 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=11.1
> ms
> > 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=7.06
> ms
> > 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=12.8
> ms
> [snip]
> > And these are from 54G AP:
> >
> > PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> > 64 bytes from 192.168.1.1: icmp_req=1 ttl=63 time=8.56
> ms
> > 64 bytes from 192.168.1.1: icmp_req=2 ttl=63 time=1.67
> ms
> > 64 bytes from 192.168.1.1: icmp_req=3 ttl=63 time=2.94
> ms
> > 64 bytes from 192.168.1.1: icmp_req=4 ttl=63 time=1.64
> ms
> > 64 bytes from 192.168.1.1: icmp_req=5 ttl=63 time=1.67
> ms
> > 64 bytes from 192.168.1.1: icmp_req=6 ttl=63 time=3.70
> ms
> > 64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=1.80
> ms
> > 64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=2.22
> ms (DUP!)
> [snip]
> > If I use the STA drivers, no such problem occurres with
> either N or G APs.
> > This, for me, has been a long-standing problem.
>
> Looks like this could be related with Power-Save. Seems APs
> does not
> handle PS well (between each ICMP packed our station is put
> in
> the sleep mode) . Vendor driver has? PS disabled, hence
> problem
> is not observable.
>
> Try "iwconfig wlan0 power off" and see if it helps.
>
> Stanislaw
Hello again,
Unfortunately, disabling PS does not fix the problem:
root@dell:~# iwconfig wlan1 power off
root@dell:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=5.55 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=2.09 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=4.83 ms (DUP!)
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=2.03 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.71 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.44 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.79 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=5.15 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=2.70 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=16.8 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=24.1 ms (DUP!)
64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=13.0 ms
^C
--- 192.168.1.1 ping statistics ---
11 packets transmitted, 10 received, +2 duplicates, 9% packet loss, time 10015ms
rtt min/avg/max/mdev = 1.443/6.786/24.168/7.023 ms
Walter
On Mon, Feb 20, 2012 at 08:52:54AM -0800, Walter Goldens wrote:
> > Looks like this could be related with Power-Save. Seems APs
> > does not
> > handle PS well (between each ICMP packed our station is put
> > in
> > the sleep mode) . Vendor driver has? PS disabled, hence
> > problem
> > is not observable.
> >
> > Try "iwconfig wlan0 power off" and see if it helps.
> >
> > Stanislaw
>
> Hello again,
>
> Unfortunately, disabling PS does not fix the problem:
I'm able to reproduce that problem locally, I'm adding debug
that problem to my TODO list ...
Stanislaw
Hi.
On Sat, Feb 18, 2012 at 04:11:36AM -0800, Walter Goldens wrote:
> This is from an N AP:
>
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.47 ms
> 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.45 ms
> 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.952 ms
> 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=11.1 ms
> 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=7.06 ms
> 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=12.8 ms
[snip]
> And these are from 54G AP:
>
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_req=1 ttl=63 time=8.56 ms
> 64 bytes from 192.168.1.1: icmp_req=2 ttl=63 time=1.67 ms
> 64 bytes from 192.168.1.1: icmp_req=3 ttl=63 time=2.94 ms
> 64 bytes from 192.168.1.1: icmp_req=4 ttl=63 time=1.64 ms
> 64 bytes from 192.168.1.1: icmp_req=5 ttl=63 time=1.67 ms
> 64 bytes from 192.168.1.1: icmp_req=6 ttl=63 time=3.70 ms
> 64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=1.80 ms
> 64 bytes from 192.168.1.1: icmp_req=7 ttl=63 time=2.22 ms (DUP!)
[snip]
> If I use the STA drivers, no such problem occurres with either N or G APs.
> This, for me, has been a long-standing problem.
Looks like this could be related with Power-Save. Seems APs does not
handle PS well (between each ICMP packed our station is put in
the sleep mode) . Vendor driver has PS disabled, hence problem
is not observable.
Try "iwconfig wlan0 power off" and see if it helps.
Stanislaw
On Sun, Feb 12, 2012 at 07:45:51AM -0800, Walter Goldens wrote:
> My rt3070 USB card works flawlessly when connected to an 802.11N AP. Excellent throughput, speed and reliability.
>
> When connected to a 54G AP however, there is significant packet loss and duplicates.
> I can confirm this to be happening with two older 54G APs, and not with a single N AP.
>
> Does anyone else have the same problem?
Usually we have opposite problem, 11g works, 11n does not.
Are you using the lates wireless-testing tree? If not, try that
i.e using compat-wireless package there are some pending radio chip
programing fixes, I think they may help with packet lost.
Stanislaw
Dear Stanislaw,
I've been away for a while, apologies for not participating in solving the duplicate packet issue. I reviewed your work on the subject and the patches you've submitted. Thank you for your contribution and keeping me informed.
With latest patches, I experience no more duplicate packets or significant data loss. The only issue remaining is Power Save. When PS is on, the latency is ridiculously high and packet loss occurrences are present. PS switched off keeps everything running smooth and problem-free.
Walter
--- On Mon, 2/20/12, Walter Goldens <[email protected]> wrote:
> From: Walter Goldens <[email protected]>
> Subject: Re: [rt2x00] rt2800usb and RT3070 issues with 54G AP
> To: "Stanislaw Gruszka" <[email protected]>
> Cc: [email protected], "Ivo van Doorn" <[email protected]>
> Date: Monday, February 20, 2012, 6:52 PM
>
>
> Walter
> --
> 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
>