I know from experience that the staging driver rt82860sta has been replaced by
rt2800pci and I plan to push a patch deleting the driver from staging.
It appears that rt2870sta has been replaced by rt2800usb. Is that correct? If
so, I will also include the deletion of that driver from staging in the patch.
I noticed that rt2870sta includes a few USB IDs not found in rt2800usb, namely:
0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
Any reasons why these should not be included in rt2800usb?
Please let me know of any objections to removing those two staging drivers.
Thanks,
Larry
On Thu, Apr 7, 2011 at 5:19 PM, Walter Goldens <[email protected]> wrote:
>
>> I know from experience that the
>> staging driver rt82860sta has been replaced by rt2800pci and
>> I plan to push a patch deleting the driver from staging.
>>
>> It appears that rt2870sta has been replaced by rt2800usb.
>> Is that correct? If so, I will also include the deletion of
>> that driver from staging in the patch.
>>
>> I noticed that rt2870sta includes a few USB IDs not found
>> in rt2800usb, namely:
>>
>> 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
>>
>> Any reasons why these should not be included in rt2800usb?
>>
>> Please let me know of any objections to removing those two
>> staging drivers.
>
> Here's my vote against removing the rt2870sta from staging. Some longstanding issues with latency and duplicate packets (rt307x) are persistent with rt2800usb, whereas rt2870sta works fine.
>
> my two cents
>
> Walter
Personally, I've had the opposite (since the patch to disable power
management on rt2800usb.) rt2870sta hasn't been noticeably more
stable, and in fact, I tend to see div0 bugs quite often when using
it. That said, I'm using Azurewave rt3070s.
--
Steev Klimaszewski <[email protected]>
Senior Software Engineer, Genesi USA, Inc.
Larry Finger wrote:
> I noticed that rt2870sta includes a few USB IDs not found in rt2800usb, namely:
>
> 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
>
> Any reasons why these should not be included in rt2800usb?
They were in the ralink driver imported into the kernel,
and later they were eliminated in recent versions of ralink drivers:
2010_0709_RT2870_Linux_STA_v2.4.0.1
2010_1215_RT3572_Linux_STA_v2.5.0.0.DPO
2011_0107_RT3070_RT3370_Linux_STA_v2.5.0.1_DPO
Only these four were meaningful, and they were included by me in rt2800usb.c:
<http://marc.info/?l=linux-wireless&m=130125079513964&w=2>
0x0411,0x016f de37cd49b5a54facef174cf34496919857436e8f MelCo(Buffalo) WLI-UC-G301N
0x050d,0x825b 12840c63b0679f7fab88ea1cc26b52db8b574ce7 Belkin F5D8055
0x050d,0x935a 705059a670f3af2b37695e82de0ee58e75e656ed Belkin F6D4050 v1
0x050d,0x935b 5d92fe3387d086fc2f10426fbdb6b86d6cce5a47 Belkin F6D4050 v2
I think 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14 can be despised,
unless they also be in the windows driver.
Am Freitag, 8. April 2011 schrieb Walter Goldens:
> Further investigation suggests the DUP! packets stem from one specific AP.
> Different APs seem to have less duplicate packets and overall packet-loss.
> Its puzzling to me however that the said AP does not produce DUP! packs
> at all with rt2870sta.
Is the AP 11n capable? Could you try to get a wifi capture when these
duplicates happen (with a second station in monitor mode)?
Thanks,
Helmut
> Walter Goldens:
> > Further investigation suggests the DUP! packets stem
> from one specific AP.
> > Different APs seem to have less duplicate packets and
> overall packet-loss.
> > Its puzzling to me however that the said AP does not
> produce DUP! packs
> > at all with rt2870sta.
>
> Is the AP 11n capable? Could you try to get a wifi capture
> when these
> duplicates happen (with a second station in monitor mode)?
Hi Helmut,
Your question about the 11N AP sparked interesting results. An 11n capable AP, but connected to a 54G mode did NOT produce a _single_ DUP! packet! Well over 2000 packets transmitted, not a single one duplicate.
This clearly isolates the problem to 54 B/G-Only APs.
Regarding your request for a capture file where duplicate packets occur, I have this to ask. I found out rt2800usb has the ability to switch to monitor mode - while connected to the AP and the gateway is ping-able. Will a capture from the same PC connected to the AP do the job for analysis? It will take me some time to set up a second station running the rt2800usb module and capture communications between the AP and the said PC.
Please let me know.
Walter
Hi Larry,
Am Donnerstag, 7. April 2011 schrieb Larry Finger:
> I know from experience that the staging driver rt82860sta has been replaced by
> rt2800pci and I plan to push a patch deleting the driver from staging.
rt2800pci is quite stable already (at least for me). So removing rt2860sta
would be ok I think.
> It appears that rt2870sta has been replaced by rt2800usb. Is that correct? If
> so, I will also include the deletion of that driver from staging in the patch.
>
> I noticed that rt2870sta includes a few USB IDs not found in rt2800usb, namely:
>
> 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
>
> Any reasons why these should not be included in rt2800usb?
I'm not quite sure about rt2800usb. It's still a bit immature in my opinion.
On the other hand, as long as people just use the staging driver instead of
reporting bugs for rt2800usb that situation won't change that fast.
Helmut
Hi,
> I know from experience that the staging driver rt82860sta has been replaced
> by rt2800pci and I plan to push a patch deleting the driver from staging.
Excellent! :)
> It appears that rt2870sta has been replaced by rt2800usb. Is that correct?
> If so, I will also include the deletion of that driver from staging in the
> patch.
Yeah, rt2800usb is the rt2x00 version of rt2870sta.
> I noticed that rt2870sta includes a few USB IDs not found in rt2800usb,
> namely:
>
> 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
>
> Any reasons why these should not be included in rt2800usb?
Nope, could you post a patch to add them?
> Please let me know of any objections to removing those two staging drivers.
I would definately welcome the removal of the staging drivers.
Ivo
Hi,
On Fri, Apr 8, 2011 at 11:32 AM, Walter Goldens
<[email protected]> wrote:
>> > Here's my vote against removing the rt2870sta from
>> staging. Some longstanding issues with latency and duplicate
>> packets (rt307x) are persistent with rt2800usb, whereas
>> rt2870sta works fine.
>> >
>> > my two cents
>> >
>> > Walter
>>
>> Personally, I've had the opposite (since the patch to
>> disable power
>> management on rt2800usb.)? rt2870sta hasn't been
>> noticeably more
>> stable, and in fact, I tend to see div0 bugs quite often
>> when using
>> it.? That said, I'm using Azurewave rt3070s.
>
> My vote went against only because of this:
> (rt3070 - 148f:3070)
>
> Ping gateway with staging:
>
> 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=4.34 ms
> 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=4.70 ms
> 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=1.61 ms
> 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.68 ms
> 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.33 ms
> 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=6.57 ms
> 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=4.45 ms
> ^C
> --- 192.168.1.1 ping statistics ---
> 7 packets transmitted, 7 received, 0% packet loss, time 6009ms
>
>
> Now pinging gateway with rt2800usb:
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=647 ms
> 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=1590 ms
> 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=583 ms
> 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=29.2 ms
> 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1674 ms
> 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=667 ms
> 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=668 ms (DUP!)
> 64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1645 ms
> 64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=637 ms
> 64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.38 ms
> ^C
> --- 192.168.1.1 ping statistics ---
> 10 packets transmitted, 9 received, +1 duplicates, 10% packet loss, time 9032ms
> rtt min/avg/max/mdev = 1.384/814.547/1674.284/588.666 ms, pipe 2
>
>
> Steev, you mentioned there was a fix? Could you please point which patch resolves this?
>
> I'll be glad to drop the staging driver if rt2800usb does not lag anymore.
Try:
iwconfig wlan0 power off
to disable powersaving.
Ivo
> > Try:
> >
> > iwconfig wlan0 power off
> >
> > to disable powersaving.
> >
> > Ivo
>
> Hi Ivo,
>
> Disabling power decreased latency substantially to a normal
> level, however it paved the way for myriad duplicate
> packets.
>
> rt2800usb:
>
> PING gmail.com (209.85.229.19) 56(84) bytes of data.
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=1 ttl=53 time=52.9 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=2 ttl=53 time=50.2 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=3 ttl=53 time=51.6 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=4 ttl=53 time=52.8 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=5 ttl=53 time=53.3 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=6 ttl=53 time=51.4 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=6 ttl=53 time=52.4 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=6 ttl=53 time=52.5 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=51.8 ms
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=54.8 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=56.5 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=58.2 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=59.9 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=61.3 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=62.9 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=7 ttl=53 time=63.3 ms (DUP!)
> 64 bytes from ww-in-f19.1e100.net (209.85.229.19):
> icmp_req=8 ttl=53 time=51.4 ms
> ^C
> --- gmail.com ping statistics ---
> 8 packets transmitted, 8 received, +9 duplicates, 0% packet
> loss, time 7011ms
> rtt min/avg/max/mdev = 50.285/55.181/63.304/4.219 ms
>
> Without these, the rt2800usb is looking to be pretty
> stellar driver.
Further investigation suggests the DUP! packets stem from one specific AP. Different APs seem to have less duplicate packets and overall packet-loss. Its puzzling to me however that the said AP does not produce DUP! packs at all with rt2870sta.
I think the problem may be originating from the device's retransmission pattern. The device thinks that certain package(s) were not transmitted correctly and attempts to re-send them again which in essence results in duplicates.
Network tests completed with staging and rt2800usb indicate staging slightly outperforms rt2800usb. Also it appears some throughput is lost with rt2800usb.
My verdict nevertheless: Drop the staging driver and leave rt2800usb as primary.
I'm sure improvements will be made. Plus, having both drivers load together, clash with each other and confuse users isn't desirable, either.
Walter
>
> Try:
>
> iwconfig wlan0 power off
>
> to disable powersaving.
>
> Ivo
Hi Ivo,
Disabling power decreased latency substantially to a normal level, however it paved the way for myriad duplicate packets.
rt2800usb:
PING gmail.com (209.85.229.19) 56(84) bytes of data.
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=1 ttl=53 time=52.9 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=2 ttl=53 time=50.2 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=3 ttl=53 time=51.6 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=4 ttl=53 time=52.8 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=5 ttl=53 time=53.3 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=6 ttl=53 time=51.4 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=6 ttl=53 time=52.4 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=6 ttl=53 time=52.5 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=51.8 ms
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=54.8 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=56.5 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=58.2 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=59.9 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=61.3 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=62.9 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=7 ttl=53 time=63.3 ms (DUP!)
64 bytes from ww-in-f19.1e100.net (209.85.229.19): icmp_req=8 ttl=53 time=51.4 ms
^C
--- gmail.com ping statistics ---
8 packets transmitted, 8 received, +9 duplicates, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 50.285/55.181/63.304/4.219 ms
Without these, the rt2800usb is looking to be pretty stellar driver.
Walter
> I know from experience that the
> staging driver rt82860sta has been replaced by rt2800pci and
> I plan to push a patch deleting the driver from staging.
>
> It appears that rt2870sta has been replaced by rt2800usb.
> Is that correct? If so, I will also include the deletion of
> that driver from staging in the patch.
>
> I noticed that rt2870sta includes a few USB IDs not found
> in rt2800usb, namely:
>
> 0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
>
> Any reasons why these should not be included in rt2800usb?
>
> Please let me know of any objections to removing those two
> staging drivers.
Here's my vote against removing the rt2870sta from staging. Some longstanding issues with latency and duplicate packets (rt307x) are persistent with rt2800usb, whereas rt2870sta works fine.
my two cents
Walter
> > Here's my vote against removing the rt2870sta from
> staging. Some longstanding issues with latency and duplicate
> packets (rt307x) are persistent with rt2800usb, whereas
> rt2870sta works fine.
> >
> > my two cents
> >
> > Walter
>
> Personally, I've had the opposite (since the patch to
> disable power
> management on rt2800usb.)? rt2870sta hasn't been
> noticeably more
> stable, and in fact, I tend to see div0 bugs quite often
> when using
> it.? That said, I'm using Azurewave rt3070s.
My vote went against only because of this:
(rt3070 - 148f:3070)
Ping gateway with staging:
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=4.34 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=4.70 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=1.61 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.68 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=6.57 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=4.45 ms
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
Now pinging gateway with rt2800usb:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=647 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=1590 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=583 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=29.2 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1674 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=667 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=668 ms (DUP!)
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1645 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=637 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.38 ms
^C
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 9 received, +1 duplicates, 10% packet loss, time 9032ms
rtt min/avg/max/mdev = 1.384/814.547/1674.284/588.666 ms, pipe 2
Steev, you mentioned there was a fix? Could you please point which patch resolves this?
I'll be glad to drop the staging driver if rt2800usb does not lag anymore.
Walter