How accurrate is ePMP 4k DL Frame time%

I have been monitoring my 4k APs and doing peformance testing with both single/multi SM link tests along with running mtik bandwidth tests from customer routers behind the SMs and I have had a hard if not impossible time getting DL frame time % as reported by the AP Performance section to cross around ~60%.

I have tried on both MU-MIMO APs and just beamforming APs. No matter what I cannot seem to get above 60% DL Frametime reported in the GUI.

One example is at 4500AP. 40mhz 75/25 TDD. I did a 4 SM link test while other normal customer traffic was running. I got around 90% of the link test was MU-MIMO and AP did around 830Mbps DL which I would assume is pretty close to max but while watching the AP DL frame time in the GUI it only got to ~60%.

Other tests were on 27 client MU-MIMO AP and 19 client beamforming AP. No matter how much bandwidth I push and how much I try to tax the AP reported DL frametime is only at most 60% (the 27 client 4600 MU-MIMO AP had fluctuating frametime % during the tests). I have a hard time believing that tests are unable to ‘max’ out the AP.

I have been graphing and using DL Frametime % to get an idea on when an AP is getting near max like I did with AirmaxAC and monitoring Airtime %. On AirmaxAC if flex framing I knew that around 80% airtime the AP was near max and on TDD it would be near max if the Airtime was close to the DL split. So if running 66/33 split the AP max would be when the AP was near 60% Airtime usage.

So I believe I was told that for ePMP the frame time % is always out of 100% and it does not change based on your TDD mode or frame split. However in my tests so far it seems ~60% is max instead of 100%.

So when during peak I see some 4k APs showing ~40% DL Frametime am I to then assume the AP is really running at around 66% of DL capacity (40/60=66), or is there either something wrong with the reported metric or my understanding of it?

1 Like

Just did some testing on a 27 client 4600 AP and I have two customers mtik routers doing TCP bandwidth tests to the tower router. Regular AP usage from other clients was around 80-100Mbps.

Total AP usage with these tests running was around 460Mbps DL with 0Mbps of that being MU-MIMO. AP was around 55% DL Frametime %.

I then did a single SM link test and then a dual SM link test to SMs that should trigger MU-MIMO. Got 672Mbps DL total with 480Mbps of that being MU-MIMO. Dual SM test with the Mtiks running was 701Mbps total DL with 563Mbps being MU-MIMO.

I then tried to fully max out the AP by doing a 4SM link test while 2 other SMs were running Mtik TCP bandwidth tests along with the regular customer traffic. I got 817Mbps DL with 780Mbps of that being MU-MIMO.

During all the above tests AP DL Frametime % never exceeded ~55-60%. Also during the 4 SM link tests with 2 SM running Mtik bandwidth tests and other regular client traffic also running the 2 Mtik bandwidth tests dropped to near 0 during the 4SM link test. Not sure if that means the AP was maxed out during the test or if that means something else.

There is much strangeness around e4k’s initial MU-MIMO implementation. As I’ve mentioned in other posts, dev’s are working hard to improve MU-MIMO performance and reporting in the upcoming 5.11 firmware.

1 Like

Thing is I see this same 60% frame time limitations on beamforming only APs as well.

I do stand corrected somewhat. On a 4600 AP w/19 clients and beamforming only I was able to push the AP to 680Mbps and a reported 80% DL frametime usage. However, no matter how much I tried I could not get it over 80%.

Does that mean with 75/25 TDD the expected max frametime you can get is around 75-80%, and right now with the current ‘unoptimized’ MU-MIMO the best is around 60%?

Also I notice quite the lag between what the GUI reported and what I expect is the actual frametime usage. This would make the 20s link tests probably not really show the max frametime in the GUI due to this lag. I would say the GUI is around 13-20s behind. Checking DL frametime via SNMP and it was around 9-13s behind.