From: "Nicolas Escande" <nico.escande@gmail.com>
To: "Remi Pommarel" <repk@triplefau.lt>,
"Linus Lüssing" <linus.luessing@c0d3.blue>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH RFC 2/2] batman-adv: Better half duplex penalty estimation
Date: Wed, 18 Oct 2023 23:37:43 +0200 [thread overview]
Message-ID: <CWBW1FS4IRH7.JIAIOB8DVNK7@gmail.com> (raw)
In-Reply-To: <ZTA40fGA-NSvYkoq@pilgrim>
On Wed Oct 18, 2023 at 9:58 PM CEST, Remi Pommarel wrote:
> [...]
> >
> > Also, this seems to assume that time slices are divided equally.
> > That's probably only be true for WiFi drivers that have airtime
> > fairness changes integrated? So only recent versions of mt76,
> > ath9k and ath10k? Has anyone verified that this works fine not
> > only in AP but also in 11s mode?
>
> I don't know how that would behave on setup that does not have airtime
> fairness changes integrated, if you think the current dividing by two
> approach is better maybe this can be made a configurable option but that
> could be tricky ?
It seems to me that airtime fairness is something that most current drivers aim
at doing. Even the mac80211 scheduler is going this route with the itxq work.
So I feel like we should assume that with time, most drivers will be.
And devices that do not respect airtime fairness will probably not match the
current TP/2 rule either.
> [...]
> >
> > And a third concern, but we'd probably have this issue with both
> > our current and your suggestion: Would we be off again 802.11be
> > and its "Multi-Link Operation" in the future?
>
> This, I have hard time figuring out how MLO would play along with
> B.A.T.M.A.N-Adv integration. Unfortunately right now I have no way
> to experiment that yet. IIUC the link would be a mix between half and
> full duplex, and this would probably complicate things a bit.
>
> Thanks a lot for your review.
For me MLO is hard to take into account. Depending on the drivers (and probably
on the firmwares mostly) we do not know if it is/will be used as a real
aggregation mechanism or as a way to have 'free' roaming between multiple bands.
Moreover, currently all the path throughput estimation is based on the expected
throuput that the 80211 stack gives us for individual sta. I beleive that very
few drivers actually provide a value for it.
So IMHO we should do our best to have a good path estimation based on the sta
estimated throughput, and it should be the mac80211 drivers job to provide us
with an accurate estimated throughput for each sta on a link. And yes in the MLO
case it will be a hard job indeed...
next prev parent reply other threads:[~2023-10-18 21:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 12:39 [PATCH RFC 0/2] Better throughput estimation on half duplex interfaces Remi Pommarel
2023-09-28 12:39 ` [PATCH RFC 1/2] batman-adv: Keep half duplex penalty on OGM receiving side also Remi Pommarel
2023-09-28 12:39 ` [PATCH RFC 2/2] batman-adv: Better half duplex penalty estimation Remi Pommarel
2023-10-14 5:10 ` Linus Lüssing
2023-10-14 6:03 ` Linus Lüssing
2023-10-18 19:58 ` Remi Pommarel
2023-10-18 21:37 ` Nicolas Escande [this message]
2023-10-14 6:24 ` Linus Lüssing
2023-09-28 15:33 ` [PATCH RFC 0/2] Better throughput estimation on half duplex interfaces Marek Lindner
2023-09-28 16:48 ` Remi Pommarel
2023-09-28 17:54 ` Remi Pommarel
2023-09-28 18:10 ` Marek Lindner
2023-09-28 19:16 ` Remi Pommarel
2023-10-03 21:06 ` Marek Lindner
2023-10-11 8:55 ` Remi Pommarel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CWBW1FS4IRH7.JIAIOB8DVNK7@gmail.com \
--to=nico.escande@gmail.com \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=linus.luessing@c0d3.blue \
--cc=repk@triplefau.lt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.