Re: [PATCH v2 1/3] mac80211: improve PID rate control mechanism byavoiding rate oscillation problem

[Julian Calaby]

Hi Wei,

On Mon, Mar 12, 2012 at 13:21, wei <yinwei168@xxxxxxxxx> wrote:
> Thank you, Julian.

No problem =)

> On 12/03/12 11:14, Julian Calaby wrote:
>>> @@ -271,14 +473,17 @@ rate_control_pid_get_rate(void *priv, st
>>>                info->control.rates[0].count =
>>>                        txrc->hw->conf.long_frame_max_tx_count;
>>>        else
>>> -               info->control.rates[0].count =
>>> -                       txrc->hw->conf.short_frame_max_tx_count;
>>> -
>>> +               info->control.rates[0].count = 2;
>> Should this be a constant or something? Why is this being set to 2?
>
> According to the principle of how PID works, the default FLR is 14% and it attempts to decrease the rate if the FLR is higher than 14%. Let us assume that the current FLR is 14%, Then the probability for two consecutive failed attempts should be 14% * 14% = 0.0196 = 1.96%. The probability is very low. So I think we should not try further retransmission at this rate and fall back as soon as possible. Another reason is that the number of probes at the proposed rate is set to MAX_PROBES = 3 in the implementation, which means we will have 6 attempts at the probing rate. If the current rate is the lowest, say 1 Mbit/s, in 120 ms (a rate adaptation period in PID), the maximum number of attempts is around 8--9. I think I should limit the number of probes within the maximum attempts that can be achieved in one rate adaptation period.
>
> We could switch back to the configured value. But I need to change the maximum number of probes, MAX_PROBES.

You should either use a constant (i.e. #define
PID_SHORT_FRAME_MAX_PROBES 2) or put this reasoning in a comment
there, otherwise people may question why you've set the count to 2.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@xxxxxxxxx
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/