Wednesday, 9 Nov, 2022  |    Leave a comment

Howdy,

just wanted to share which "aggregation" value worked on one of my WLAN APs in my old home lab.

FWIW, the AP I was using at the time was an old UBNT NanoStation Loco M2 (2.4Ghz) setup as a Bridge:

image

On my real world “testing” scenarios, aggregating 3 ETH Frames/4500 bytes gave me the best compromise between acceptable performance, sufficient bandwidth and sustainable latencies.

My real world “testing” included playing music on 2 WLAN stations from a DFS Share while transferring an Ubuntu iso from one side of the bridge to the other.

Connecting 2 disjoint subnets (through a 3rd, wireless-one) has its disadvantages, namely, the lack of Jumbo frames.

My crazy idea was to use 802.11 aggregation as "a means to transport large Ethernet frames from one side of the bridge to the other", ‘though that “can’t be done” because, despite the fact that you can increase the LAN & WLAN Interfaces’ MTU to 2024 bytes, the bridge interface is still limited to 1500 bytes.

For further reading, please refer to:

http://community.ubnt.com/t5/airOS-Software-Configuration/airMax-aggregation-priority/td-p/264579

 

I am sharing the above because I experienced something similar to the issue hereby described:

http://serverfault.com/questions/51891/unexplained-slow-gigabit-network-speeds

That issue described above has been haunting and plaguing me in the past years (I've since moved equipment to newer Ubiquity Wireless Access Point).

What's interesting is that when I transferred files from within an RDP session, everything worked Okay while transferring data directly (ie. from the shared folders), it misbehaved as described @ serverfault.

Glad I was finally able to figure it out after so much testing.

Rate this post

Ask me anything