Another great sure-fire tip from customer/Alfa user Trey MacDonald, in his words:

“…I found will significantly improve the “perceived” performance on the part of the Alfa Network USB client.

For starters, I’m assuming that for the most part, customers who purchase this unit are trying to achieve longer distance connections, etc,..”in the neighborhood” (wink, wink)….

One problem with this, is that most people leave their wireless hubs, set to the default..Let’s say, “linksys” on channel 6… Consequently buying a directional antenna is essential to sorting out the signals.

Nevertheless, even when you get a connection, the other signals can “bleed in” and disrupt the traffic.

Obviously, there are parameters which can be modified, with respect to packet-size, and fragmentation threshold, etc. – in conjunction with a good “ping” tool such as:

http://www.colasoft.com/ping_tool/

Which will allow someone to adjust packet sizes, frequency, and TTL….

BUT – this requires some competency and understanding – Which may be above the comprehension of the average user..

Here’s the tip.Once installed, go to the Control Panels/Network Connections
Right-click on the USB Network Adapter and Select Properties
Click on the Configure button on the right-hand top, of the General tab

Go to the Advanced tab
Set the value of “Long Retry Count” to a higher value – The default is 7, (I used 21)
Set the value of “Short Retry Count” to a higher value – The default is 7, (I used 21)

Click OK.

That’s it !

The effect of making this change, is that the adapter will retry the packets (both long and short) many more times AT THE DRIVER LEVEL before reporting an error. In many cases this will overcome poor reception or disruptive interference.

The consequence to the end-user is that the connection appears to be more reliable, because the driver is doing all of the work of repeating packets…

This solution is significantly less complicated than actually tuning the connection – but it has the desired effect. I think in the circumstances I described, quite profound.

The reason for this, is for the most part, web-based protocols like HTTP – use what’s called “AT LEAST ONCE” semantics – which means they automatically discard duplicate packets – therefore the effect of re-transmitting is non-consequential…and is much preferred to the driver reporting back to the browser that the connection itself has “stalled” …or to the OS that the connection has been dropped. The idea is to perform the re-transmit at the lowest overhead point – at the driver.

-Trey MacDonald