-
Notifications
You must be signed in to change notification settings - Fork 8
Description
This issue is to note an observation seen while testing another issue, and possibly highlights that there is an issue (or at the least, an optimization opportunity) with the WILC1000 module.
Using iperf to send traffic from a WILC1000 (station mode) to a distant TPLink AP, on the air packet captures show a large amount of re-transmissions.
Further investigation has shown the the WILC module appears to consistently tx the large QOS-Data frames at an initial rate that is much higher data rate than the weak link is capable of. Most often, these packets are re-transmitted 4 times before successfully being ack'ed, each at a successively lower rate.
This results in much lower wilc - > AP performance than would otherwise be seen if the initial tx was closer to the rate the link is actually capable of.
Some anecdotal examples:-
On the same link:
- iperf from AP-> WILC shows initial tx and consistent first packet ack at 39Mbps rate
- iperf from WILC ->AP shows packets sent most frequently at 65 initially, then retries at 58, 52, and 39.
With a weaker link, the WILC will transmit using mid g rates, but the same sequence occurs, with the packet being re-transmitted several times.
Comparing to the AP-> WILC iperf the AP again sends a much higher number of packets without re-transmit (and at a lower initial rate)
Comparing the data throughput, for the same link conditions, AP->wilc iperf throughput is much higher than the wilc->AP throughput.
We believe that if the WILC module was more accurately maintaining the current rate the link is capable of, and re-transmitted fewer packets, then the difference between up and down link speeds would be less. It appears that the automatic rate control in the WILC100 module needs to be investigated.
During these tests, the RF environment was kept as quiet as possible, however other WIFI AP's are operating on the same channel, and some other WILC stations were connected to this AP, however no active data transmission was taking place with those other modules. (This is unlikely to be a contention, or packet overlap issue, causing the re-transmissions)
Using the WILC module in AP mode has not been investigated to see if the same behaviour occurs in this reversed configuration, but this would be an interesting experiment.
While this is not a critical issue (the packets do successfully get through after several retries), it would be good to get some feedback on these observations, and have some Microchip engineering investigations performed to see if improvements can be made to how the WILC module handles selecting the initial rate used for tx.
It should also be noted that as a result of this behaviour, the effective throughput difference between modules that are located very close the the AP, compared to those located much further away is much more that it should be, after taking into account the lower data rate needed for the distant link. This difference was easily noticeable, which was the trigger for this deeper investigation.