qca / open-ath9k-htc-firmware

The firmware for QCA AR7010/AR9271 802.11n USB NICs
Other
428 stars 182 forks source link

Retry limit for data frames (with ar9271 chipset) #86

Open willtop opened 8 years ago

willtop commented 8 years ago

I am wondering where is the retry limit for data frames stored when ack is not received. Is it stored in a register within the hardware, or is it defined as a constant within firmware code. I have found the retry limit for RTS failures specified in register D_RETRY_LIMIT, yet:

  1. it doesn't cover data frame failure (not receiving ack)
  2. value 0x0 is not supported Also, I tried to ask question on the mailing list: http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw, yet sending email to the specified address: ath9k_htc_fw@lists.infradead.org constantly fails, even after successful subscription. Thanks in advance!
erikarn commented 8 years ago

Hm, so RTS exchange failure is a "short retry" and that should be specified in the D_RETRY_LIMIT register.

willtop commented 8 years ago

Thanks for the reply! I understand that D_RETRY_LIMIT has the RTS exchange failure limit specified by bit 3:0. Yet I am wondering the data frame retry limit (after sending data frame, can't receive ack). If retried more than limit amount, the packet would be dropped. Wondering where the limit value is stored in. Thanks!

erikarn commented 8 years ago

Ok, that's the LONG ack limit, and also should be set in the per-rate retry setup in the TX descriptor.

Ie, setting the TX descriptor retry rate to 1 should do what you want.

For 11n aggregate packets, that retransmit is done in software in the firmware, so the hardware gets handed the same frame over and over until it expires or transmits fine.

-adrian

willtop commented 8 years ago

Thanks for the reply again! I indeed knew it's long ack limit, but need a bit more clarifications on a few other concepts: what does per-rate mean, and why would it be referred as retry rate rather than retry count? By the last paragraph, you are implying there won't be any register recording data packet retry limit, and this limit is specified as a constant within firmware? If with details on where it's stored in firmware code, it would be highly appreciated.

Truly grateful the help.

erikarn commented 8 years ago

Hi!

So you need to check two things - what the firmware is doing for retransmitting frames, and what the per-rate retry is setup for in the TX descriptor.

The TX descriptors have up to four rate try slots - each attempt has:

For non-aggregate traffic, I think the firmware isn't doing any retransmit.

-adrian

willtop commented 8 years ago

Hello erikarn,

Still not sure about four rate try slots, does that mean the ar9271 adapter supports up to 4 queues to transmit at different rates? Yet from the datasheet, I read it has 10 separate QCU and DCU pairs, would them represent the 10 queues to send/ receive the frames, and how would they correspond to the 4 queues? I couldn't find the answer from online searching or datasheet.

Did you also infer for aggregated packets (several small sized packets joined together, as long as still smaller than max packet size) the firmware code would retransmit in absence of acks by sending to hardware same packet again and again; yet with non-aggregated packets (only single standalone packets as they were sent from upper layers), no retry would be performed at all despite the retry limit setting? While in both cases,there isn't hardware register storing the retry limit?

Thanks again for the responce!

erikarn commented 8 years ago

Hi,

Look at ar5416_hw.c - Set11nRateScenario_20() . It has four rate scenarios, each has a rate, number of tries, and some other flags.

willtop commented 8 years ago

Hello erikarn,

I am looking into the directory of ath9k, yet couldn't find file ar5416_hw.c.

I am seeing files with prefixes such as ar5008, ar9002, and ar9003. Do you know what do they correspond to?

Thanks

erikarn commented 8 years ago

hi!

This is the /firmware/ - ie, checkout open-ath9k-htc-firmware ;-p

willtop commented 8 years ago

Thanks for the tips! Now i see the four series of different default try settings (0,1,2,3) respectively. Gonna try testing it out. Yet still not sure what those 4 series stand for?

erikarn commented 8 years ago

Hi,

Yeah, they're tried in order. 0 first, then 1, then 2, then 3. :)

-a

willtop commented 8 years ago

Hello,

Thanks for the help and explanation! Sorry for another inquiry.

I have edited the set11nTries(series,1) for all four lines from line862~865 within the ar5416_hw.c code, yet using iperf still shows retries. I have even tried to set the second number within parenthesis all 0, still seeing retries for packets (for some packets there are even 2 retries, with a RTS/CTS pair in between) Am i revising at the right part?

willtop commented 8 years ago

Looking from datasheet, the tx descriptor has fields tx_tries0,1,2,3. as they might correspond to the number in set11ntries? Guess I would try to set one of them 1 and rest 0 as that would skip the rest three series

erikarn commented 8 years ago

Hi,

So, hm. If you set the first rate retry count to 1, and the rest are set to rate = 0, tries = 0, it shouldn't try those other attempts.

There are a couple of places where it's setting the first rate tries, so just look at that file for wherever else it's setting that descriptor up.

-a

erikarn commented 8 years ago

Yup!

-a

willtop commented 8 years ago

I am also suspecting my new firmware really isn't properly loaded (since i still see traffics even setting all those tries to 0) What i did is checking out open-ath9k-firmware and make it, then replace its ar9271-1.4.0.fw file over its older version into /lib/firmware/ath9k_htc folder. unload all related modules, and replug in adapters. Does ath9k driver automatically load adapter with the firmware every single time the adapter is plugged into usb slot? or if there is certain error, the adapter would actually function with it's older firmware stored from previous load? Is there a way to confirm newest firmware being loaded? Sorry for yet another question, as I have been trying to figure this question out really hard. thanks for the understanding!

erikarn commented 8 years ago

Hi,

I don't know much about the firmware loading side of things, sorry!

-a

willtop commented 8 years ago

no problem! thanks for the help and support :)