[Make-wifi-fast] [PATCH v2 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue
moeller0 at gmx.de
Sat Oct 19 10:01:38 EDT 2019
On October 19, 2019 2:14:42 PM GMT+02:00, "Toke Høiland-Jørgensen" <toke at redhat.com> wrote:
>Sebastian Moeller <moeller0 at gmx.de> writes:
>>> On Oct 18, 2019, at 16:15, Johannes Berg <johannes at sipsolutions.net>
>>> On Thu, 2019-10-17 at 18:11 -0700, Kan Yan wrote:
>>>> I don't think it is hard to take care of extra header size for
>>>> with VLAN tags
>>> VLAN tags are payload as far as wifi is concerned, so no need to
>>> that into account ...
>> Ah, good to know; but just out of curiosity is any of the
>> following 7 Byte Preamble + 1 Byte start of frame delimiter
>> (SFD) + 12 Byte inter frame gap (IFG) actually packaged into
>> ethernet frames inside 802.11 packets? I would have guessed that
>> at least the IFG would be dropped as it does not really exist as
>No, those are accounted in the airtime calculation in airtime.c (Felix'
> duration = 20 + 16; /* premable + SIFS */
Looks like apples and pears to me. These seem to be the wifi preamble and short interframe space in microseconds. Sure you need to add those to the airtime estimate as these will hog airtime.
But the 12 byte interframe gap of the Ethernet packets that are transmitted over a 802.11 link surely will not be actually transmitted as a stretch of zeros? Same for the Ethernet preamble and the start of frame marker, as those can/will be trivially added by the Ethernet NIC that will handle the encapsulated Ethernet frame after the wifi link, no?
As far as I can tell, the wifi SIFS is constant time independent of wifi link speed while the IFG size is constant but it's duration is not?
Again, I am trying to understand this conceptually, which seems orthogonal to the question of whether 38 is the correct number....
P.S.: Is there a repository I could look into to try to figure this out myself?
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Make-wifi-fast