Mainly 4.6.1 with pretty much issues on a mix of 3000 and 3000L. For our solar sites the uptime is over a year. Upgraded some to 4.7.0.1 5 months prior and they’re all still running.
80MHz channels are only a dream for us though.
Mainly 4.6.1 with pretty much issues on a mix of 3000 and 3000L. For our solar sites the uptime is over a year. Upgraded some to 4.7.0.1 5 months prior and they’re all still running.
80MHz channels are only a dream for us though.
Hello everyone,
this thread looks very exciting! Real feedback is priceless. Especially positive. As usually when everything is fine nobody notifies his vendor.
4.7.1-RC18 is published. There are stability improvements. New features, No issues were reported so far.
We constantly run stability tests. But we can not fully replicate real production environment with air instability or other glitches. I will really appreciate if you can try it and report some stability issue if it is there. Just download a techsupport and PM it to me.
Thank you!
Hi Andrii,
I’m 4.6.2 on every AP accept one 3000L, due to that html issue I let you know about.
The 3000L has always been a crasher/self rebooter and this continues under 4.7.0.1. I will send you some files.
Once the gui html issue is sorted i’ll upgrade some 3k to 4.7.1rc13 and report back.
Cheers
Thanks Jacob. Regarding the 3000 with 124 days - what firmware version is it running and how many subscribers does it have?
Andrii, to confirm - it’s only one 3000L that has issues. My other 3000Ls are pretty good.
Then the 3000’s of course, which I will report back on once upgraded to 4.7.1tc13- I need the gui thig fixed first, which might be my old mac laptop as i’m not seeing others with gui issues. Will send you some screenshots etc.
Thanks
Firmware 4.7.0.1 is buggy. It works sensibly both on 3000 4x4 and 3000L base stations and on AC/N SMs with firmware 4.7.1-RC18. We have noticed an improvement in SM performance in the “n” standard (40 MHz). The GUI on 4.7.1-RC18 is ok in a web browser on a computer (Safari macOS) or mobile browser (iOS). SMs connect to the base faster. When you change the frequency (channel) of the base station, the AC terminals do not disconnect and change the channel on the fly. Cool.
UTP cables do not matter whether they are category 5e or 6. It is enough if they are of good quality (necessarily copper) and external (resistant to UV and high/low temperatures). We use VLAN’s on the AP or SM’s, we enable and use SNMP for monitoring, we use cnMaestro cloud. We use sync and at all sites we use a TDD fixed ratio of 75/25. We not use IPv6. We use PPPoE (via BRAS) in the network, we do not use Cambium MIR. QoS bandwidth cutting for users on SMs is performed by the BRAS server for the entire network. With over 80 base stations, one 3000L sector restarts sporadically (software 4.7.0.1 is still broken, we are in the process of changing the entire network to 4.7.1-RC18). At base stations, we cut off traffic between devices on network switches. Traffic only goes “up” the network to the Internet and back. On a tower with e.g. 6 x AP, the movement between them is cut off. This prevents any unnecessary broadcasts or storm traffic on the network.
Update:
They all still crash eventually. The other day one of my e3k completely stopped broadcasting from 11pm until it eventually crashed at 6am. There are 35 customers on this radio. The fact it eventually crashed is great, as it self rebooted and came back to life.
My point is, they all eventually crash and burn.
I am always torn between loving and hating these radios. I love their awesome performance and how I can see exactly what packets are making it at what modulation rate, and that I can control that, and the problems I have with reliability.
I would rather have the epmp range than any ubiquiti or mimosa any day, but I just wish they were more reliable.
Mainly 4.6.1 with pretty much issues on a mix of 3000 and 3000L. For our solar sites the uptime is over a year. Upgraded some to 4.7.0.1 5 months prior and they’re all still running.
To this day my APs still crash eventually. The only ones that don’t are ones with less than 10 subscribers. I have a single E3k with over 100 days up, but all my E3ks with over 25 subscribers always crash/reboot before 100 days.
I’m hoping 5.8 might fix this but I can’t run it - I do not enjoy a 4db drop in UL RSSI for every SM!! There’s the beamforming bonus gone.
I would not run the 5.x release train on e3k AP’s and their SM’s. Stick to the 4.x release train. 5.x is really only intended for those wanting to migrate their e3k AC SM’s to e4k AP’s.
Really? OK. How about the SMs? I usually run 4.6.2 on everything ek3 + f300
Cheers
Correction: I just realised the beam forming 3db bonus is only in the DL too.
Stick to the 4.x release train for all AC and N radios. The only time you’d want to use 5.x is for AC SM’s that you’re migrating to e4k AP’s.
ive been seeing good results with 5.8 on f300-25 eptp links. They usually god bad after a few weeks or less with MCS 0 and only 5Mbps capacity, until a reboot - so annoying. Anyway, 5.8 has been stable for a few weeks so might be good for these too.
Were those links previously running 4.8.1? Because at its core, all the improvements for AC radios in 5.x are from 4.8.1.
Nah man all 4.6.2. I run the whole network on 4.6.2 accept a single eptp link that runs some rc of 4.7.1 - i do this because it can run for almost 100 days before crash/reboot. Good to know though about 4.8.1 - is that what you run your E3k’s and F300’s on?
We use 4.8.1 on all N and AC radios.
Good to know thanks.
Hey what would you run on a eptp link of f425 to f400c? One link I run 5.6rc9 because its the only fw that wouldn’t drop all the time - i reboot it weekly and usually lasts a week. The other is a failover for a siklu link and ive been testing 5.8 - it drops every two days and there’s no interference. What do you run on F400 to F400?
Cheers