[Make-wifi-fast] emulating wifi better - coupling qdiscs in netem?

[Dave Taht]

On Wed, May 30, 2018 at 11:32 AM, Bob McMahon <bob.mcmahon at broadcom.com> wrote:
> Sorry, I may be coming late to this.  What exactly is the goal?  Instead of
> emulating interference with netem is it possible to create real
> interference?

Interference to me is a secondary, but important part of the problem.

The core requirement is somehow emulating the single transmitter at a
time behavior of wireless technologies. In this way of thinking, an
interfere-er is just another transmitter in emulation.

Linux's behaviors are all full duplex, except at the very lowest
driver levels. Being able to move the concept of a
"single bulk transmitter at a time" much higher in stack (at least,
for netem emulation), is what I'd like to do. Being better able to
reliable look at the behaviors of e2e protocols with a decently
correct wireless emulation...

Does that help? Just getting to where I could describe the problem(s)
well enough to talk about 'em
in the mailing list has taken me forever, and if I/we can get to where
we can describe the problem
better, maybe solutions will materialize. ;)

Did anyone but me ever play with the slotting models I put into netem last year?


>
> Bob
>
> On Wed, May 30, 2018 at 10:28 AM, Dave Taht <dave.taht at gmail.com> wrote:
>>
>> The match to reality of my "wifi slotting" code for netem was so
>> disappointing that I was extremely reluctant to push support for it up
>> to mainline iproute2.
>>
>> I've now spent months failing to come up with something that
>> could emulate in linux the non-duplex behavior and arbitration steps
>> that wifi goes through in order to find a new station to transmit to,
>> or receive from, using netem as a base.
>>
>> Getting that non-duplex behavior right is the *single most important
>> thing*, I think,  for trying to emulate real wireless behaviors in
>> real time that I can think of (and to thus be able to run and improve
>> various e2e transports against it).
>>
>> A potential tc API seems simple:
>>
>> tc qdisc add dev veth1 root netem coupled # master (AP)
>> tc qdisc add dev veth2 root netem couple veth1 # client
>> tc qdisc add dev veth3 root netme couple veth2 # client
>>
>> Something more complicated would be to create some sort of
>> arbitration device and attach that to the qdiscs. (which would make
>> it more possible to write arbitration devices to emulate lte, gpon,
>> cable, wireless mesh and other non-duplex behaviors in real time)
>>
>> But how to convince qdiscs to be arbitrated, only allowing one in a
>> set to transmit at the same time? (and worse, in the long run,
>> allowing MU-MIMO-like behaviors).
>>
>> I'm tempted to *not* put my failed thinking down here in the hope that
>> someone says, out there, "oh, that's easy, just create this structure
>> with X API call and use Y function and you're clear of all the
>> potential deadlock and RCU issues, and we've been doing that for
>> years, you idiot! Here's the code for how we do it, sorry we didn't
>> submit it earlier."
>>
>> What I thought (*and still think*) is of creating a superset of the
>> qdisc_watchdog_schedule_ns() function is a start at it:
>>
>> tag = qdisc_watchdog_create_arb("some identifier");
>> qdisc_watchdog_schedule_arb(nsec, tag); /* null tag = schedule_ns */
>>
>> which doesn't allow that qdisc instance to be run until the arbitrator
>> says it can run (essentially overriding the timeout specified)
>>
>> But I actually wouldn't mind something that worked at the veth, or
>> device, rather than qdisc level...
>>
>> thoughts?
>>
>> PS I just spent several days working on another aspect of the problem,
>> which is replaying delay distributions (caused by interference and
>> such)... and that, sigh, to me, also belongs in some sort of
>> arbitration device rather than directly in netem. Maybe tossing netem
>> entirely is the answer. I don't know.
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619