N-driver: slowdown of speed & stop of client access

Post new topic   Reply to topic    DD-WRT Forum Index -> Atheros WiSOC based Hardware
Goto page 1, 2  Next
Author Message
Sash
DD-WRT Guru


Joined: 20 Sep 2006
Posts: 17619
Location: Hesse/Germany

PostPosted: Wed Aug 25, 2010 9:28    Post subject: N-driver: slowdown of speed & stop of client access Reply with quote
THIS DRIVER IS UNDER HEAVY DEVELOPMENT AND SHOULD KNOWN TO BE IN ALPHA/BETA STATUS! (matching all ar92XX/5416, ar71xx/73xx, etc. atheros systems). And you should always have the latest BETA build installed before reporting problems!

i see a decrease of speed on a test ap:

    build 15004
    gateworks
    ar9220
    b/g-mode
    2 streams w. v/h dual pol ant.
    30 customers
    b/g clients only


customers report that the speed slows down more and more over the day.
i cant reproduce it nor i cant see the problem from my side atm.
what i noticed some time ago is when i use 2,4ghz n-only after some time i cant access any clients and users report a total connection loss although the customer units are still connected to the ap. thats why i switched back to b/g-mode and thought the problem was gone.


btw
i see a similar behavior on a test client at a customer side. tl-wp941 in b/g client mode. connecting to a alix ap w. sr2. the client works ok for a while. when the customer boots the pc in the morning there wont be any outside/inet access but u can reach the client and browse it. the client itself cant ping the ap or anything else. after reboot the tl-wp941 communication is ok again. this happens every day


i'm wonder if you guys have seen similar.

_________________
Forum Guidelines...How to get help
&
Forum Rules
&
RTFM/STFW
&
Throw some buzzwords into the WIKI search Exclamation
_________________
I'm NOT rude, just offer pure facts!
_________________
Atheros (TP-Link & Clones, etc ) debrick service in EU
_________________
Guide on HowTo be Safe, Secure and Protect Your Online Anonymity!


Last edited by Sash on Thu Jan 13, 2011 15:02; edited 7 times in total
Sponsor
pbuck
DD-WRT User


Joined: 02 May 2010
Posts: 53
Location: Seattle, WA

PostPosted: Thu Aug 26, 2010 18:59    Post subject: Reply with quote
Yes this is basically what happens on my WZR-HP-G300NH and I posted it to the tracker several times, some of those times you actually closed the ticket saying it works for you.

Funny.

The MadWifi driver is trash with wireless N connections.
moorebt
DD-WRT Novice


Joined: 12 Aug 2010
Posts: 9

PostPosted: Thu Aug 26, 2010 21:19    Post subject: Reply with quote
I have 4 different Atheros devices all in client mode all having the exact same problem (AR430W, WZR-HP-300NH, WHR-HP-300N and a WHR-HP-GN) of randomly loosing the client AP and then they stop advertising their VAP requiring me to either plug a laptop into one of the switch ports and either rebooting or sometimes I can just resurvey and it comes back alive or hitting the apply setting button in the wireless tab brings the client access back to life, alternatively I just recycle the power and it comes back. This problem has been with me for the past 3 release of DD-WRT. That all 4 of these boxes have this issue makes me believe that there is clearly something wrong in the software.

If there are any details you want to know please ask, this is a very frustrating problem and I would love to see it fixed.
Highland
DD-WRT Novice


Joined: 25 Jul 2010
Posts: 2

PostPosted: Fri Aug 27, 2010 2:02    Post subject: Reply with quote
I have seen the same basic problem on my WHR-HP-G300N. At first it seemed like a packet loss problem (~20-30%) but, as I've played with the official Buffalo 14512 build, I've come to believe that it's not true packet loss at all, but a general slowness in the router itself. I ran it for 24 hours and let my wife play around with it and she reported a consistent sluggish response to her requests (mostly web related). Sometimes the router would be snappy and sometimes it would just time out.

The Buffalo stock firmware does not have this problem and I've tried several flashes to confirm it is DD-WRT and not my connection. It's a pity since the Buffalo stock firmware is really not all that intuitive to use. Still, I run it because it's the only thing that leaves the router usable.
Sash
DD-WRT Guru


Joined: 20 Sep 2006
Posts: 17619
Location: Hesse/Germany

PostPosted: Fri Aug 27, 2010 8:01    Post subject: Reply with quote
yesterday i observed a dramatically latency increase when i ping from a client (200m away) from the ap

...
64 bytes from 195.135.220.3: seq=61 ttl=55 time=17.701 ms
64 bytes from 195.135.220.3: seq=62 ttl=55 time=19.458 ms
64 bytes from 195.135.220.3: seq=63 ttl=55 time=15.354 ms
64 bytes from 195.135.220.3: seq=64 ttl=55 time=15.043 ms
64 bytes from 195.135.220.3: seq=65 ttl=55 time=27.167 ms
64 bytes from 195.135.220.3: seq=66 ttl=55 time=19.804 ms
64 bytes from 195.135.220.3: seq=67 ttl=55 time=20.414 ms
64 bytes from 195.135.220.3: seq=68 ttl=55 time=18.999 ms
64 bytes from 195.135.220.3: seq=69 ttl=55 time=18.253 ms
64 bytes from 195.135.220.3: seq=70 ttl=55 time=15.915 ms
64 bytes from 195.135.220.3: seq=71 ttl=55 time=15.169 ms
64 bytes from 195.135.220.3: seq=72 ttl=55 time=15.453 ms
64 bytes from 195.135.220.3: seq=74 ttl=55 time=278.579 ms
64 bytes from 195.135.220.3: seq=75 ttl=55 time=9068.229 ms
64 bytes from 195.135.220.3: seq=76 ttl=55 time=18175.587 ms
64 bytes from 195.135.220.3: seq=77 ttl=55 time=33831.086 ms
64 bytes from 195.135.220.3: seq=78 ttl=55 time=37839.089 ms
64 bytes from 195.135.220.3: seq=79 ttl=55 time=42278.988 ms
64 bytes from 195.135.220.3: seq=80 ttl=55 time=42405.453 ms
64 bytes from 195.135.220.3: seq=81 ttl=55 time=48830.636 ms
64 bytes from 195.135.220.3: seq=82 ttl=55 time=49517.127 ms
64 bytes from 195.135.220.3: seq=83 ttl=55 time=50427.608 ms
64 bytes from 195.135.220.3: seq=84 ttl=55 time=52558.553 ms
64 bytes from 195.135.220.3: seq=88 ttl=55 time=50048.237 ms
64 bytes from 195.135.220.3: seq=89 ttl=55 time=58219.698 ms
64 bytes from 195.135.220.3: seq=90 ttl=55 time=58889.016 ms
64 bytes from 195.135.220.3: seq=91 ttl=55 time=61305.665 ms
64 bytes from 195.135.220.3: seq=92 ttl=55 time=61534.422 ms
64 bytes from 195.135.220.3: seq=93 ttl=55 time=67597.709 ms
64 bytes from 195.135.220.3: seq=94 ttl=55 time=67112.036 ms
64 bytes from 195.135.220.3: seq=95 ttl=55 time=66838.631 ms
64 bytes from 195.135.220.3: seq=96 ttl=55 time=66609.387 ms
64 bytes from 195.135.220.3: seq=97 ttl=55 time=66838.396 ms
64 bytes from 195.135.220.3: seq=98 ttl=55 time=66489.306 ms
64 bytes from 195.135.220.3: seq=99 ttl=55 time=66683.528 ms
64 bytes from 195.135.220.3: seq=100 ttl=55 time=67206.624 ms
64 bytes from 195.135.220.3: seq=101 ttl=55 time=73850.485 ms
64 bytes from 195.135.220.3: seq=102 ttl=55 time=77798.513 ms
64 bytes from 195.135.220.3: seq=103 ttl=55 time=77838.565 ms
64 bytes from 195.135.220.3: seq=104 ttl=55 time=78838.361 ms
64 bytes from 195.135.220.3: seq=105 ttl=55 time=78808.737 ms
64 bytes from 195.135.220.3: seq=106 ttl=55 time=78830.765 ms
64 bytes from 195.135.220.3: seq=107 ttl=55 time=78137.459 ms
64 bytes from 195.135.220.3: seq=108 ttl=55 time=80313.614 ms
64 bytes from 195.135.220.3: seq=109 ttl=55 time=85252.313 ms
64 bytes from 195.135.220.3: seq=110 ttl=55 time=84418.056 ms
64 bytes from 195.135.220.3: seq=111 ttl=55 time=84789.027 ms
64 bytes from 195.135.220.3: seq=112 ttl=55 time=88433.697 ms
64 bytes from 195.135.220.3: seq=113 ttl=55 time=88838.540 ms
64 bytes from 195.135.220.3: seq=114 ttl=55 time=88708.109 ms
64 bytes from 195.135.220.3: seq=115 ttl=55 time=89631.628 ms
64 bytes from 195.135.220.3: seq=116 ttl=55 time=92074.485 ms
64 bytes from 195.135.220.3: seq=117 ttl=55 time=93641.405 ms
64 bytes from 195.135.220.3: seq=122 ttl=55 time=88838.705 ms
64 bytes from 195.135.220.3: seq=125 ttl=55 time=89214.964 ms
64 bytes from 195.135.220.3: seq=126 ttl=55 time=91830.893 ms
64 bytes from 195.135.220.3: seq=130 ttl=55 time=101357.041 ms
64 bytes from 195.135.220.3: seq=132 ttl=55 time=103529.036 ms
64 bytes from 195.135.220.3: seq=133 ttl=55 time=102530.708 ms
64 bytes from 195.135.220.3: seq=135 ttl=55 time=100535.177 ms
64 bytes from 195.135.220.3: seq=136 ttl=55 time=99537.219 ms
64 bytes from 195.135.220.3: seq=137 ttl=55 time=98538.850 ms
64 bytes from 195.135.220.3: seq=139 ttl=55 time=96546.911 ms
64 bytes from 195.135.220.3: seq=140 ttl=55 time=95548.246 ms
64 bytes from 195.135.220.3: seq=141 ttl=55 time=94549.776 ms
64 bytes from 195.135.220.3: seq=142 ttl=55 time=93557.842 ms
64 bytes from 195.135.220.3: seq=145 ttl=55 time=90561.667 ms
64 bytes from 195.135.220.3: seq=147 ttl=55 time=88587.306 ms
64 bytes from 195.135.220.3: seq=148 ttl=55 time=87602.063 ms
64 bytes from 195.135.220.3: seq=149 ttl=55 time=86609.375 ms
64 bytes from 195.135.220.3: seq=151 ttl=55 time=84624.060 ms
64 bytes from 195.135.220.3: seq=154 ttl=55 time=81626.191 ms
64 bytes from 195.135.220.3: seq=155 ttl=55 time=80629.695 ms
64 bytes from 195.135.220.3: seq=156 ttl=55 time=79632.202 ms
64 bytes from 195.135.220.3: seq=158 ttl=55 time=77636.518 ms
64 bytes from 195.135.220.3: seq=160 ttl=55 time=75641.070 ms
64 bytes from 195.135.220.3: seq=161 ttl=55 time=74646.806 ms
64 bytes from 195.135.220.3: seq=162 ttl=55 time=73665.963 ms
64 bytes from 195.135.220.3: seq=163 ttl=55 time=72671.124 ms
64 bytes from 195.135.220.3: seq=164 ttl=55 time=71675.373 ms
64 bytes from 195.135.220.3: seq=167 ttl=55 time=68685.317 ms
64 bytes from 195.135.220.3: seq=170 ttl=55 time=65693.197 ms
64 bytes from 195.135.220.3: seq=174 ttl=55 time=61694.598 ms
64 bytes from 195.135.220.3: seq=175 ttl=55 time=60698.554 ms
64 bytes from 195.135.220.3: seq=178 ttl=55 time=57704.104 ms
64 bytes from 195.135.220.3: seq=180 ttl=55 time=55728.416 ms
64 bytes from 195.135.220.3: seq=182 ttl=55 time=53729.720 ms
64 bytes from 195.135.220.3: seq=184 ttl=55 time=51733.775 ms
64 bytes from 195.135.220.3: seq=185 ttl=55 time=50735.683 ms
64 bytes from 195.135.220.3: seq=186 ttl=55 time=49738.002 ms
64 bytes from 195.135.220.3: seq=187 ttl=55 time=48747.743 ms
64 bytes from 195.135.220.3: seq=188 ttl=55 time=47755.325 ms
64 bytes from 195.135.220.3: seq=195 ttl=55 time=40777.361 ms
64 bytes from 195.135.220.3: seq=196 ttl=55 time=39778.318 ms
64 bytes from 195.135.220.3: seq=205 ttl=55 time=30786.735 ms
64 bytes from 195.135.220.3: seq=208 ttl=55 time=27809.404 ms
64 bytes from 195.135.220.3: seq=211 ttl=55 time=24810.573 ms
64 bytes from 195.135.220.3: seq=212 ttl=55 time=23811.097 ms
64 bytes from 195.135.220.3: seq=224 ttl=55 time=11761.564 ms
64 bytes from 195.135.220.3: seq=225 ttl=55 time=10762.026 ms
64 bytes from 195.135.220.3: seq=231 ttl=55 time=4763.182 ms
64 bytes from 195.135.220.3: seq=236 ttl=55 time=20.772 ms
64 bytes from 195.135.220.3: seq=237 ttl=55 time=17.064 ms
64 bytes from 195.135.220.3: seq=238 ttl=55 time=15.708 ms
64 bytes from 195.135.220.3: seq=239 ttl=55 time=15.336 ms
...


this will repeat till death. sometimes the ap get stuck at high latency, and the watchdog reboots the unit

_________________
Forum Guidelines...How to get help
&
Forum Rules
&
RTFM/STFW
&
Throw some buzzwords into the WIKI search Exclamation
_________________
I'm NOT rude, just offer pure facts!
_________________
Atheros (TP-Link & Clones, etc ) debrick service in EU
_________________
Guide on HowTo be Safe, Secure and Protect Your Online Anonymity!
newvisionantenna
DD-WRT User


Joined: 31 Jan 2009
Posts: 114
Location: Ansbach, Germany

PostPosted: Fri Aug 27, 2010 16:03    Post subject: Reply with quote
I'm glad I stopped and looked before I posted. I almost made another topic about this.

So the problem goes like this, RouterStation and the R52N card in 2.4ghz.

My AP serves a Toshiba laptop and the new 11N Xbox 360 and twice now the wifi has came to a halt, it appears the connection is still alive but no traffic passes and nothing loads.

I'll say that this same/similar problem or result has been in ath9k for some time. I have 20+ AP's setup with ath9k serving hundreds of client's at location X. Thankfully I had a backup plan of madwifi/11G inside the AP. After a very long year, OpenWRT seems to have resolved said issue and ath9k is going strong.

Is there an expected time frame for the dd-wrt driver to emerge from beta? Any way to get a discount on keys being purchased if it truely is beta? Seems odd that I'm paying full price to be a "beta" tester.

Thanks


Last edited by newvisionantenna on Sat Aug 28, 2010 4:59; edited 1 time in total
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Fri Aug 27, 2010 16:52    Post subject: Reply with quote
newvisionantenna wrote:
Any way to get a discount on keys being purchased if it truely is beta? Seems odd that I'm paying full price to be a "beta" tester.



So you were not aware that the n-driver was beta and under development when you bought the keys?

_________________
Kernel panic: Aiee, killing interrupt handler!
newvisionantenna
DD-WRT User


Joined: 31 Jan 2009
Posts: 114
Location: Ansbach, Germany

PostPosted: Fri Aug 27, 2010 17:28    Post subject: Reply with quote
Thank you for your concern, but I was fully aware on both accounts. I would just expect that if I'm paying for firmware beta or not, that it would atleast be more stable then what I'm getting out of large real world install of ath9k running in ap mode that cost me nothing.

I could care less about all the extra 11n features if the most basic of functions is not working properly.
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Fri Aug 27, 2010 17:48    Post subject: Reply with quote
newvisionantenna wrote:
Thank you for your concern, but I was fully aware on both accounts. I would just expect that if I'm paying for firmware beta or not, that it would atleast be more stable then what I'm getting out of large real world install of ath9k running in ap mode that cost me nothing.

I could care less about all the extra 11n features if the most basic of functions is not working properly.


Ok, I understand your points.
Just a question, since how long back do you consider the ath9k to be a functional driver for you?
You said that it had been a "long and painful year" before the ath9k problems got fixed.
I'm asking you since I understand that you have quite a long experience with both ath9k and madwifi drivers.

_________________
Kernel panic: Aiee, killing interrupt handler!
newvisionantenna
DD-WRT User


Joined: 31 Jan 2009
Posts: 114
Location: Ansbach, Germany

PostPosted: Fri Aug 27, 2010 19:33    Post subject: Reply with quote
I had this big message typed up and the forum timed out...

To make it short and sweet, just being hard on dd-wrt. I understand beta stuff takes awhile to get right. I was just surprised to see the same/similar issue as seen on ath9k. I have a feeling that if I put dd-wrt into the same install I would see this issue a lot more.

Right now the small single test ap at my house has stopped passing traffic several times. I don't know if one certain thing triggers it or what. I'm to burnt out from working with OpenWRT devs and allowing them into ap's for ath9k enhancments to provide proper dd-wrt 11n feedback at the moment.

To answer your question about ath9k, it's only within the last 2-3 weeks that things have stablized to a point where it appears ap mode can recover from a "stuck" state.
lordgreg
DD-WRT Novice


Joined: 23 Feb 2008
Posts: 49

PostPosted: Fri Aug 27, 2010 21:53    Post subject: Reply with quote
so, let me see if i understood this post properly:

* everyone is talking about how their speed on N is dropping to 130mbps
* there are several tickets opened on this same issue. the ticket has been reopened several times
* everyone is asking if latest dd-wrt build has fixed this issue
* now new pinned thread is opened with the same issue as everyone is having?
* not to be rude and talking about how this is NOT dd-wrt issue since i have 300mbit connection constantly with official firmware of my Buffalo WZR-HP-300NH

Hope this beta/alpha/gamma/you_name_it driver gets its bug fixed soon :$
newvisionantenna
DD-WRT User


Joined: 31 Jan 2009
Posts: 114
Location: Ansbach, Germany

PostPosted: Sat Aug 28, 2010 4:49    Post subject: Reply with quote
It's not dropping to 130mbps, it's getting "stuck" and not allowing any traffic to pass.
Gingernut
DD-WRT User


Joined: 29 Jul 2007
Posts: 229

PostPosted: Tue Aug 31, 2010 15:00    Post subject: Reply with quote
lordgreg wrote:
everyone is asking if latest dd-wrt build has fixed this issue



Sash's build number is 15004, based on ddwrts timeline, this build is from 28/08/10 and hasn't been released to the public.

From changeset 15004 to 15060 there's been a lot of changes so maybe it has been fixed and is in testing.
slybunda
DD-WRT User


Joined: 09 Jan 2010
Posts: 471

PostPosted: Fri Sep 03, 2010 20:10    Post subject: Reply with quote
madwifi web page shows last update was done in 2008. is madwifi driver still being worked on or is the current version the final version of the driver?

also do older atheros hardware such as the Atheros MIPS 4KC in ubiquiti bullet work ok with dd-wrt or are they also unstable?
santiagodraco
DD-WRT Novice


Joined: 03 Sep 2010
Posts: 15

PostPosted: Tue Sep 07, 2010 23:59    Post subject: Reply with quote
I'm having the same issue with my new WNDR3700 routers. Wireless works fine for a bit then completely stops. The routers have to be restarted to restore functionality.

This along with Client Bridging being broken on the latest release build.
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Atheros WiSOC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum