Open willtop opened 8 years ago
Hm, so RTS exchange failure is a "short retry" and that should be specified in the D_RETRY_LIMIT register.
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!
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
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.
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
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!
Hi,
Look at ar5416_hw.c - Set11nRateScenario_20() . It has four rate scenarios, each has a rate, number of tries, and some other flags.
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
hi!
This is the /firmware/ - ie, checkout open-ath9k-htc-firmware ;-p
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?
Hi,
Yeah, they're tried in order. 0 first, then 1, then 2, then 3. :)
-a
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?
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
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
Yup!
-a
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!
Hi,
I don't know much about the firmware loading side of things, sorry!
-a
no problem! thanks for the help and support :)
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: