Johannes Berg writes:
>> > Perhaps then it should just be fractional? i.e. 8.8 bits or so?, so
>> > the default would be 1.0 (0x0100) and then you could scale down to 0.5
>> > (0x0080) etc?
>>
>> Hmm, that's an interesting idea. I'll have to run some numbers to see
>> how the precision holds up
On Wed, 2018-08-29 at 12:33 +0200, Toke Høiland-Jørgensen wrote:
> > > Hmm, the problem with a higher weight is that weight*quantum becomes the
> > > time each station is scheduled, so having a higher value means higher
> > > latency. This could be fixed by replacing the station weights with
> >
Johannes Berg writes:
> On Wed, 2018-08-29 at 11:27 +0200, Toke Høiland-Jørgensen wrote:
>
>> Hmm, the problem with a higher weight is that weight*quantum becomes the
>> time each station is scheduled, so having a higher value means higher
>> latency. This could be fixed by replacing the station
On Wed, 2018-08-29 at 11:27 +0200, Toke Høiland-Jørgensen wrote:
> Hmm, the problem with a higher weight is that weight*quantum becomes the
> time each station is scheduled, so having a higher value means higher
> latency. This could be fixed by replacing the station weights with
> per-station
Johannes Berg writes:
> On Mon, 2018-07-09 at 18:37 +0200, Toke Høiland-Jørgensen wrote:
>>
>> @@ -427,6 +428,8 @@ struct sta_info *sta_info_alloc(struct
>> ieee80211_sub_if_data *sdata,
>> sta->cparams.interval = MS2TIME(100);
>> sta->cparams.ecn = true;
>>
>> +
On Mon, 2018-07-09 at 18:37 +0200, Toke Høiland-Jørgensen wrote:
>
> @@ -427,6 +428,8 @@ struct sta_info *sta_info_alloc(struct
> ieee80211_sub_if_data *sdata,
> sta->cparams.interval = MS2TIME(100);
> sta->cparams.ecn = true;
>
> + sta->airtime.weight = 1;
Perhaps it might be
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new callback, ieee80211_sta_register_airtime(), is added
that drivers can call to report airtime usage for stations, and an
extended feature flag is added that drivers can use to opt into airtime
fairness scheduling.
