Quick question about throughput on my Meraki wireless.... My network runs all MR52 access points and I've been trying to get some better throughput when I run speed tests. My test MR52 is running a CAT6 cable directly into a switch. We just installed a 1Gb Internet EDIA circuit. If I speed test with a laptop on the wired port, I get a download of around 800Mb down and 780Mb up from Speedtest.net If I speed test with the same laptop on a wireless connection to an MR52 I top out at about 120Mb up and down. The wireless network I'm connecting to is 5Ghz only with nobody else on it. I've whitelisted my laptop and there is no shaping being done. The MR52 is showing a 1Gb connection to the switch. Testing the throughput in the in the Meraki control panel shows me about 75Mb (down?).
I know there should be some loss when running speed tests but the numbers I'm seeing seem kinda extreme. I would expect to see at least 300 to 500 down. I've even tried running tests from Speedtest.net and my provider (thinking the shortest hop would be just off my network) with different devices and I still can't get any speed from it. I ran these tests using a test AP and test wifi network but even in my production environment I'm seeing the same 100 to 120Mb barrier on the speed test and about 300Mb test from the Meraki control panel on MR52 AP's with 2Gb uplinks.
Solved! Go to Solution.
@NolanHerring is right.
So is @kYutobi with regard to increasing the channel width - providing that their is actually enough spare RF spectrum to support channels this wide. I have clients operating in central city areas and because of the amount of WiFi being used by other near by businesses it just isn't possible to use 80Mhz wide channels (in fact, we use 20Mhz wide channels to make it reliable rather than fast).
Also note that if you increase to (say) 40Mhz wide channels (as a compromise) and your clients start connecting at 40Mhz instead of 20Mhz that you might only be able to sustain half the number of clients per AP that you could before. Only really an issue in a dense environment but something to keep in mind.
Also you need to give some consideration to your client being used (as hinted to by @NolanHerring ). If you want high performance get yourself a WiFi client that is 3x3. Note that most WiFi clients are 2x2 because manufacturers are more concerned with longer battery life than higher throughput.
And of course the other thing you can do is to increase your AP density ...
Thanks Nolan... I did try moving to the 80Mhz range (as kYutobi suggested) as a test with some increase in speed... Not practical in production though...
I work at college and we're supposed to get an onslaught of about 80 high school kids this weekend so I'm trying to setup to handle 80 kids with multiple devices doing all kinds of things...
My 2 cents,
No wireless AP will ever perform at its advertised speeds, refer to this as more of a capability, rather than a reality.
Agree with other comments that your speed seems about right, and considering its not Wifi6.
In regards to the onslaught of kids, we generally try to budget each AP to have a max of around 6-8 clients, any more performance is lost. Within a hospital environment, with all our testing, we always got best results to leaving everything on Auto. We did play around with channel widths and NX settings, but as scenarios changed so did the settings.
I would consider reducing bandwidth for the clients during the onslaught, but regardless wireless clients will still have to fight for airtime communication (another reason wifi6 will be heaps better - more clients)
Also we found reducing our SSIDs to noore than 4 made a substantial performance difference including not broadcasting on DFS channels.
Using the floor plan view to see an overview of what each channel the APs are operating on is very helpful, it can show you any potential channel crossings from neighbouring APs and gives you the opportunity to adjust accordingly. In fact I read somewhere that positioning your APs on the floor plan view actually help the APs automatically assign channel numbers to ensure no cross over.
We also increased the minimum bit rate, this stopped older clients from connecting from old protocols, enabling more airtime and quality of service, also ensuring band steering is enabled.
Cheers and good luck