Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.8.8806
#1
I am pleased to release Version 4.8.8806. for the War1B. Others will follow in the coming week.

It is available for download at https://cp.sync.com/dl/4bd9ff300#5imn6u3...r-rfcrd8vi

Please test this on an easy to access system and make sure it is stable for your situation. The firmware has been stress tested for general function and throughput (5 hour continous speed test) in an indoor environment. Your outdoor and long term use "might" not be the same. I have NOT had any issues with upgrading and absolutely NO BRICKS have been created. I will say this is a safe release and your long term use will determine its reliability.

PLEASE post any reports, good or bad of your testing and use. Your feedback is important and helps me to make repairs.

Main Features of the 4.8.8806 Release

- NO Licensed Frequency support.
- NO Bridging support.
- NO Hidden ESSID.
- NO Full Duplex.
- NO Basic SYNC support.

- make sure you do NOT use u-APSD on the clients

- This is an ALL NEW driver and I need to have the core functionality tested for reliability, mainly to see if the AP stall issue is gone. It will take a lot of additions (have done it several times before, so it will be done) for the licensed frequencies and other StarOS enhancements, so I need to be adding these changes to a working base. It is the only way I will know for sure if any additions make the base unstable, so PLEASE give this a test in a spot that has problems. With no licensed frequency support it will be an even better stress test since it will have to contend with more interference.

The following versions have been tested

- War1B

Please test this and report good and bad news to this thread.
Reply
#2
I've put 4.8.8806 on one of our WAR1B AP's and on the WAR1B clients on that AP. The AP is in 2422 Mhz and HT20 width. Everything came back up (no bricks) and everything re-associated. It's difficult to tell performance, it's the middle of the day and performance issues don't really start until people start using it more at 6-11 PM, but individual thoughput tests the performance seems good, similar to 4.7.1.0 (from what I can tell in 10 minutes...)
Reply
#3
How often would that AP stall? Once a day? More?

Thanks for testing this.

ninedd Wrote:I've put 4.8.8806 on one of our WAR1B AP's and on the WAR1B clients on that AP. The AP is in 2422 Mhz and HT20 width. Everything came back up (no bricks) and everything re-associated. It's difficult to tell performance, it's the middle of the day and performance issues don't really start until people start using it more at 6-11 PM, but individual thoughput tests the performance seems good, similar to 4.7.1.0 (from what I can tell in 10 minutes...)
Reply
#4
That AP (our AP # 86) would FUBAR 50 times per day with 4.4.5.6-7744 when it had 18 clients connected to it. Now that it only has 2 low use clients left, it can run for days usually. I have left 4.8.8806 on it for now to see. On that AP, I don't really expect we'll see much different - on a low client, low noise and low usage AP, we don't typically see the fubar problem often. It shows up on higher client count, higher usage times, and higher noise environments.

Again, I should reiterate that the AP problem isn't just stall - it can be some combination of either all signals dropping to -80's, and/or throughput dropping to ~1 mbit total on the whole AP, and/or latency going WAY up to everyone, and/or no traffic & no ping to any clients, and/or deauthing all clients due to inactivity.

So, sometimes everything looks fine for everyone's signal/rates/quality - but no one is getting more than 200 or 500 kbit of traffic and there's no way to really detect that other than angry customer's calling, and then when we look and test - the overall throughput is dropped to very very low. Other times, the client signals drop way way off over time. So, a client who is -50 right now might drop to -75 and they might still work OK and not notice anything, but someone who is -64 right now might drop to -89 and barely pass any traffic. Other times, everyone looks perfectly good - throughput is clicking along as per normal to everyone, latency is low, signals are fine... and suddenly it instantly drops to 0 traffic to anyone, and the idle time climbs to everyone, which will eventually de-auth everyone and leave 0 associations. Of course, that 0-client deal typically follows either a low-throughput and/or a high-latency and/or a low-signal-to-everyone situation... those situations usually are a precursor to a 0-client, but not always... that can happen instantly without any warning right when everyone is working seemingly perfectly.

Currently however, we have a ping watchdog pinging one of the clients and so if it can't communicate with him, it can reboot the AP.
Reply
#5
OK, I waited up till 3 AM and put 4.8.8806 on 'West' (WAR1B 2.4Ghz) and rebooted. This would be the AP that 'fubars' most often - typically several times per day running 4.7.1.0 - although sometimes it'll run for 2 days, and then sometimes it'll 'fubar' every couple hours all night long.

In any event, with 4.8.8806, all 21 clients re-associated (WAR1B, WAR1A-SIAM and a couple old WAR1-MIPS). Testing quickly,
the performance with 4.7.1.0-8747 and 4.8.8806 seemed about same. That's not a very thorough or comprehensive test however - that's just a quick 'feels about the same' after throughput testing to about half the clients.

I've also sent an email about doing a longer test - but in the short testing I did, I didn't see any deal breakers.
Reply
#6
Thanks ninedd. Great feedback with respect to throughput.

I'm working on the APU version right now. Funny how it was always the easiest to develop on but now simply refuses to work with the driver. Such is life.
Reply
#7
We have only one APU left in the field, but it is in a place where it does something strange about once per day more or less with 4.4.5.6 or 4.7.1.0 on it. Again, we have it pinging one of it's clients (which isn't a good solution - but better than going to 0 clients without anyone noticing/reporting) and so we mostly know it is acting up because it reboots itself and the uptime resets when it does that. It's uptime is "1 Day, 12 Hours" right now.

So - that would be a place to test on the APU that we should be able to tell. It's uptime is often < 1 day, so it reboots about that often. If we can put a 4.8 on there and have it run for a week (without it going to 0 client, or without the throughput droppign to nearly nothing, or without the client signals all goign to -80 or -90, or without the latency all going to 600 ms for everyone) then we will know that's a different & better result.
Reply
#8
lonnie Wrote:Thanks ninedd. Great feedback with respect to throughput.
Yes, of course as I mentioned in our emails, I can't really really test the exact same setting that we've been using until some of those missing features are fleshed out. I can't really know how 4.8.x would perform set exactly how we have 4.7.x set now until we have a 4.8.x with those things added in and we can run it for a week and see.

But, this encouraging yes. Actually 4.7.1.0-8747 was encouraging vs 4.4.5.6 too - we see a drop in ping times across the board on an AP upgrade to 4.7.x and it solved the 'missing first ping' issue that WAR1B's had since the beginning of WAR1B time. And some of the fubar's seemed to go away - so systems that were doing it 10 per day dropped to 2 times per day maybe. Still 2 too many, but better than 10 too many. Smile

So, hopefully we will see a 4.8.x with those missing features filled in, and hopefully that will be the magic bullet for the WAR1B and we can move forward.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)