okay folks. here's my definitive (IMHO) definition (Redundant) of the effect of MTU - the maximum transmission unit for a network interface, like ethernet or iBurst radio.
If your connection is configured for a MTU that is higher than your link connection can support, the packet will be *FRAGMENTED* that is, split into two (or more packets if your link is especially bad).
The issue is, your iBurst can only transmit and receive a certain amount of packets a second. This is where a skewed MTU setting can affect speed. If you inefficiently send packets, speed will be affected, and some websites will associate you with a ddos attack, which is quite undesirable.
Example: You're connected to a bittorrent tracker, and peers contact you for data. As you send a packet of data to the peer, whereever he is on the internet, your PC sends a the maximum sized packet of data for your ETHERNET connection, which by default is 1500 bytes including TCP headers.
As the packet reaches your router, iptables or your other NAT software running on the router will say, 'hey man, this packet is 1500 bytes, but the iBurst connection can only send out, by default, packets of 1432 bytes at a time - I'll have to split this into two packets to send this.' Obviously, it takes more time to send two packets than it takes to send one.
The most important problem arises if the MTU on your router is set to the default setting, but this IS STILL TOO HIGH. For example, the default linux MTU for PPPoE (eg Iburst) is 1432, but my radio signal will only support packets > 1350 in size.
So what happens in the logic of NAT at your router is: 'I recieve an outgoing packet of size 1500 bytes. This is too large for the default setting, So I'll split it into two packets - one 1432b in size, the other 68 bytes in size. But hang on, the iBurst router just told me that the 1432bytes packet is still too large for transmission - I'll HAVE TO FURTHER SPLIT THIS PACKET.'
So what happened essentially is that the one packet that you tried to send actually was split into 3 packets where one could have done fine.
Author's note: I'm not sure where the second fragmentation occurs: on the router, or on the UT.