linux-kernel - Re: [PATCH v2 1/3] mac80211: improve PID rate control mechanism by avoiding rate oscillation problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGRGNgX37DgMzbTjdhQ5LRD_6JwQi8tyN_6VVzYzwQ-KAat4jA@mail.gmail.com>
Date:	Mon, 12 Mar 2012 13:28:14 +1100
From:	Julian Calaby <julian.calaby@...il.com>
To:	wei <yinwei168@...il.com>
Cc:	linux-wireless@...r.kernel.org, johannes@...solutions.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] mac80211: improve PID rate control mechanism by
 avoiding rate oscillation problem

Hi Wei,

On Mon, Mar 12, 2012 at 13:21, wei <yinwei168@...il.com> 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@...il.com
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/