From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 48CF23BA8E for ; Wed, 30 May 2018 13:28:45 -0400 (EDT) Received: by mail-qk0-x22a.google.com with SMTP id c198-v6so15001715qkg.12 for ; Wed, 30 May 2018 10:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=u1yhX8LKY26mrYifHuhWYWdXMQsJtIXchIfoL2a/TAA=; b=Sq5cGgPQiPLpsxm0sWvn/Ha8zeGGAa0LWtYhglUZzXV46+0vO8iVWQSuIXLAa3zsCk P2HxLZEA2ajhIYaZiacwig5BMsD65vMGKTTBZXqqbefcJwU8/ixaX+4xIY2FL3hIgHoz Mxs6MNfsbQg04Q5rs3fk5UOZRfZuAmaWjnXYdoqlp0NKg7mXotgFNy/DaD0M+vBJNYGZ kIhpqqgduefh6JfcXN2U8K2l9knE/nbOHGuXtqEVny0BCoUiXxCSkxMQJk6TUAFMLU24 AUESVATZIPlxFegoStBthNb5jcYRc0umrV//uiPAaXydvPWansJSRuKm1i+6vdZ5WS1z sHsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=u1yhX8LKY26mrYifHuhWYWdXMQsJtIXchIfoL2a/TAA=; b=WWk9Vo5xeFDTa4KxyjAzCyA97fe7f6ECQsCSduujJDncWzodKx9dWD6GUmJ+601SJw HFtTP/cdTo1Qtp7MHg4kPt7USfY4NRI22PP6pJdQTuLRP26lsZeTwayvG4q1ocwQusBd J3IAUf0OSduvEwLCT1X+KuVB/zM6nSgNS4E6LDSqEhWtPkLWGhjjq6uHYDPdJOXcY+yF NL5C+UT1HvzLrgywLpZb/5EVL0sbQfXc9MlV6C7QstMIdmC9NGFTX0vw6glCqjcvIrPQ 7HIckucrxzlw23O9Ac+BEpBoQBMmfdQwj9GnQ/Z+9fi41KP8wShJl3lnE7e6Kx065W6h 1c+A== X-Gm-Message-State: APt69E1deVAlfkmC7kh9e6N+/UieshG/JrbV69y3GnOZMxGtrczMOEvV gwd+sw4TO1sd+jN34/G12I+lRtA6femKVSi2TG4= X-Google-Smtp-Source: ADUXVKKBD8f//XZ4pOI2umJC7o3BBqHKTMvVUzQG6pEIY8JFBaRhIhVOnYKQh/OY7agkI0p7Zzk7FvtEGALW0kgpTEE= X-Received: by 2002:a37:ef0d:: with SMTP id j13-v6mr3205182qkk.263.1527701324458; Wed, 30 May 2018 10:28:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:7193:0:0:0:0:0 with HTTP; Wed, 30 May 2018 10:28:43 -0700 (PDT) From: Dave Taht Date: Wed, 30 May 2018 10:28:43 -0700 Message-ID: To: make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [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 17:28:45 -0000 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. --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619