From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 375A43BA8E for ; Wed, 30 May 2018 15:19:57 -0400 (EDT) Received: by mail-wm0-x233.google.com with SMTP id x12-v6so113407wmc.0 for ; Wed, 30 May 2018 12:19:57 -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=QOt6RhYkwJ3ArMCR994nIUoVRkoiE+1ATYLUeJ4qEd0=; b=W4+IZgqJeI5aNMwNcNEu2bogvkvvDKrn/ze5WQQYQK9ExGvVNHlhXjrfEAEjPdaK4z RPboGuxpmGsOprSrZ/uIlEa7r/t7R+5XFIAgzLtC48QGPx6EzZmIbqyGSkKgVHmuGH/b vkne8VQ4vBmNPSYvN5hoI0pZdomNtOihj6QG8= 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=QOt6RhYkwJ3ArMCR994nIUoVRkoiE+1ATYLUeJ4qEd0=; b=fYay7GTrXMhHscwQ9x38tTNYr8fImoUziskdtxKM/9IVQaGKAbaUJrjyVNCLmnmvCs i7q/rpgCGZINWbxvVdkaw3taaUTDgZPf5GhZ22JcJq4CZdzeE+fQsDyx5u5KmwMwxBMc xCz4nhVD/5siy4IDouBCdVtZLHVNW8gBKJ5/o6ei2f1LiBh3CJ5nwGiclK6Tmgg1xvHG FA8CPadekyw0ZjGjywKVkxWNo3ddd0tsV9umRao0S5V9ivv0RL/4NdDUt0BuiA6lq7ys haQqus6e/vEShDbAdxHg+IxIISFrm4C88+2UxrNgi4JefJtbqi3GI1cIrs34I+Om5TC2 A1HA== X-Gm-Message-State: ALKqPwdAvr5BbUmzwROw9TDuf7afZTLkGzSJEGxfv9VDoo1YrAyEfEa1 jnMGEWeSRMk+NLoItda6Py7cJjeQiKvh+IqrqQxQBQ== X-Google-Smtp-Source: ADUXVKJpO8104vL+lV1q1u71Nhu+r9PB+BjOY7yFoa0Aar1pGxMoqhguVSBV7uWPGnc9n2EYhvWq637sZobtDeXFrSI= X-Received: by 2002:aa7:d3d7:: with SMTP id o23-v6mr4818064edr.104.1527707996240; Wed, 30 May 2018 12:19:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8934:0:0:0:0:0 with HTTP; Wed, 30 May 2018 12:19:55 -0700 (PDT) In-Reply-To: References: From: Bob McMahon Date: Wed, 30 May 2018 12:19:55 -0700 Message-ID: To: Dave Taht Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000006fe0de056d713cba" 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 19:19:57 -0000 --0000000000006fe0de056d713cba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? Instea= d > 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 las= t > 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 =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 > > > > > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > --0000000000006fe0de056d713cba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm still confused.=C2=A0 Not exactly sure what "= wifi single transmitter at time behavior" means.=C2=A0 Is this phy lev= el testing such as energy detect and NAV?= =C2=A0 Are you trying to consume time "slots" from a transmitter = perspective and seeing how that peer device responds w/respect to its trans= mit scheduling?=C2=A0

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 c= hip not released.)

Bob
=C2=A0
<= div class=3D"gmail_extra">
On Wed, May 30, 20= 18 at 11:54 AM, Dave Taht <dave.taht@gmail.com> wrote:
=
On Wed, May 30, 2018 at 11:= 32 AM, Bob McMahon <bob.mcma= hon@broadcom.com> wrote:
> 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 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 leas= t,
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@gmail.com> wrote:
>>
>> The match to reality of my "wifi slotting" code for nete= m was so
>> disappointing that I was extremely reluctant to push support for i= t 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 ste= ps
>> 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 importa= nt
>> thing*, I think,=C2=A0 for trying to emulate real wireless behavio= rs in
>> real time that I can think of (and to thus be able to run and impr= ove
>> 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 mak= e
>> it more possible to write arbitration devices to emulate lte, gpon= ,
>> cable, wireless mesh and other non-duplex behaviors in real time)<= br> >>
>> 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 h= ope that
>> someone says, out there, "oh, that's easy, just create th= is 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 f= or
>> years, you idiot! Here's the code for how we do it, sorry we d= idn't
>> submit it earlier."
>>
>> What I thought (*and still think*) is of creating a superset of th= e
>> 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 sched= ule_ns */
>>
>> which doesn't allow that qdisc instance to be run until the ar= bitrator
>> 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 prob= lem,
>> 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 ne= tem
>> 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/lis= tinfo/make-wifi-fast
>
>



--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619

--0000000000006fe0de056d713cba--