Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.8.0.0-9028
#11
lonnie Wrote:Just to be sure --> it still has the AP stall and disconnect happening?
Yes. But, again, it's a collection of behaviors. What's happened twice tonight is an overall slowdown - so clients all getting < 1 Mbit. So, a bunch of clients trying to transfer data, but only getting 30 or 50 KBytes/second throughput. I do a -a activate and everyone disconnects and reconnects and everyone starts getting their 2 or 3 megabit per second CBQ rates. BUT, as I've said before - since it's just an 'activate' that'll likely only help for a few hours typically, whereas a reboot will likely help for a day.

If I left it in that state (slow state) then before long a couple of the clients would be unreachable / unpingable. Then some of them would have 0.0.0.0 IP addresses. Then a bunch of the clients would be unreachable... and then everyone's idle time would count up to 5 minutes, and then everyone would be de-auth'd due to inactivity. BUT, since we now sit and stare at all our WAR1B Access Points 20 hours per day, we reset or reboot them before that, and if we don't (for the 4 hours we sleep each night) then the ping watchdog on the AP will reboot the AP.

So yes, as near as I can tell - there is no change from the behavior with WAR1B's as an Access Point - not from 4.4.5.5 to 4.8.0.1 or anything between. Other than of course the 'auto reset' mechanism that came in with 4.4.5.6, but that was overly aggressive and would reset an AP 100 times per day.

Quote:The only thing left is the 4.9 driver if that is the case. It is totally different. All the other drivers have evolved from the Linux kernel ath9K and there seems to be a common problem.

As I've said, I don't know this has anything at all to do with ''the driver''. It could be other things - maybe something to do with the 'Auto Noise Immunity' backing things off maybe, or something with RTS/CTS maybe, or something with the card output backing off in power output so that the client's can't get the right throughput anymore, or something inherent with the WAR1B & APU hardware, since we've never seen this on any other hardware other than WAR1B and APU's (and apparently Ventanas from what I've heard) and as far as I know, all other hardware doesn't have this same problem with 4.4.5.6 or 4.6 or 4.7 or 4.8 or whatever versions. Of course, you previously said on these forums that ''it affects all hardware'' and again, that makes me feel like whatever problem you're working on is either not the same problem we're seeing for the last two years, or we've just don't see it for some reason.
Reply
#12
lonnie Wrote:Build 9030... ...fixes the 1 mbps last rate issue

It does not appear so. Exactly same behavior again. Any client who get's to 30 seconds of idle time, immediately (exactly at 30 seconds) will snap to 1 mbit on the RX Display of the AP.


.jpg   10.10.4_1Mbit_Rates_build_9030.jpg (Size: 56.64 KB / Downloads: 17)
Reply
#13
hehe That is quite likely because I modified the Tx rate logic. I guess I only did half of the equation.


ninedd Wrote:It does not appear so. Exactly same behavior again. Any client who get's to 30 seconds of idle time, immediately (exactly at 30 seconds) will snap to 1 mbit on the RX Display of the AP.

[Image: attachment.php?thumbnail=469]
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)