Latency testing under "heavy traffic" isn't ideal.= =C2=A0 If the input rate=C2=A0exceeds the service rate of any queue for = any period of time the queue fills up and latency hits a worst case per=C2=A0that queue depth.=C2=A0 I'd say take latency measurement= s when the input rates are below the service rates. The measurements when service rates are less than input rates are less about=C2=A0latency and more about bloat.

Also, a good paper is this one on trading bandwidth for ultr= a low latency using phantom queues and ECN.

Another thing to consider is that network engineers=C2=A0tend to = have a mioptic view of latency.=C2=A0 The queueing or delay between th= e socket writes/reads and network stack matters too.=C2=A0 Network engineers focus on packets or TCP RTTs and somewhat overlook a user's true end to end experience.=C2=A0 Avoiding bloat by slowin= g down the writes, e.g. ECN or different scheduling, still contributes to end/end latency between the writes() and the reads() that too few test for and monitor.

Note: We're moving to trip times of writes to reads (or frames for video) for our testing. We are also replacing/supplementing=C2=A0pings with TCP connects as other "latency related" measurements. TCP connects are more important than ping.

Bob

On Fri, May 15, 2020 at 8:2= 0 AM Tim Higgins <tim@smallnetbuilder.com> wrote:

=
Hi Bob,

Thanks for your comments and feedback. Responses below:

On 5/14/2020 5:42 PM, Bob McMahon wrote:

Also, forgot to mention, for latency don't= rely on average as most don't care about that.=C2=A0 Mayb= e use the upper 3 stdev, i.e. the 99.97% point.=C2=A0 Our latency runs will repeat 20 seconds worth of packets and find that then calculate CDFs of this point in the tail across hundreds=C2=A0of runs under different conditions. = One "slow packet" is all that it takes to screw up user experience when it comes to latency.=C2=A0

On Thu, May 14, 202= 0 at 2:38 PM Bob McMahon <bob.mcmaho= n@broadcom.com> wrote:

I haven't looked closely at OFDMA but these latency numbers seem way too high for it to matter.=C2=A0 Why is the latency so high?=C2=A0 It su= ggests there may be queueing delay (bloat) unrelated to media access.

Also, one aspect is that OFDMA is replacing EDCA with AP scheduling per trigger frame.=C2=A0 EDCA kind= a sucks per listen before talk which is about 100 microseconds on average which has to be paid even when no energy detect.=C2=A0 This limits the transmit= s per second performance to 10K (1/0.0001.). Also remember that WiFi aggregates so transmissions have multiple packets and long=C2=A0transmits will consume= those 10K tx ops. One way to get around aggregation is to use voice (VO) access class which many devices won't aggregate (mileage will vary.). Then take a packets per second measurement=C2=A0with small packet= s.=C2=A0 This would give an idea on the frame scheduling being AP based vs EDCA.=C2=A0=C2=A0

Also, measuring ping time as a proxy for latency isn't ideal. Better to measure trip times of the actual traffic.=C2=A0 This requires clock sync to a common reference. GPS atomic clocks are available but it does take some setup work.

I haven't thought about RU optimizations and that testing so can't really comment there.=C2=A0

Also, I'd consider replacing the mechanical turn table=C2=A0with variable phase shifters and set them = in the MIMO (or H-Matrix) path.=C2=A0 I use model 84= 21 from Aeroflex. Others make them too.