Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.8.8878
#31
pti-andy Wrote:I never have seen this performance degradation issue with current V4 software but then again it is only because I only run V4 at 5GHz and any of my 2.4 and 900 installs are using old V3 software.

We ONLY see this on WAR1B's and on our APU. My question again is - IF ''the driver'' code is the same between the different hardware's (if the driver in an ALIX, x86-PC, Laguna, XScale, WAR1A-SIAM is the same as the driver in a WAR1B and APU) and IF the problem that we are reporting only shows up on just the WAR1B and APU version's, then can it possibly be something OTHER than ''the driver''. Can it be something in the base ''linux'' or in some Memory BUS or something?

We can run 4.4.5.6 or 4.7.x or 4.8.x on a LAGUNA or ALIX (and 4.4.5.6 will reset/puke/fubar 50+ times per day on a WAR1B Access Point or CPE - maybe that's partly the ''reset bandaid code'' I don't know) but as far as I know, that same version will run for 50+ days on any other hardware plopped in place of a WAR1B.

Quote:Sorry for the long post but I thought it was important even if this is old news.
For me - I appreciate ANY reports from anyone... so thank you Andy. Smile

We are desperate to figure this out and fix it. We sit and watch every WAR1B AP from as soon as we get home from work, till about 2 AM every single day, and then all day long every weekend - and we have to manually reset them a half a dozen times every night. THIS IS CRAZY and it's driving us all crazy. And it's been TWO YEARS since there has been a working product. And I'm not even 100% sure that you are even working on the same issue or not? Not sure if you've actually been able to duplicate what we're seeing or not?
Reply
#32
I have long suspected a memory leak or a data locking issue, and if you recall the first "fixes" I did concentrated on those issues and improved things but did not eliminate the issues.

For the last 3 days I have been attempting to update the kernel on the APU. The reason it was chosen is because this process tends to ruin the image and it is quite simple to copy the SD card and try again.

WELLLLLLLLL ... tonight I got it working. I have bumped the kernel up from 3.10.58 to 3.10.105 and it seems a lot more stable. I have started a throughput test (no stress added yet) and we'll see if it is still running in the morning. 3.10.58 is quite old and 3.10.105 is the latest available in the long term support for the 3.10 series.

Now that I know how to do the kernel transplant, I will try and update to 3.16.42, which is the very latest and last of the 3 series long term support. My intention is to get all the systems using 3.16.42 because it makes it very hard to keep track of the various versions and the issues affecting them. It will make my job easier if they are all the same kernel version and driver version, etc.
Reply
#33
Sounds like great news on the new kernel.

I was unaware that the main issue was just pertaining to the WAR1B. I thought the degrading signal/performance was global to all hardware. I guess I should read more carefully. If the lockup problem on the WAR1B is happening only after the signal degradation then it appears to be two different issues, one leading to the other.

For me the issue has been that any version after 4.2.3 will randomly reset itself on the Laguna platform. I would be fine with 4.2.3 or even 4.1.12 but neither will support extended or licensed frequencies. Even those frequencies in the 5.25GHz (U-NII-2 band) which are unlicensed are still not available. I have therefore held back upgrades of old Xscale V3 installations. If we could just add full frequency support to 4.1.12 (say 4.1.12a) it would hold me over until the issue can be fixed. It should be just a matter of updating the correct or allowed frequency list based on the license so that ## will work again or just add 5.25-5.35GHz back to the US band. I could then proceed with upgrading my sites. This would give a fully working V4 for us 5GHz users.

By the way, I realize that many of us have been struggling with some issues for some years now but I encourage everyone to hang in there. There are numerous benefits to StarOS and the flexibility of this platform with various hardware allow for an unmatched level of control at a very reasonable price point. It appears that a solution to some of the specific issues is around the corner so I'm looking forward to the future releases. If a bandaid will buy us time then I welcome that as well. This really is a great platform.
-Andy
PTI Wireless
Reply
#34
The issue affects all platforms, not simply the war1b. The interesting thing is that the kernels all changed after the 4.2 series. So now I am focused on the kernel. The driver has been brought up to the very latest and although it is better, again, like my previous fixes, does not eliminate the root problem of the AP stall.

When I'm done we'll have the newest kernel in the series along with the newest driver. We'll see.

I have begun to work on getting 3.16.42 into the APU firmware.

pti-andy Wrote:Sounds like great news on the new kernel.

I was unaware that the main issue was just pertaining to the WAR1B. I thought the degrading signal/performance was global to all hardware. I guess I should read more carefully. If the lockup problem on the WAR1B is happening only after the signal degradation then it appears to be two different issues, one leading to the other.

For me the issue has been that any version after 4.2.3 will randomly reset itself on the Laguna platform. I would be fine with 4.2.3 or even 4.1.12 but neither will support extended or licensed frequencies. Even those frequencies in the 5.25GHz (U-NII-2 band) which are unlicensed are still not available. I have therefore held back upgrades of old Xscale V3 installations. If we could just add full frequency support to 4.1.12 (say 4.1.12a) it would hold me over until the issue can be fixed. It should be just a matter of updating the correct or allowed frequency list based on the license so that ## will work again or just add 5.25-5.35GHz back to the US band. I could then proceed with upgrading my sites. This would give a fully working V4 for us 5GHz users.

By the way, I realize that many of us have been struggling with some issues for some years now but I encourage everyone to hang in there. There are numerous benefits to StarOS and the flexibility of this platform with various hardware allow for an unmatched level of control at a very reasonable price point. It appears that a solution to some of the specific issues is around the corner so I'm looking forward to the future releases. If a bandaid will buy us time then I welcome that as well. This really is a great platform.
Reply
#35
lonnie Wrote:The issue affects all platforms, not simply the war1b.
Are we certain that we are even talking about the same issue? I'm not saying that as any type of 'dig' - but I'm honestly not certain that we are even really talking about the same issue.
Reply
#36
I admit there is a slim chance it is NOT the same, BUT, at the same time it is the ONLY thing I can duplicate and it certainly seems to match the symptoms you have described.

I have been able to get 3.16.42 running but there are data issues in the GUI. Something in a data structure does not match between the kernel and gui.

ninedd Wrote:Are we certain that we are even talking about the same issue?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)