Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Version 4.8.0.0.9071
#1
https://cp.sync.com/dl/4bd9ff300#5imn6u3...r-rfcrd8vi

Please test on an easy to access system and make sure it is stable for your situation before deploying too many. The firmware has been stress tested for general function and throughput 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.

Fixed Ventana not seeing second Ethernet. Note that this fix most likely will change your device ordering so please check your wifi devices for proper configuration. This build 9089 has replaced the 9074.

Main Features of the 4.8.0.0.9074 Release Replaced previous 9071
- FULL Licensed Frequency support. Fixed ## for 5.x GHz
- FULL Bridging support.
- FULL Hidden ESSID.
- COMPLETE Full Duplex.
- NO Basic SYNC support.
- FULL OLSR support.
- fixed site survey so that all platforms now function.
- make sure you do NOT use u-APSD on the clients
- PLEASE give this a test in a spot that has problems.

I have done a FTP transfer of a 18 GB file multiple times with NO APP STALL. It sometimes slows down, but it picks right up. NOTE: I am testing with 30+ units that can be seen on a site survey and 16 are on 2412 which is what I am testing on. 3 of the units are seen by the client with higher signals than the AP it is talking to.

The following versions have been added and tested
- WAR-1B
- Ventana
- Laguna
- x86-APU
- Avila (Gateworks xscale war 4)

The following versions have been added but NOT tested (I Have no test hardware in working condition)
-wp188 (Compex xscale)
- x86- Alix
Reply
#2
Note to ryan, regarding the lack of ## on 5 GHz in the last release: If you choose a frequency that is DFS it will have the normal quiet timeout of up to a minute and if you do not wait you will think it is not working.
Reply
#3
Also the last release I had to reset AP on my ptp link which I have not had to do on any older versions on this ptp link. reset ap and link came back up. The link was still associated just no traffic passing until reset. FYI Not sure what issue was. could of been bridging issue possibly not sure.
Reply
#4
I tested dfs and licensed channels tonight and neither works. I waited for around 3 minutes on each channel before trying a different one. Within log some channels showed dfs scan time 0 seconds some showed 60 seconds. Waited and logs do not show anything else. Old versions showed something like radar detected changing channel etc... It still looks like no workie yet. Also old version you could put on licensed channel and pick a dfs channel for testing and it would just work. Looks like new version does not do this?? Can you test this more cause I cant get radio to do anything other than just saying initializing
Reply
#5
My apologies. It seems I missed a vital patch from the older driver. I have applied it and now the full 5 GHz band works with ##.

I am generating a new release and will take a walk and vote in our Provincial Election. Hopefully by the time I return it will be ready for testing. Expect a new release later this afternoon or early evening.
Reply
#6
Build 9074 has been built, tested and released. It fixes the ## for 5.x GHz.
Reply
#7
This new version does work as before with the ##. Tks. I also noticed that clients can be in na10 mode and ap is na40+ and they will still associated which is kind of nice if you forget changing both ends when tweaking on link. FYI.. I also notice that I get about the same throughput on na10 channel as I do on a 40mhz wide channel on my point to point 16 mile link. Around 50meg/50meg using war1b on each end 3foot dishes. Signals are around -52 or so both ends. I find this kind of weird. I will report back on stability over next few weeks. The previous version I have a few lock ups every week or so. Hopefully this version no more!!
Reply
#8
Thanks Ryan. Good info.

The na10 is NOT supported so it will be using whatever the AP is using, BUT, it reports what you have set for. Once things settle down I will try and get that user interface to show the actual linked info. FYI, a client will search both 2.4 GHz and 5.x GHz for an AP to connect with. It does mean an easier setup but that is balanced by a longer connection process as it scans way more channels.

I also hope it is more stable. It has fixed more than a few issues and is way more stable than before. ninedd has confirmed that his issue is still there, so I know I have work to do yet and that is ongoing.


Ryan Wrote:This new version does work as before with the ##. Tks. I also noticed that clients can be in na10 mode and ap is na40+ and they will still associated which is kind of nice if you forget changing both ends when tweaking on link. FYI.. I also notice that I get about the same throughput on na10 channel as I do on a 40mhz wide channel on my point to point 16 mile link. Around 50meg/50meg using war1b on each end 3foot dishes. Signals are around -52 or so both ends. I find this kind of weird. I will report back on stability over next few weeks. The previous version I have a few lock ups every week or so. Hopefully this version no more!!
Reply
#9
13 days an no lockup so far and i am hammering link all day 30+ meg across 16 or so mile ptp link. I have noticed that as you said this version does not work on na10 as i tried to load a new client radio with this version and it would not connect to my na10 ap running 4.4.5.5. I am sure u know this though. So i cant use it at scale yet due to this.
Reply
#10
Ryan,

Can you explain how many sites are using the 5 or 10 MHz channels? Are you doing it to save spectrum or because the sites do not need the full throughput?

After spending a LOT of time going over the driver code and testing, I can say that the total throughput of 2 separate units on the same channel will be about the same as 1 single unit, or 2 units running 10 MHz channels. The 5 & 10 MHz channels work their magic by reducing the rate, and unfortunately the result of that is increased air time. It is my belief that you will be better of by having both units at the normal width because it gives a higher rate and thus allows more time for other units to get their data through. Note you might need to use some bandwidth control to avoid a data hog.

I'm wondering if you can do some testing and confirm this in the real world, rather than my limited network. Note that most of my testing is done at 2412 MHz (channel 1). I see in excess of 30 other Access Points and several have signals higher than my own AP. There is really very little 5 GHz competition so I really never see the 5Ghz units slow down.

I believe the situation has changed with the 802.11n chips because they are MUCH better with noise handling, and have way higher rates so they will get their packet sent in the least amount of air time. Please try it out. Maybe you can simply your networks with all units at 20 MHz channels.
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  GeckoClean - Current version v1.10 tony 3 1,857 05-15-2013, 08:10 PM
Last Post: tony

Forum Jump:


Users browsing this thread: 1 Guest(s)