Hi @Morris211 

Thanks for posting in our business forum.

Morris211 wrote

the combined bandwidth usage doesn't even come close to 50% of the available bandwidth. I'd imagine the speed should only slow down if the bandwidth was used at 100% utilization.

Without a controller, you can even get Internet and they still run. But not for the mesh. Config has been deployed to them. So they can run without a controller. It is not a problem with the controller. That's the conclusion.

  @Morris211 

I am not sure how Clive determined you were using the wireless mesh capability, however that could impact the backhaul performance to your internet (and cause a lot of those packet retries).  Also if you have fast roaming turned on, that could add load on the controller CPU and impact performance in the field.  Given the 45 APs, the OC300 is more appropriately sized for your network.

I think a simple test would be to temporarily disconnect the controller (pull ethernet plug), and see if anything changes.  I doubt it will.  You can then plug it back in and things should continue as before (no outage).

You can also probably improve things a bit through some RF optimization...ie check your 2.4G channels (and I recommend fixing them to only 1,6, or 11 and 20Mhz only) and output powers via a site survey to ensure they aren't competing with each other (excess overlap in coverage).  If you are using a mesh, then minimize the number hops and neighbours (I recommend <=2 for both) and maximize the number of wired root APs.

Hi @d0ugmac1

d0ugmac1 wrote

  @Morris211 

 

I am not sure how Clive determined you were using the wireless mesh capability, however that could impact the backhaul performance to your internet (and cause a lot of those packet retries).  Also if you have fast roaming turned on, that could add load on the controller CPU and impact performance in the field.  Given the 45 APs, the OC300 is more appropriately sized for your network.

 

I think a simple test would be to temporarily disconnect the controller (pull ethernet plug), and see if anything changes.  I doubt it will.  You can then plug it back in and things should continue as before (no outage).

 

You can also probably improve things a bit through some RF optimization...ie check your 2.4G channels (and I recommend fixing them to only 1,6, or 11 and 20Mhz only) and output powers via a site survey to ensure they aren't competing with each other (excess overlap in coverage).  If you are using a mesh, then minimize the number hops and neighbours (I recommend <=2 for both) and maximize the number of wired root APs.

Morris is using outdoor EAP. (Picture). So, that's my guess and asked him.

The controller would not affect the performance of the Internet speed, ping, or latency.

Ha!  I'd just ignored the "red"-acted area.  Hats off to you Clive :)

Almost certainly the poor performance is due to poor mesh topology. 

Can you provide the 'Topology' generated by the Controller and also the ratio of root AP to meshed APs?

Hi @Morris211 

Thanks for posting in our business forum.

Morris211 wrote

  @Clive_A I just figured out what caused it. it's called "Bufferbloat". unfortunately, TP Link did not have a solution for this problem. I solved it the bufferbloat using smart queue management by openWRT and the lag went away like magic. but using openWRT router, it effectively remove the reason why I use Omada router in the first place.

SQM (Smart queue management) was available on Ubiquiti, PFsense, Tomato Routers and OpenWRT but not on TP Link Omada.

Good to know. QoS was added several versions ago. QoS is about the Internet access outbound. I don't know if you have configured that on the Omada to see if this can be improved. We don't support SQM yet. You can vote for this feature.

The original question was mainly about whether the Omada Controller is capable of carrying the adopted devices. Well, this has nothing to do with your Omada WIFI/router/switch. Thus, there is no need to add any better or more powerful controller.