Zefir Kurtisi <zefku@xxxxxxxxxxxx> writes: > Hi, > > I am running into a strange issue with the ath9k operating a 9590 > device which to me seems like a HW issue, but since work on rate > controllers is already going for decades, I hardly can imagine this > never showed up. > > The issue observed is this: the TX status descriptors never report > rateindex 1, it is always 0, 2, or 3, but never 1. > > I noticed this by overwriting the rate configuration provided by > minstrel to a static setup, e.g. (7,3)(5,3)(3,3)(1,3), all MCS. The > device operates as iperf client to a connected AP and continuously > transmits data. While at that, the attenuation between the endpoints > is gradually increased, expecting to see a gradual shift in the > reported TX status rateindex from 0 to 3. But nada, the values > reported are 0,2, and 3 - never 1. > > I double checked that the TX descriptors are correctly set with the > rates and retry counts - all looking sane. > > More obvious, after changing the rate configuration to > (7,3)(1,3)(5,3)(3,3) the expectation would be to have either 0 or 1 > reported as rateidx, since the transmission ought to be successful > with the lowest rate or never. Again all rates are reported but 1. > > Now the question for me is: what is the HW exactly doing with such a > configuration? Is it skipping the second rate, or is it just reporting > wrong? You should be able to see this by looking at the rates the frames are being sent at, shouldn't you? > Both possibilities have great impact, since upper layers (like > airtime) use the returned rateidx to calculate and configure operating > parameters at runtime. Have you actually observed any issues from this? If it's just skipping a rate, minstrel should still be able to make decisions based on the actual values returned, no? > If this is a know issue, nevermind and thanks for pointing me to it. Otherwise if > some of you have the named device operational, it would help a lot to get the > issue confirmed. Just apply the attached patch and perform some TX testing in > either attenuation adjustable or varying link condition setups. Whenever a frame > is reported to have been transmitted at a rateidx > 0, the collected stats are > logged, e.g. > MRR: 2: [51029, 0, 4741, 6454] > > In essence, the failure is confirmed if the counter for 1 is 0 or very low > compared to higher numbers for 0, 2, or 3. Tried your patch and couldn't reproduce. Not the same hardware, though. Mine is: 01:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01) -Toke
