bandwidth...why won't this work?

I'm documenting this here so that one day when I don't remember why I did what I did, I'll stumble across this posting.

Symptoms:
LQ is 100% but ping times go through the roof when trying to send traffic across the mesh. Throughput is limited.

Possible Cause:
Did you set the distance parameter correctly?

Here's a good summary of the not-so-mysterious distance parameter:

So, reading the forum, I've seen recommendations of anywhere from 110% to 150% of the actual distance.  This is a pretty wide variation.  So, how critical is setting the right ACK distance?

 

Reading up on it, here is what I found.  When radio A sends a frame (Packet in radio speak) to radio B, it expects radio B to send a ACK frame acknowledging that it received radio A's frame.  Radio A can't just wait forever for the ACK, because radio B might not even know that radio A attempted to send it a frame.  So radio A waits a set amount of time (ACK Timeout) and if it didn't receive an ACK in that time it resends the frame.  If the ACK Timeout is set much longer than is needed, there is no problem on frames that radio B receives properly, but if radio B doesn't receive a frame properly, radio A is stalled waiting until the ACK Timeout runs out.  So, especially in connections with less than perfect conditions, setting the ACK Time too long slows throughput.

 

But what happens if the ACK Timeout is too short?  Reading up on it, here is what I found.  If the ACK Timeout is too short then radio A gives up on radio B before the ACK frame that is coming can reach radio A.  This results in radio A resending a frame that radio B had received just fine.  So this could easily halve bandwidth, but it's actually worse than that.  Since the radios are half-duplex, you can get situations where the ACK and the retransmitted frame try to share the same air time, causing collisions and holdoffs in standard WiFi, reducing the throughput even worse.  And in AirMAX, where the usual collision avoidance mechanisms are turned off, I can imagine an even worse scenario.  If radio B's ACKs are arriving while radio A is retransmitting then, due to the rigid timing structure, the ACKs will be missed and frames retransmitted repeatedly until the Max Retry limit is hit.  Then, since radio A has given up on retransmitting the frame, it would finally hear the ACK.  And, while all these retransmits are going on radio A will start lowering it's TX modulation rate because it thinks that radio B is not hearing the frames. This, I think, would be the cause of Rate Crashes that some of us see from time to time.

 

So it's critical that the ACK distance not be set too short.

This comes from: http://community.ubnt.com/t5/Installation-Troubleshooting/Setting-ACK-Distance/td-p/1131379  
While that's an incomplete thread, the description is the best one I've found so far.

If you're looking for the internals and the impacts, look here: http://www.air-stream.org.au/technical-references/ack-timeouts-and-effects-distance-links
This talks about not only changing the ACK distance parameter, but also changing the slottime based on physical distance. I've not done any additional research into slottime, so I'm just including it for thoroughness - no recommendations being made or implied.

Another good thread to read is this one, where Ken and Joe dive into details: http://www.aredn.org/content/distance-parameter

So now the question of what do you really set this parameter to in the AREDN gui? Opinion, conjecture, and tribal knowledge all point to 1.2 times the actual point-to-point distance in meters between nodes that can see each other on rf. 

Stay meshed, my friends.
73, Mike KG9DW