@cmr I think your onto something here, but I suppose its so be expected with a new firmware train.
I have a laptop with an AX200 (21.70.0.6) on an MR45 with 27.1, on 20MHz on channel 100 (no other networks on this frequency), no other clients on this AP, and I'm about 10 feet away from the AP.
I am getting the following on 27.1:
Reply from 172.31.0.1: bytes=32 time=21ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=29ms TTL=64
Reply from 172.31.0.1: bytes=32 time=16ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=14ms TTL=64
Reply from 172.31.0.1: bytes=32 time=15ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=24ms TTL=64
Reply from 172.31.0.1: bytes=32 time=16ms TTL=64
Reply from 172.31.0.1: bytes=32 time=20ms TTL=64
Reply from 172.31.0.1: bytes=32 time=13ms TTL=64
Reply from 172.31.0.1: bytes=32 time=16ms TTL=64
Reply from 172.31.0.1: bytes=32 time=14ms TTL=64
Reply from 172.31.0.1: bytes=32 time=19ms TTL=64
Reply from 172.31.0.1: bytes=32 time=25ms TTL=64
Reply from 172.31.0.1: bytes=32 time=16ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=17ms TTL=64
Reply from 172.31.0.1: bytes=32 time=24ms TTL=64
Reply from 172.31.0.1: bytes=32 time=18ms TTL=64
Reply from 172.31.0.1: bytes=32 time=18ms TTL=64
Reply from 172.31.0.1: bytes=32 time=12ms TTL=64
Downgraded firmware to 26.8, and things look much better:
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=6ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=6ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=1ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=3ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Reply from 172.31.0.1: bytes=32 time=2ms TTL=64
Adding @MerakiDave so he can run this up the flag pole. I was able to reproduce the issue (not as severe as @cmr example, but still easily noticeable) within 10 minutes of testing.