From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 C4B513BA8E for ; Wed, 30 May 2018 19:26:44 -0400 (EDT) Received: by mail-qk0-x244.google.com with SMTP id a195-v6so13272894qkg.3 for ; Wed, 30 May 2018 16:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PsBDJ7nl3P7nRsAsoZg0McoRlvgTuveRTzN07Dzg1cc=; b=o3t/8k3JGIO1xmxZ4P0iVHnYHsnCUd4ZStS6LbqG4sYmItAbHq+lZSR83LT5LxQEEd iqCTAZ00vf2t1NEbDdIaErloVyywuBndjGqeUk8gBDkM3o5eputl0+6XxmbMt1KUnx0r ARlRUGjR+4f4YoFKUZL7G02rRRZcRr2uatnwxXWMUGPScPNc5YIycKpGNZZl8waAnbTo Eb4gzA5CqUq60FPQCf7F6m5MDX+SDfG54sn7euC2HRD9oIyFrDok1WXYULsMUlBhyUIv +XEMW6/nqY/3qsthcPhf4qFuaP91BNort8CbjFLHlDT8hq2v+Er+Qb0pokBYKZXpc1qX 7zxw== 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:content-transfer-encoding; bh=PsBDJ7nl3P7nRsAsoZg0McoRlvgTuveRTzN07Dzg1cc=; b=OOp/2b7MAOfC8vGvsUa0WFIi1j0ethSUvNQnkXWI3YVDR1/1XqeTfh2tU4MUxkK+W7 PrL7MHEoi/3Rg8S5sthxWmz1uQY+FA5PA3EyzPw0HCRsAzLOr/P47QgAR1LcTY48oMzZ E8PXLpNEmQP+MIRLNjc088lUySFumvZalU9or+DOI9HqUCDlTOPn6BAfewuvTX5BcPw6 NOKkNWAkBjMxzr1BVnlU2NWlpD9sBrzZpsT5FXN+IVeVI1cROa3buF+FnEPDNnQXLbIx Cy4e8a78uObtFEHt/rFQMGv3w/Yb+jlQIi2WbMg+kjr5STFqIWlOiYy3AGbX8WaBgygl OPtQ== X-Gm-Message-State: APt69E2WI+QLrHntxvCkjB5SmbCoC4o11/bQqby+ndJG1IdlQml7Dphs IHknAUjqafLViwcq33CVTKzmHXI6O9JruRocsfc= X-Google-Smtp-Source: ADUXVKL85qmGIcPfM/RRypb3VyVpHv//W0HTTRbyRZ8rSEbCoIRjdcsC51qdjH6QnUadYkR6MPJd2TDcinZxWNTy3T4= X-Received: by 2002:a37:2545:: with SMTP id x66-v6mr4402844qkg.190.1527722804328; Wed, 30 May 2018 16:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:7193:0:0:0:0:0 with HTTP; Wed, 30 May 2018 16:26:43 -0700 (PDT) In-Reply-To: References: From: Dave Taht Date: Wed, 30 May 2018 16:26:43 -0700 Message-ID: To: Bob McMahon Cc: Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 23:26:44 -0000 On Wed, May 30, 2018 at 12:19 PM, Bob McMahon wr= ote: > I'm still confused. Not exactly sure what "wifi single transmitter at ti= me > 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.) That's cool. But *way* lower level than what I'm trying for. take a faked wifi topology like this AP <-> A <-> B <-> C <-> D There are 9 possibilities as to who will transmit where at any given time, with a number of packets and bytes governed by the current rate achieved between the AP and the client (+ multicast). + possible interferers. All the top level queues in linux assume bidirectionality, where here, we don't have that, and we can have arbitrary delays of about 20ms for a burst of traffic (on average, assuming perfect random distribution for access to the medium - and averages lie in this case, and way more stations can be competing than this). And the bursts can range in size from 1 64 byte packet to a few hundred (802.11ac). So the goal with the netem slotting model was to at least accumulate bursts, which it does, and to scale to the randomness and delays common in wifi to various stations (which it doesn't). > 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? Inste= ad >> > 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 la= st >> year? >> >> >> > >> > Bob >> > >> > On Wed, May 30, 2018 at 10:28 AM, Dave Taht wrot= e: >> >> >> >> The match to reality of my "wifi slotting" code for netem was so >> >> disappointing that I was extremely reluctant to push support for it u= p >> >> 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 tha= t >> >> 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 arbitrato= r >> >> 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 > > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619