On Tue, 2008-10-07 at 19:13 +0200, Felix Fietkau wrote: > Johannes Berg wrote: > > On Sun, 2008-10-05 at 18:04 +0200, Felix Fietkau wrote: > >> This patch adjusts the rate control API to allow multi-rate retry > >> if supported by the driver. The ieee80211_hw struct specifies how > >> many alternate rate selections the driver supports. > > > > Don't those drivers that announce supporting max_altrates = 1 have to > > update the status for alternative rates too? Also, should > > max_altrate_tries == 0 indicate that that is fixed? > IMHO yes. Should we document that? > > But b43 with the > > default firmware actually _is_ capable of changing the number of retries > > (default to 3/3 or 3/4 I think), just not per frame. Should we have that > > in the API too? > Minstrel won't use it, because the value that it selects is dependent > on the rate that is to be used there. Maybe it'd make sense for other > stuff, though. No idea. > When using MRR and the get_rate function determines that it's time to do > some sampling, and the sampling rate it selected is lower than the calculated > max throughput rate, it wouldn't make sense to put the sampling rate in the > first stage of the MRR chain, because that would lower the effective > throughput unnecessarily. > > Instead it throws the sampling rate in the second stage of the MRR chain > and increases a separate counter to prevent it from doing large bursts of > sampling attempts. > > However if the hw never gets to the second MRR stage, because the first one > worked just fine, it should not mark this as a successful sampling, because > the sample rate was not actually attempted. Heh, ok, I didn't really care about those details. > The IEEE80211_TX_CTL_RATE_CTRL_PROBE flag is used to tell the tx_status > function that there is a sampling rate in the second MRR stage, so that > it can update the sampling counter accordingly, in case the sampling rate > actually got used. So if I read that correctly you're saying it's not part of the driver API but just something to be preserved from tx to tx-status. Can you document that in the header file too please? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
