Optimize AMPDU aggregation; tested and results

[thetechhimself]

I hate to do this, but see my original thread https://www.dpreview.com/forums/post/67814341 as apparently, SBNForums, don't support threads over 10K characters, which mine exceed 14K... Lemme try to cut this in half though... Reposting here as although I'm a DPR regular, I am an infrequent over here, and the discussion is much more appropriate for SNB...

Part 1

Hypothesis: Enabling AMPDU optimization may improve network efficiency with a majority of AC-enabled (of interest) clients present in my network

Background:

Router: Asus GT-AX6000 running 3.0.0.6_102, centrally located in low-voltage closet downstairs

ISP: AT&T Fiber 1GB offering, AT&T Router-Gateway plugged into 2.5GB port on Asus in bridge mode with 2.5GB NIC (CAT6 Cable) on Asus allocated to WAN (permits above 1GB data, otherwise utilizing default WAN port on GT-AX6000 results in 1GB "cap")

Synology NAS DS224+ running DSM 7.2.1 with Single NIC used (CAT6 cable) plugged into 1GB LAN port on Asus w/16GB RAM added; Dual Seagate 18TB EXOs in RAID1

WiFi Clients: 2 iPhone SEs (v3), 1 2019 15" MacBook Pro, 1 2020 iMac 20" aka "Atlantis", 1 Hades Canyon NUC (2x2 802.1AC capable) aka "Carolina Reaper", 2 TCL series 4 TVs (802.1AC dual-band capable), Apple Watch (2.4GHz), Neato BotVac D5, ADT smart panel, ADT smart doorbell (2.4GHz capable), Canon G620 Printer (2.4GHz)

Test Clients and Wireless Readings, from closest to farthest in physical proximity to router:

“iMac 2020” 2.4GHz

RSSI: -30 dBm

Tx Rate: 216 Mbps

“iMac 2020” 5GHz

RSSI:-49 dBm

Tx Rate: 1300 Mbps

…

“MacBook Pro in the Kitchen” 2.4GHz

RSSI: -30 dBm

Tx Rate: 216 Mbps

“MacBook Pro in the Kitchen” 5GHz

RSSI: -48 dBm

Tx Rate: 1170 Mbps

…

“Carolina Reaper” 2.4GHz

RSSI: -54 dBm

Tx Rate: 145 Mbps

“Carolina Reaper” 5GHz

RSSI: -65 dBm

Tx Rate: 468 Mbps

…

“MacBook Pro in Corner Rm” 2.4GHz

RSSI: -56 dBm

Tx Rate: 173 Mbps

“MacBook Pro in Corner Rm” 5GHz

RSSI: -68 dBm

Tx Rate: 390 Mbps

…

Testing Regimen:

iPerf3 installed via Docker on local Synology NAS DS224+ for local-iPerf3 performance benchmarks (not subject to WAN/ISP/distant-end variance)

Client based benchmarking shell script that leverages:

iPerf3 to measure bandwidth (TCP mode)and jitter (UDP mode) to Synology NAS iPerf3 Docker Container

Ping to measure local latency (Synology Virtual IP) and remote latency (CloudFlare IP ie 1.1.1.1)

Speedtest-CLI with hard-coding server number into script (broadcast/geocentric servers "rotate"; requires ensuring available server "up" or rotating hardcode server and re-running tests to keep results aligned between tests); remote bandwidth measurement

Script runs in 10x loop and aggregates and averages results to reduce sampling error rate

Repeat test on each band (2.4GHz, 5GHz) on all clients under test with AMPDU optimization enabled, and disabled within same timeframe to mitigate WAN/ISP/distant end loading variance (to mitigate time of day loading variance)

Observations:

1. When family was utilizing Media Server functions on my local Synology NAS (also running iPerf3 container for this benchmark), iPerf3 bandwidth benchmark impacted significantly (down 400Mbps from 780Mpbs in one instance) and local-latency impacted significantly (up ~100ms from >10ms). Had to re-run tests without Media Server on Synology in use for accurate results
2. Speedtest-CLI available / detected / broadcast servers "rotate". Ensure you utilize hardcoding a server number into the script with Speedtest-cli (can print via speedtest-cli --list) so that results to distant end are repeatable. 5 servers at a time are presented. Ensure you run same band and same client against same server with AMPDU optimization enabled, and then disabled for reliable results
3. 2.4GHz band testing caused significant disruption to my nearby wireless SNES classic 2.4 GHz controllers. Had to re-run tests when kids weren't playing to avoid frustrated children.
4. The wife running the microwave negatively impacted 2.4GHz results. Had to re-run 2.4GHz tests when she used it as I could see performance regression in real-time.
5. I had to personally supervise these tests even though they were-script driven so I got to see the results of each test as they came in, even though I'm presenting the 10x aggregated and averaged results, I discarded the tainted results but did observe them in real-time. From both the tainted and untainted data, I would say generally speaking there is a slight bandwidth improvement with AMPDU optimization enabled, and a slight latency increase when enabled which was expected on both fronts. However, 2.4GHz seems to experience significant increase in latency and jitter when enabled compared to 5GHz which only saw minimal latency performance hit in exchange for additional bandwidth.

Data Collected:

Device/Location: MacBook Pro Kitchen Band: 2.4GHz

AMPDU: Enabled

Throughput (Mbps): 131.13

Local Latency (ms): 9.37

Download Speed (Mbps): 139.38

Upload Speed (Mbps): 119.47

Internet Latency (ms): 15.18

Jitter (ms): 0.64

Device/Location: MacBook Pro Kitchen Band: 2.4GHz

AMPDU: Disabled

Throughput (Mbps): 137.74

Local Latency (ms): 9.53

Download Speed (Mbps): 133.30

Upload Speed (Mbps): 131.36

Internet Latency (ms): 20.15

Jitter (ms): 0.88

Device/Location: MacBook Pro Kitchen Band: 5GHz

AMPDU: Enabled

Throughput (Mbps): 699.45

Local Latency (ms): 8.32

Download Speed (Mbps): 380.25

Upload Speed (Mbps): 305.28

Internet Latency (ms): 14.21

Jitter (ms): 0.19

Device/Location: MacBook Pro Kitchen Band: 5GHz

AMPDU: Disabled

Throughput (Mbps): 702.13

Local Latency (ms): 7.27

Download Speed (Mbps): 63.35

Upload Speed (Mbps): 45.08

Internet Latency (ms): 14.73

Jitter (ms): 0.26

Device/Location: MacBook Pro Corner Rm Band: 2.4GHz

AMPDU: Enabled

Throughput (Mbps): 35.02

Local Latency (ms): 9.87

Download Speed (Mbps): 58.13

Upload Speed (Mbps): 94.66

Internet Latency (ms): 15.67

Jitter (ms): 1.44

Device/Location: MacBook Pro Corner Rm Band: 2.4GHz

AMPDU: Disabled

Throughput (Mbps): 32.00

Local Latency (ms): 10.45

Download Speed (Mbps): 45.34

Upload Speed (Mbps): 77.28

Internet Latency (ms): 14.87

Jitter (ms): 2.63

Device/Location: MacBook Pro Corner Rm Band: 5GHz

AMPDU: Enabled

Throughput (Mbps): 189.90

Local Latency (ms): 8.66

Download Speed (Mbps): 240.47

Upload Speed (Mbps): 130.47

Internet Latency (ms): 15.34

Jitter (ms): 0.48

Device/Location: MacBook Pro Corner Rm Band: 5GHz

AMPDU: Disabled

Throughput (Mbps): 179.28

Local Latency (ms): 8.47

Download Speed (Mbps): 215.62

Upload Speed (Mbps): 122.65

Internet Latency (ms): 14.96

Jitter (ms): 0.50

Device/Location: “Carolina Reaper” (Hades Canyon NUC w/BCM94360NG, 2x2 802.1AC) Band: 2.4GHz

AMPDU: Enabled

Throughput (Mbps): 42.44

Local Latency (ms): 6.45

Download Speed (Mbps): 38.26

Upload Speed (Mbps): 21.15

Internet Latency (ms): 11.63

Jitter (ms): 2.16

Device/Location: “Carolina Reaper” (Hades Canyon NUC w/BCM94360NG, 2x2 802.1AC) Band: 2.4GHz

AMPDU: Disabled

Throughput (Mbps): 29.02

Local Latency (ms): 4.03

Download Speed (Mbps): 39.95

Upload Speed (Mbps): 31.01

Internet Latency (ms): 13.91

Jitter (ms): 1.34

Device/Location: “Carolina Reaper” (Hades Canyon NUC w/BCM94360NG, 2x2 802.1AC) Band: 5GHz

AMPDU: Enabled

Throughput (Mbps): 258.74

Local Latency (ms): 3.96

Download Speed (Mbps): 219.92

Upload Speed (Mbps): 211.88

Internet Latency (ms): 10.05

Jitter (ms): 0.28

Device/Location: “Carolina Reaper” (Hades Canyon NUC w/BCM94360NG, 2x2 802.1AC) Band: 5GHz

AMPDU: Disabled

Throughput (Mbps): 280.34

Local Latency (ms): 3.73

Download Speed (Mbps): 231.19

Upload Speed (Mbps): 240.77

Internet Latency (ms): 10.03

Jitter (ms): 0.25

Device/Location: “Atlantis” (iMac 2020) Band: 2.4GHz

AMPDU: Enabled

Throughput (Mbps): 145.48

Local Latency (ms): 12.38

Download Speed (Mbps): 140.81

Upload Speed (Mbps): 135.88

Internet Latency (ms): 18.98

Jitter (ms): 1.18

Device/Location: “Atlantis” (iMac 2020) Band: 2.4GHz

AMPDU: Disabled

Throughput (Mbps): 151.77

Local Latency (ms): 11.39

Download Speed (Mbps): 139.52

Upload Speed (Mbps): 144.83

Internet Latency (ms): 14.05

Jitter (ms): 0.54

Device/Location: “Atlantis” (iMac 2020) Band: 5GHz

AMPDU: Enabled

Throughput (Mbps): 733.40

Local Latency (ms): 5.85

Download Speed (Mbps): 362.92

Upload Speed (Mbps): 415.32

Internet Latency (ms): 11.96

Jitter (ms): 0.22

Device/Location: “Atlantis” (iMac 2020) Band: 5GHz

AMPDU: Disabled

Throughput (Mbps): 746.16

Local Latency (ms): 5.97

Download Speed (Mbps): 349.03

Upload Speed (Mbps): 377.59

Internet Latency (ms): 12.31

Jitter (ms): 0.23

 

[thetechhimself]

Part 2...

After reviewing the data, my initial personal conclusion mirrors my own preferences, there is a slight hit on latency and jitter across the spectrum, in exchange for a bit of additional bandwidth, I was going to rule summarily that Optimizing AMPDU aggregation should remain disabled (default), period. But, then I decided to feed the data to ChatGPT, for kicks and grins as it’s going to in theory be more objective in weighing the metrics than a biased human...


And here’s ChatGPT’s opinion of the matter:

Based on the provided data, we can analyze the performance differences between the scenarios with "Optimize AMPDU Aggregation" enabled and disabled across different devices and locations on both 2.4GHz and 5GHz bands. Here are the key points:

MacBook Pro (Kitchen)

2.4GHz:

• Throughput: Slightly higher with AMPDU disabled (137.74 Mbps vs. 131.13 Mbps).

• Local Latency: Comparable (9.53 ms vs. 9.37 ms).

• Download Speed: Slightly higher with AMPDU enabled (139.38 Mbps vs. 133.30 Mbps).

• Upload Speed: Higher with AMPDU disabled (131.36 Mbps vs. 119.47 Mbps).

• Internet Latency: Lower with AMPDU enabled (15.18 ms vs. 20.15 ms).

• Jitter: Lower with AMPDU enabled (0.64 ms vs. 0.88 ms).

5GHz:

• Throughput: Comparable (702.13 Mbps vs. 699.45 Mbps).

• Local Latency: Lower with AMPDU disabled (7.27 ms vs. 8.32 ms).

• Download Speed: Significantly higher with AMPDU enabled (380.25 Mbps vs. 63.35 Mbps).

• Upload Speed: Significantly higher with AMPDU enabled (305.28 Mbps vs. 45.08 Mbps).

• Internet Latency: Comparable (14.73 ms vs. 14.21 ms).

• Jitter: Lower with AMPDU enabled (0.19 ms vs. 0.26 ms).

MacBook Pro (Corner Room)

2.4GHz:

• Throughput: Slightly higher with AMPDU enabled (35.02 Mbps vs. 32.00 Mbps).

• Local Latency: Lower with AMPDU enabled (9.87 ms vs. 10.45 ms).

• Download Speed: Higher with AMPDU enabled (58.13 Mbps vs. 45.34 Mbps).

• Upload Speed: Higher with AMPDU enabled (94.66 Mbps vs. 77.28 Mbps).

• Internet Latency: Comparable (15.67 ms vs. 14.87 ms).

• Jitter: Lower with AMPDU disabled (1.44 ms vs. 2.63 ms).

5GHz:

• Throughput: Higher with AMPDU enabled (189.90 Mbps vs. 179.28 Mbps).

• Local Latency: Comparable (8.66 ms vs. 8.47 ms).

• Download Speed: Higher with AMPDU enabled (240.47 Mbps vs. 215.62 Mbps).

• Upload Speed: Higher with AMPDU enabled (130.47 Mbps vs. 122.65 Mbps).

• Internet Latency: Comparable (15.34 ms vs. 14.96 ms).

• Jitter: Comparable (0.48 ms vs. 0.50 ms).

Carolina Reaper (Stationary)

2.4GHz:

• Throughput: Higher with AMPDU enabled (42.44 Mbps vs. 29.02 Mbps).

• Local Latency: Higher with AMPDU enabled (6.45 ms vs. 4.03 ms).

• Download Speed: Comparable (38.26 Mbps vs. 39.95 Mbps).

• Upload Speed: Lower with AMPDU enabled (21.15 Mbps vs. 31.01 Mbps).

• Internet Latency: Lower with AMPDU enabled (11.63 ms vs. 13.91 ms).

• Jitter: Higher with AMPDU enabled (2.16 ms vs. 1.34 ms).

5GHz:

• Throughput: Lower with AMPDU enabled (258.74 Mbps vs. 280.34 Mbps).

• Local Latency: Comparable (3.96 ms vs. 3.73 ms).

• Download Speed: Lower with AMPDU enabled (219.92 Mbps vs. 231.19 Mbps).

• Upload Speed: Lower with AMPDU enabled (211.88 Mbps vs. 240.77 Mbps).

• Internet Latency: Comparable (10.05 ms vs. 10.03 ms).

• Jitter: Comparable (0.28 ms vs. 0.25 ms).

iMac (Stationary)

2.4GHz:

• Throughput: Slightly lower with AMPDU enabled (145.48 Mbps vs. 151.77 Mbps).

• Local Latency: Higher with AMPDU enabled (12.38 ms vs. 11.39 ms).

• Download Speed: Comparable (140.81 Mbps vs. 139.52 Mbps).

• Upload Speed: Slightly lower with AMPDU enabled (135.88 Mbps vs. 144.83 Mbps).

• Internet Latency: Higher with AMPDU enabled (18.98 ms vs. 14.05 ms).

• Jitter: Higher with AMPDU enabled (1.18 ms vs. 0.54 ms).

5GHz:

• Throughput: Comparable (733.40 Mbps vs. 746.16 Mbps).

• Local Latency: Comparable (5.85 ms vs. 5.97 ms).

• Download Speed: Higher with AMPDU enabled (362.92 Mbps vs. 349.03 Mbps).

• Upload Speed: Higher with AMPDU enabled (415.32 Mbps vs. 377.59 Mbps).

• Internet Latency: Lower with AMPDU enabled (11.96 ms vs. 12.31 ms).

• Jitter: Comparable (0.22 ms vs. 0.23 ms).

Summary of Findings

1. 5GHz Performance: Generally, 5GHz provides significantly higher throughput and lower latency compared to 2.4GHz, as expected due to the higher frequency and wider channels available in the 5GHz band.
2. AMPDU Aggregation Impact:

o MacBook Pro (Kitchen): Significant improvement in download and upload speeds on 5GHz with AMPDU enabled.

o MacBook Pro (Corner Room): Moderate improvements in throughput, download, and upload speeds on both bands with AMPDU enabled.

o Carolina Reaper: Mixed results; 2.4GHz shows improved throughput but increased latency and jitter with AMPDU enabled. 5GHz shows slightly lower performance with AMPDU enabled.

o iMac: Minimal differences in throughput and latency on 5GHz. On 2.4GHz, slight regression in throughput and increased latency and jitter with AMPDU enabled.

Recommendations

1. Enable AMPDU Aggregation: For devices and locations that showed clear improvements, such as the MacBook Pro in the kitchen on 5GHz.
2. Disable AMPDU Aggregation: For setups where enabling it resulted in increased latency and jitter, such as the Carolina Reaper on 2.4GHz.
3. Further Testing: Consider additional tests to confirm trends, especially in mixed environments where results are not clear-cut.

Overall, enabling AMPDU aggregation generally provides benefits in terms of throughput and download/upload speeds, especially on the 5GHz band, but it can introduce higher latency and jitter in some cases. The decision to enable or disable it should be based on the specific requirements and performance of each device and location.

Given the data from all four scenarios, the decision to enable or disable "Optimize AMPDU Aggregation" should be based on balancing the overall network performance across all devices and locations in your house. Here are the key conclusions:

General Observations

1. 5GHz Band:

o MacBook Pro (Kitchen): Significant improvements in download and upload speeds with AMPDU enabled.

o MacBook Pro (Corner Room): Improvements in throughput, download, and upload speeds with AMPDU enabled.

o Carolina Reaper: Slightly lower performance with AMPDU enabled.

o iMac: Minimal differences, with a slight improvement in download and upload speeds with AMPDU enabled.

1. 2.4GHz Band:

o MacBook Pro (Kitchen): Slight variations, with minor improvements in download speeds with AMPDU enabled.

o MacBook Pro (Corner Room): Improvements in throughput, download, and upload speeds with AMPDU enabled.

o Carolina Reaper: Improved throughput but increased latency and jitter with AMPDU enabled.

o iMac: Slight regression in throughput and increased latency and jitter with AMPDU enabled.

Recommendations

For 5GHz Band

• Enable AMPDU Aggregation: The 5GHz band shows clear benefits in terms of throughput and download/upload speeds for most devices, especially for mobile devices like the MacBook Pro in different locations. The slight decrease in performance for the Carolina Reaper is outweighed by the significant improvements for other devices.

For 2.4GHz Band

• Disable AMPDU Aggregation: The 2.4GHz band shows mixed results with AMPDU enabled. The Carolina Reaper and iMac experience increased latency and jitter, which can negatively impact real-time applications. Disabling AMPDU aggregation can help maintain more consistent performance across all devices.

Overall Strategy

Given that your network supports both 2.4GHz and 5GHz bands, a mixed strategy would be optimal:

1. Enable AMPDU Aggregation on the 5GHz Band:

o This will provide significant performance improvements for throughput, download, and upload speeds for devices connected to the 5GHz band, particularly beneficial for mobile devices like the MacBook Pro.

1. Disable AMPDU Aggregation on the 2.4GHz Band:

o This will help maintain consistent performance with lower latency and jitter for devices on the 2.4GHz band, which is important for stationary devices and applications sensitive to latency variations.

Implementation

1. Router Configuration:

o Check if your router allows separate configurations for AMPDU aggregation on 2.4GHz and 5GHz bands. Many modern routers provide band-specific settings.

1. Monitor Performance:

o After applying the changes, monitor the network performance for a few days to ensure that the configuration meets the overall needs of your household.

Conclusion

By enabling AMPDU aggregation on the 5GHz band and disabling it on the 2.4GHz band, you can achieve a balanced network performance that leverages the strengths of each band and addresses the specific needs of different devices and locations in your house. This approach maximizes throughput and download/upload speeds where beneficial while minimizing latency and jitter where it is more critical.

 

[thetechhimself]

Part 3...

Had to move some stuff around, here's a quote from Star Trek TOS regarding ChatGPT I'm going to throw in...

KIRK: All right, my recommendations are as follows. We send down general survey party, avoiding contact of all intelligent life on the planet's surface. The survey party will consist of myself, Doctor McCoy, Astrobiologist Phillips, Geologist Rawlins and Science Officer Spock.
DAYSTROM: Play M-5's recommendations, won't you, Mister Spock?
M5: (a male computer voice) M-5 readout, planet Alpha Carinae Two. Class M, atmosphere, oxygen-nitrogen.
SCOTT: The power's gone off on deck five.
M5: Categorization of life form readings recorded. Recommendations for general survey party. Science officer Spock, Astrobiologist Phillips, Geologist Carstairs.
KIRK: Well, the only difference in reports and recommendations is the landing party personnel. That's only a matter of judgment.
DAYSTROM: Judgment, Captain?
SPOCK: Captain, the computer does not judge. It makes logical selections.
KIRK: Why pick Carstairs instead of Rawlins? Carstairs is an ensign, no experience. This is his first tour of duty. Rawlins is chief geologist.
DAYSTROM: Aren't you really more interested in why M-5 did not select you and Doctor McCoy? Well, let's find out anyway. M-5 tie-in.
M5: M-5.
DAYSTROM: Explanation for landing party recommendation.
M5: General survey party requires direction of science officer. Astrobiologist Phillips has surveyed twenty nine biologically similar planets. Geologist Carstairs served on merchant marine freighters in this area. Once visited planet on geology survey for mining company.
DAYSTROM: Why were the Captain and the Chief Medical Officer not included in recommendation?
M5: Non-essential personnel.

Like the M5 computer in Star Trek, it doesn’t miss a beat (but it has flaws like the M5 computer, I’ll save those jokes for another time). ChatGPT correctly concluded, unlike a biased human, how about turn it on for 5GHz, and turn it off for 2.4GHz, instead of my “flawed” all or nothing thinking. Be careful them large language models, they’re getting better. It also correctly concludes, every situation is different. It depends what you’re trying to achieve. When I initially asked it for conclusions, it didn’t give me a summary conclusion at first as you can see, it gave me each client’s performance and it’s impact for each client instead of the whole (I redacted my next input requesting it to weigh the entire scenario as a whole). After, it did “think about the bigger picture” and disagreed with my all or nothing assessment. In hindsight, I actually agree with the computer here; it makes sense on paper that optimizing AMPDU aggregation on 2.4GHz is going to be more problematic; it’s inherently more susceptible to interference which is going to lead to more retransmissions which is the downside to using Optimization of AMPDU Aggregation. My benchmark data aggress with on-paper theory here interestingly enough. Just a hypothesis, enabling Optimizing AMPDU aggregation, will likely benefit 6GHz even more as it’s an even newer spectrum, with more bandwidth, and even less interference, has less range too though.

Post-testing anecdotes:

About 70% through testing, I mentally said to myself "I seem to recall seeing that the media server function on my Synology NAS could be allocated to the other unused port on my Synology NAS; perhaps connecting it and assigning the Media Server to the secondary NIC, would improve results as it would leave the network pipe to the containers open." I decided not to implement this mid-testing as this was already very time intensive running these tests and I had already repeated the testing when the Media Server wasn't in use; seemed a poor choice to change horses mid-race.

However, after the testing concluded, I attached the secondary NIC on my DS224+ to one of my spare 1GB LAN ports on my Asus GT-AX6000 and assigned the Media Server to it and ran a couple tests. I found that my latency was closer to 30ms with the media server under load on the dedicated port (not shared with the containers) indicating there is still some intrinsic latency added when the media server is also under load, probably from either the CPU or storage loading, but a far cry from the 100ms latency with both the containers and media server "fighting" over the same NIC. This is highly relevant to my day-to-day setup/operations regardless of deciding whether or not to enable Optimizing AMPDU aggregation as I'm running both a PiHole and Unbound container to improve my network posture; those containers would also in theory benefit from utilizing a dedicated NIC for the media server so when it's in use by one of my TVs, they have faster response to DNS queries from those containers on the network for browsing activity or cloud-sync operations, streaming operations, etc.

Lastly, as a human, I tend to view things in black or white, that is enable or disable AMPDU optimization wholesale, the idea of enabling it on 5GHz and disabling it on 2.4GHz was disheartening at first, however, I had also witnessed this first hand spending hours in front of these devices running the tests and getting to see both the data now presented, seeing it as it was coming in before being aggregated and averaged, and also from tests I had to frequently abort which made it through several iterations of each 10x loop, before having interference on 2.4GHz from say my wife wanting to heat her coffee, warm a lunch, a kid firing up a video from my media server which was quickly presented in the next iteration run, or a server suddenly becoming unavailable from speedtest-cli. I can say, the large language model is not wrong in it's assessment here. What's more, ideally then, it'd be nice to have my clients "roam" between 2.4GHz and 5GHz depending on distance from routing and signal strength/TX rate, to maximize these benefits of enabling Optimization of AMPDU aggregation on only 5GHz, however Apple Devices (both my iPhones and Macs) are "dumb" where they just lock unto the strongest RSSI, which in my case is always 2.4GHz, but it's almost always the slower option unless I'm either outside, or in a corner of my house where the signal is weakest so that's counterintuitive…

Perhaps it's time I revisit "SmartConnect" where both bands are presented as a single SSID and the router chooses which band to steer a client to depending upon conditions so to workaround this logic fault / limitation (and I did, up next)

 

[thetechhimself]

#Here's the script I used, in case someone else wants to inspect, replicate, or improve upon it... In hindsight, you could run speedtest-cli --list, awk out the first hit, initialize it into the array and have it print the server used, and store these results into a file, where the script also checks to see what server was last used, before proceeding to alleviate some of the manual "lifting" for checking your speedtest-cli server isn't moving or unavailable, and have it re-run both test. You know, I could've also made this interactive, where it pauses at the end of each loop, asks for what band I'm testing, and whether AMPDU is enabled or disabled and print there results into a log that way it has a built-in wait mechanism between router tweaks... Anyhow, here's the code as I ran it...

# Define test parameters


SERVER="192.168.1.1” # Replace with the IP address of the iPerf3 server


DURATION=10 # Duration for each iPerf3 test in seconds


ITERATIONS=10 # Number of times to run each test


SPEEDTEST_SERVER_ID=1772 # Replace with your chosen speedtest server ID


PING_TARGET="1.1.1.1" # Target for the additional internet latency ping test





# Initialize accumulators for aggregated results


total_throughput=0


total_latency=0


total_download=0


total_upload=0


total_internet_latency=0


total_jitter=0





# Function to run iPerf3 test for throughput


run_iperf_test() {


echo "Running iPerf3 test..."


throughput=$(iperf3 -c $SERVER -t $DURATION -J | jq .end.sum_received.bits_per_second)


throughput_mb=$(echo "scale=2; $throughput / 1000000" | bc)


echo "Throughput: ${throughput_mb} Mbps"


total_throughput=$(echo "$total_throughput + $throughput_mb" | bc)


}





# Function to run iPerf3 UDP test for jitter


run_iperf_udp_test() {


echo "Running iPerf3 UDP test..."


jitter=$(iperf3 -c $SERVER -u -t $DURATION -J | jq .end.sum.jitter_ms)


echo "Jitter: ${jitter} ms"


total_jitter=$(echo "$total_jitter + $jitter" | bc)


}





# Function to run ping test to local server


run_ping_test() {


echo "Running ping test to local server..."


ping_result=$(ping -c 10 $SERVER)


latency=$(echo "$ping_result" | awk -F '/' 'END {print $5}')


echo "Latency: ${latency} ms"


total_latency=$(echo "$total_latency + $latency" | bc)


}





# Function to run speedtest


run_speedtest() {


echo "Running speedtest..."


speedtest_json=$(PYTHONWARNINGS="ignore" speedtest-cli --json --server $SPEEDTEST_SERVER_ID)


if [ $? -eq 0 ]; then


download=$(echo "$speedtest_json" | jq .download)


upload=$(echo "$speedtest_json" | jq .upload)


download_mb=$(echo "scale=2; $download / 1000000" | bc)


upload_mb=$(echo "scale=2; $upload / 1000000" | bc)


echo "Download Speed: ${download_mb} Mbps"


echo "Upload Speed: ${upload_mb} Mbps"


total_download=$(echo "$total_download + $download_mb" | bc)


total_upload=$(echo "$total_upload + $upload_mb" | bc)


else


echo "Speedtest failed"


fi


}





# Function to run ping test to 1.1.1.1


run_internet_ping_test() {


echo "Running ping test to 1.1.1.1..."


ping_result=$(ping -c 10 $PING_TARGET)


internet_latency=$(echo "$ping_result" | awk -F '/' 'END {print $5}')


echo "Internet Latency: ${internet_latency} ms"


total_internet_latency=$(echo "$total_internet_latency + $internet_latency" | bc)


}





# Run tests multiple times


echo "Starting network performance tests..."


echo "Test run started at $(date)" | tee -a network_test_results.txt


for i in $(seq 1 $ITERATIONS); do


echo "Iteration $i..."


run_iperf_test


run_iperf_udp_test


run_ping_test


run_speedtest


run_internet_ping_test


done





# Calculate averages


avg_throughput=$(echo "scale=2; $total_throughput / $ITERATIONS" | bc)


avg_latency=$(echo "scale=2; $total_latency / $ITERATIONS" | bc)


avg_download=$(echo "scale=2; $total_download / $ITERATIONS" | bc)


avg_upload=$(echo "scale=2; $total_upload / $ITERATIONS" | bc)


avg_internet_latency=$(echo "scale=2; $total_internet_latency / $ITERATIONS" | bc)


avg_jitter=$(echo "scale=2; $total_jitter / $ITERATIONS" | bc)





# Print aggregated results


echo "Aggregated results:" | tee -a network_test_results.txt


echo "Average Throughput: ${avg_throughput} Mbps" | tee -a network_test_results.txt


echo "Average Local Latency: ${avg_latency} ms" | tee -a network_test_results.txt


echo "Average Download Speed: ${avg_download} Mbps" | tee -a network_test_results.txt


echo "Average Upload Speed: ${avg_upload} Mbps" | tee -a network_test_results.txt


echo "Average Internet Latency: ${avg_internet_latency} ms" | tee -a network_test_results.txt


echo "Average Jitter: ${avg_jitter} ms" | tee -a network_test_results.txt


echo "Tests completed at $(date)" | tee -a network_test_results.txt

 

[Tech9]

I don't know what ChatGPT says, but Optimize AMPDU aggregation Enabled may lead to broken time sensitive applications. The default setting is Disabled for good reason. May work well with printers/scanners on 2.4GHz band in a noisy Wi-Fi environment. 5GHz band, VoIP, video calls, etc. - Disabled.

 

[thetechhimself]

I don't know what ChatGPT says, but Optimize AMPDU aggregation Enabled may lead to broken time sensitive applications. The default setting is Disabled for good reason. May work well with printers/scanners on 2.4GHz band in a noisy Wi-Fi environment. 5GHz band, VoIP, video calls, etc. - Disabled.

I agree, in fact I think I said that, or at least the next thread I’m working on I do which I hope to post soon. Anything latency sensitive? Nope.

That said, I’m finding it works fantastic for streaming and browsing on 5GHz. There’s a reason it’s both the default, and likewise, an exposed control to adjust.

 

[Tech9]

the next thread

Something more readable, please. Your test scenarios, results, differences - very hard to find and directly compare.

I just scrolled down because I know what the result of Optimize AMPDU aggregation Enable/Disable is. Tested already.

 

[thetechhimself]

Something more readable, please. Your test scenarios, results, differences - very hard to find and directly compare.

I just scrolled down because I know what the result of Optimize AMPDU aggregation Enable/Disable is. Tested already.

I actually have to agree with you; thinking it myself but I also knew my proposal would be fought, hard, by those saying “inconclusive”, really wanted to conclusively bring some closure to this debate. That said I originally posted this on another forum that doesn’t support table insertion, really hurts presentation. I may take a second stab at posting this on SNB and see if I can clean it up as I suspect this forum although limited to 10k threads, may have better formatting and style support

 

[Tech9]

Optimize AMPDU Aggregation is a setting for someone to try in congested Wi-Fi environment with many active clients. May improve the throughput for none time critical applications. If you can get 140Mbps throughput on 2.4GHz - you have a good channel with quite high bandwidth available, keep it disabled, it's not needed. When testing this specific setting for more accurate conclusions you have to test with multiple clients simultaneously, not one at a time. This may eventually show differences in throughput and latency between enabled/disabled.

 

[thetechhimself]

Optimize AMPDU Aggregation is a setting for someone to try in congested Wi-Fi environment with many active clients. May improve the throughput for none time critical applications. If you can get 140Mbps throughput on 2.4GHz - you have a good channel with quite high bandwidth available, keep it disabled, it's not needed. When testing this specific setting for more accurate conclusions you have to test with multiple clients simultaneously, not one at a time. This may eventually show differences in throughput and latency between enabled/disabled.

 

[thetechhimself]

I like. I may have to repeat test with all 3 clients banging away

 

[sfx2000]

Optimize AMPDU Aggregation is a setting for someone to try in congested Wi-Fi environment with many active clients. May improve the throughput for none time critical applications

This is more of a driver specific option - even across the same vendor...

QC-Atheros and MediaTek do well here on the AP side - it's all about the scheduler implementation I suppose...

 

[sfx2000]

I hate to do this, but see my original thread https://www.dpreview.com/forums/post/67814341 as apparently, SBNForums, don't support threads over 10K characters, which mine exceed 14K... Lemme try to cut this in half though... Reposting here as although I'm a DPR regular, I am an infrequent over here, and the discussion is much more appropriate for SNB...

You need to find a better way is displaying the results of your testing...