<div dir="ltr">I'm still confused.  Not exactly sure what "wifi single transmitter at time behavior" means.  Is this phy level testing such as <a href="http://www.revolutionwifi.net/revolutionwifi/2011/03/understanding-wi-fi-carrier-sense.html">energy detect and NAV</a>?  Are you trying to consume time "slots" from a transmitter perspective and seeing how that peer device responds w/respect to its transmit scheduling? <br><br>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.)<div><br></div><div>Bob<br><div> </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 30, 2018 at 11:54 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, May 30, 2018 at 11:32 AM, Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.com</a>> wrote:<br>
> Sorry, I may be coming late to this.  What exactly is the goal?  Instead of<br>
> emulating interference with netem is it possible to create real<br>
> interference?<br>
<br>
</span>Interference to me is a secondary, but important part of the problem.<br>
<br>
The core requirement is somehow emulating the single transmitter at a<br>
time behavior of wireless technologies. In this way of thinking, an<br>
interfere-er is just another transmitter in emulation.<br>
<br>
Linux's behaviors are all full duplex, except at the very lowest<br>
driver levels. Being able to move the concept of a<br>
"single bulk transmitter at a time" much higher in stack (at least,<br>
for netem emulation), is what I'd like to do. Being better able to<br>
reliable look at the behaviors of e2e protocols with a decently<br>
correct wireless emulation...<br>
<br>
Does that help? Just getting to where I could describe the problem(s)<br>
well enough to talk about 'em<br>
in the mailing list has taken me forever, and if I/we can get to where<br>
we can describe the problem<br>
better, maybe solutions will materialize. ;)<br>
<br>
Did anyone but me ever play with the slotting models I put into netem last year?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Bob<br>
><br>
> On Wed, May 30, 2018 at 10:28 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>><br>
>> The match to reality of my "wifi slotting" code for netem was so<br>
>> disappointing that I was extremely reluctant to push support for it up<br>
>> to mainline iproute2.<br>
>><br>
>> I've now spent months failing to come up with something that<br>
>> could emulate in linux the non-duplex behavior and arbitration steps<br>
>> that wifi goes through in order to find a new station to transmit to,<br>
>> or receive from, using netem as a base.<br>
>><br>
>> Getting that non-duplex behavior right is the *single most important<br>
>> thing*, I think,  for trying to emulate real wireless behaviors in<br>
>> real time that I can think of (and to thus be able to run and improve<br>
>> various e2e transports against it).<br>
>><br>
>> A potential tc API seems simple:<br>
>><br>
>> tc qdisc add dev veth1 root netem coupled # master (AP)<br>
>> tc qdisc add dev veth2 root netem couple veth1 # client<br>
>> tc qdisc add dev veth3 root netme couple veth2 # client<br>
>><br>
>> Something more complicated would be to create some sort of<br>
>> arbitration device and attach that to the qdiscs. (which would make<br>
>> it more possible to write arbitration devices to emulate lte, gpon,<br>
>> cable, wireless mesh and other non-duplex behaviors in real time)<br>
>><br>
>> But how to convince qdiscs to be arbitrated, only allowing one in a<br>
>> set to transmit at the same time? (and worse, in the long run,<br>
>> allowing MU-MIMO-like behaviors).<br>
>><br>
>> I'm tempted to *not* put my failed thinking down here in the hope that<br>
>> someone says, out there, "oh, that's easy, just create this structure<br>
>> with X API call and use Y function and you're clear of all the<br>
>> potential deadlock and RCU issues, and we've been doing that for<br>
>> years, you idiot! Here's the code for how we do it, sorry we didn't<br>
>> submit it earlier."<br>
>><br>
>> What I thought (*and still think*) is of creating a superset of the<br>
>> qdisc_watchdog_schedule_ns() function is a start at it:<br>
>><br>
>> tag = qdisc_watchdog_create_arb("<wbr>some identifier");<br>
>> qdisc_watchdog_schedule_arb(<wbr>nsec, tag); /* null tag = schedule_ns */<br>
>><br>
>> which doesn't allow that qdisc instance to be run until the arbitrator<br>
>> says it can run (essentially overriding the timeout specified)<br>
>><br>
>> But I actually wouldn't mind something that worked at the veth, or<br>
>> device, rather than qdisc level...<br>
>><br>
>> thoughts?<br>
>><br>
>> PS I just spent several days working on another aspect of the problem,<br>
>> which is replaying delay distributions (caused by interference and<br>
>> such)... and that, sigh, to me, also belongs in some sort of<br>
>> arbitration device rather than directly in netem. Maybe tossing netem<br>
>> entirely is the answer. I don't know.<br>
>><br>
>> --<br>
>><br>
>> Dave Täht<br>
>> CEO, TekLibre, LLC<br>
>> <a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
>> Tel: 1-669-226-2619<br>
>> ______________________________<wbr>_________________<br>
>> Make-wifi-fast mailing list<br>
>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.<wbr>bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/make-wifi-fast</a><br>
><br>
><br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-669-226-2619<br>
</div></div></blockquote></div><br></div>