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

[Bob McMahon]

I'm still confused.  Not exactly sure what "wifi single transmitter at time
behavior" means.  Is this phy level testing such as energy detect and NAV
<http://www.revolutionwifi.net/revolutionwifi/2011/03/understanding-wi-fi-carrier-sense.html>?
Are you trying to consume time "slots" from a transmitter perspective and
seeing how that peer device responds w/respect to its transmit scheduling?

To move the noise floor on either a peer RX or TX we just send tones for a
duration on a frequency band at a power level without worrying about any
slotting (but that's a special tool in our chip not released.)

Bob


On Wed, May 30, 2018 at 11:54 AM, Dave Taht <dave.taht at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20180530/c72234d1/attachment-0001.html>