MT states: (http://wiki.mikrotik.com/wiki/Wireless# ... S.2FCTS.29
* hw-fragmentation-threshold (integer 256..3000 | disabled;) : Specifies maximum fragment size in bytes when transmitted over wireless medium. 802.11 standard packet (MSDU in 802.11 terminology) fragmentation allows packets to be fragmented before transmitting over wireless medium to increase probability of successful transmission (only fragments that did not transmit correctly are retransmitted). Note that transmission of fragmented packet is less efficient than transmitting un-fragmented packet because of protocol overhead and increased resource usage at both - transmitting and receiving party.
If your Alvarion now fragments all data in portions of 10bytes and put some header on it of some bytes (I don't know how much but will be in the same range) this would mean you basically double the data to be transported over the link.
At the same time the router recieving the data package first has to break the package up and add the headers before he send it to the next hop over the wireless link
The receiving end now had to debug all the frames back to its original package size.
You can imagine that takes quit some processor time to on both ends.
So although these small setting on a very poor link (other wise retrans not needed) might improve the data delivery over such poor link, the sheer bulk of extra data to be transported reduces that (already poor- ) links capacity in Alvarion's case by 50%
This is what UBNT writes in their manual:
Fragmentation Threshold: specifies the maximum size for a packet before data is fragmented into multiple packets. The range is 256-2346 bytes, or word “off”. Setting the Fragmentation Threshold too low may result in poor network performance.
The use of fragmentation can increase the reliability of frame transmissions. Because of sending smaller frames, collisions are much less likely to occur. However lower values of the Fragmentation Threshold will result lower throughput as well. Minor or no modifications of the Fragmentation Threshold value is recommended while default setting of 2346 is optimum in most of the wireless network use cases.
Here the guideline is "NOT to small", If not needed leave default 2346
2346 is 1500mtu dataframe + all possible header add ons for encryption, TOS etc.
If you are not using that, 1500 is therefore a good suggestion.
Personally I have not a high impression of the skills of Mike from ubnt. He actually wonders in a topic why someone would use RTS/CTS and fragmentation threshold at all...
That shows of little knowledge of real world networks. RTS/CTS almost always improves network performance.
He also advised me in the past re settings of my nano`s which didn't help me at all. You won't find me a lot there any more...
So, if your link suffers from lots of package losses it is better to enhance the link anyway physical possible instead of reducing the thresholds to very low numbers.
Its like an icy road full with loaded auto buses that have to transport a certain amount of passengers in a certain time to reach their destinations in time. Now and then a bus slips and get lost so not everybody will make it.
I don't think we will save a lot of passengers in the end by having them all using their own little Volkswagen with a trailer on their tow bar (extra headers) to do the same.... probably more passengers won´t make it in time in the end, even when the ice is gone. So what did we win here?
I have used 1000 for some months and upon advice of a experienced member of this forum changed that into 1500 but to be hones have not seen noticeable differences in data deliveries in general.
Maybe in certain specific links that suffer higher package losses then the average it might be a suggestion to test with some lower settings. But since you basically also have to set the lower frame size on the AP the good links are now suffering from higher date payloads. On heavy used networks this would decrease overall performance of the AP-clients network.
My suggestion would be to use 1500 for most links that have no extra WEP, WPA or TOS headers on the data packages. If you do then you have to increase the size a bit to cope with the extra.