From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DDF8C3BA8E for ; Wed, 30 May 2018 14:32:23 -0400 (EDT) Received: by mail-wm0-x229.google.com with SMTP id a8-v6so49506965wmg.5 for ; Wed, 30 May 2018 11:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V9vVD0i4nn+x+9C+Ty+rcpUdAGECOsU1KHm6qRQIx5g=; b=c88y8MXfg91b8qtvUUdLNNb8JmH7GBV/8GbTwGQIPrL16gLYeEF4RtkuDiaNj2ApQR rudU2hY86HZ1uMxaPvPOXY7Newm5eASkY6KokrdT0Bs8FhcbnNXi013eu6o1yu5Y0L8z KyOmzdch+nX4TpaAzf3PzccMJ1e3xfETCbyOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V9vVD0i4nn+x+9C+Ty+rcpUdAGECOsU1KHm6qRQIx5g=; b=AsUN6qjx70l0io1V+tTRXlK1axfI4ecND+iw+06UlLBYNEhPhTWg/S/mz1Kg0vP/NG 1ebVKKn+ZDorlYCmmxpZuGRq9YKeNIMyNI+kZNHjuHzrCnAbiXXAErAFTEdRd8EnJ6vz 0NqNqLM2VaL+PCaNFpuPo9nqw23tWSJyQdyGoXahIy91FzfqTrdUJQWp8uGhN7joD+Ov sAu+YwXkEw9weqodRj4GUunPkGgmyjMfvku21QIOjsBU5AY7zF4aE5+jUXyTlt/x5qY6 rgBCg1zZZJDcRrVelkYivdca4FS+Rev4YrLmYoGPiuJSRIBMaqvb9xNI0E3memacnnOH KDNA== X-Gm-Message-State: ALKqPwd3SPTfcVSkysnXCcUCVz+pxj7J7i4kaj0QNB+KaTDhoE2GqlQJ odN4zR7s1UM/zHZHkmrNjU0OiCegMOcLsO417dovpA== X-Google-Smtp-Source: ADUXVKLM8nFU3gDNGuUXAFWSoAAMiZdQ0AWbB3q49sHkB2yO5A3fCyViG6Vlqi+jmJAWR4ONI/o4HB7PRgrhEDwIhIo= X-Received: by 2002:aa7:d3d7:: with SMTP id o23-v6mr4683616edr.104.1527705142856; Wed, 30 May 2018 11:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8934:0:0:0:0:0 with HTTP; Wed, 30 May 2018 11:32:22 -0700 (PDT) In-Reply-To: References: From: Bob McMahon Date: Wed, 30 May 2018 11:32:22 -0700 Message-ID: To: Dave Taht Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000005cb42e056d709225" Subject: Re: [Make-wifi-fast] emulating wifi better - coupling qdiscs in netem? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 18:32:24 -0000 --0000000000005cb42e056d709225 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? 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 =3D qdisc_watchdog_create_arb("some identifier"); > qdisc_watchdog_schedule_arb(nsec, tag); /* null tag =3D 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=C3=A4ht > 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 --0000000000005cb42e056d709225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I may be coming late to this.=C2=A0 What exactly is= the goal?=C2=A0 Instead of emulating interference with netem is it possibl= e to create real interference?

Bob
<= br>
On Wed, May 30, 2018 at 10:28 AM, Dave Taht <= span dir=3D"ltr"><dave.taht@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,=C2=A0 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<= br> someone says, out there, "oh, that's easy, just create this struct= ure
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 =3D qdisc_watchdog_create_arb("some identifier");
qdisc_watchdog_schedule_arb(nsec, tag); /* null tag =3D schedule_ns */=

which doesn't allow that qdisc instance to be run until the arbitrator<= br> 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=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--0000000000005cb42e056d709225--