From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 111683BA8E for ; Tue, 10 Oct 2017 05:25:21 -0400 (EDT) Received: by mail-qt0-x233.google.com with SMTP id k31so13887039qta.6 for ; Tue, 10 Oct 2017 02:25:21 -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; bh=Dxvc9Svb1BUIZeMq8G/MiOELoHubdGTDqCGMZLjb1hk=; b=cNhNYsEihiFXnVwAoshH6YpHUpb/DW4XPpa023W/bpPPfFEOJiIK2NSz96Qm6M6Y2a //cTv142ujT43GQ5XB31QzTRfN6Vo7FUwzKC7lnwZyYx5m0OdquS6i7jZomxP4yBXhio nrOjr9aq3SPKHwCnHHI3P/DzMIrpZyxZE9dkL9x6Lt4/UfAcD2KUmgwh+EEnxQmnd5WS 5qenRpDJun1fDM8+vHR4dYIJE/Yt9UvS6dN6KvbR95WOYQo1DPzAxdHwKqMGQGUrbG9R 8/WPW7Q4JaBjQMhoKU5d6jzH5mBGRNwN+GGOuiNTa48iDJwSgXxg+RROIA0rlUawYb+T /K1w== 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=Dxvc9Svb1BUIZeMq8G/MiOELoHubdGTDqCGMZLjb1hk=; b=JbQMNrH7th/CygSlnD+1BL7xc2ZS7rAviGAVA5DUbiPO0kTgmypqNrBG+EInxCfKUU v4CrGrtrGSX3CAmEmrJM9eE0PYtRb4ab08ODluN4/pIV8BXUjZMTqeQkZz53K+XTOxnQ qE/WZxZRFZNTO2SHbR7zjujIAjTPRbVhA5h8MVaCOWtwfFlz6/xk5daDbMqMRWE86O2Z bKpJHxFVexNKFtHuhdo5+OB4rN/VBrFj/xeGxRvBtfs+BiJb+MuQIu3ciazdTw9rD1TZ We/iupzjDdR23AjhVpGSrZvYUllDmhyLhHbU0QwnmL+KbDSMtLqSPbV/Z1G2PnrF6o8i LKfA== X-Gm-Message-State: AMCzsaWEf9agvhOeRBivF0FRMU1/AkUQFfhymFFsIiKEDtYSUQy4xnT1 OXat2nqOYIIoXr7wKLKeOdy6frNN8BVG1mwBrV4= X-Google-Smtp-Source: AOwi7QD2CLB3gsgH/MfwOynax3KnEf/yuyBUVTLP0gq0z5mxqNbnednRUu1Z70x5zCJyoZMRZMVvRaDfY9iXnPZFMr8= X-Received: by 10.55.110.196 with SMTP id j187mr10540099qkc.192.1507627520535; Tue, 10 Oct 2017 02:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.152.236 with HTTP; Tue, 10 Oct 2017 02:25:20 -0700 (PDT) In-Reply-To: References: From: Luca Muscariello Date: Tue, 10 Oct 2017 11:25:20 +0200 Message-ID: To: Dave Taht Cc: bloat Content-Type: multipart/alternative; boundary="94eb2c05b69ad0b300055b2de2a3" Subject: Re: [Bloat] emulating non-duplex media in linux qdiscs X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:25:21 -0000 --94eb2c05b69ad0b300055b2de2a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dave, If the objective is to run experiments with some emulated wifi I could suggest a workaround that we are using. It is not based on qdisc only. It is based on ns3 emulation and linux bridges. https://git.fd.io/cicn/tree/emu-radio/README.md?h=3Dvicn/master The radio emulation piece includes 802.11n and LTE. For wifi you get the contention behaviour you're looking for and listen before talk etc. You also get the TX or RX behaviour. There is also the propagation models from ns3 (fast/slow fading, etc. etc.). The radio piece is a single Linux process so depending on the scaling you're looking for this tool might or might not be useful. In the repo, there is some documentation, but if you plan to use this stuff and need help let me know. There is also a ML, in case it helps. Luca On Mon, Oct 9, 2017 at 3:54 AM, Dave Taht wrote: > I have been hacking away at netem for a while now in the hope that > eventually - with a great deal more hacking - it could be used to more > accurately emulate shared media like wifi and lte. > > (Some people try to describe these as simplex (which is not true > because you can have multiple destinations), and they certainly are > not duplex, so I tend to say non-duplex and still hope some better > word emerges) > > So... one sticking point for me has been wanting to emulate the fact > that on shared media, that you cannot transmit and receive at the same > time; that these are "coupled" events, and what I'd like to be able to > express might be something like: > > tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier > ... some tc mirred magic for ifb here ... > tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier > > "some_identifier" would be a mutex of some sort, and I confess to > not having much grip on the kernel outside of the net/sched directory. > > What facility would be best to try and leverage? It would be created > (globally) on first use, ref-counted (thus destroyed when it goes to > zero), atomically updated... posix shared memory seems too heavyweight > to use.... > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --94eb2c05b69ad0b300055b2de2a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave,

If the objective is to run experi= ments with some emulated wifi I could suggest=C2=A0
a workaround = that we are using. It is not based on qdisc only.

= It is based on ns3 emulation and linux bridges.

h= ttps://git.fd.io/cicn/tree/emu-radio/README.md?h=3Dvicn/master

The radio emulation piece includes 802.11n and LTE.
For wifi you get the contention behaviour you're looking for an= d listen before talk etc.
You also get the TX or RX behaviour. Th= ere is also the propagation models from ns3 (fast/slow fading, etc. etc.).<= /div>

The radio piece is a single Linux process so depen= ding on the scaling you're looking for this tool
mig= ht or might not be useful.

In the repo, ther= e is some documentation, but if you plan to use this stuff and need help le= t me know.
There is also a ML, in case it helps.=C2=A0
=
Luca




On Mon, Oct 9, 2= 017 at 3:54 AM, Dave Taht <dave.taht@gmail.com> wrote:
=
I have been hacking away at netem for a whil= e now in the hope that
eventually - with a great deal more hacking - it could be used to more
accurately emulate shared media like wifi and lte.

(Some people try to describe these as simplex (which is not true
because you can have multiple destinations), and they certainly are
not duplex, so I tend to say non-duplex and still hope some better
word emerges)

So... one sticking point for me has been wanting to emulate the fact
that on shared media, that you cannot transmit and receive at the same
time; that these are "coupled" events, and what I'd like to b= e able to
express might be something like:

tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
... some tc mirred magic for ifb here ...
tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier
"some_identifier" would be a mutex of some sort, and I confess to=
not having much grip on the kernel outside of the net/sched directory.

What facility would be best to try and leverage? It would be created
(globally) on first use, ref-counted (thus destroyed when it goes to
zero), atomically updated... posix shared memory seems too heavyweight
to use....

--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--94eb2c05b69ad0b300055b2de2a3--