<div dir="ltr">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?<br><br>Bob</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 30, 2018 at 10:28 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">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>
<span class="HOEnZb"><font color="#888888"><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></font></span></blockquote></div><br></div>