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 ? 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 wrote: > On Wed, May 30, 2018 at 11:32 AM, Bob McMahon > 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 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@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 >