[Bloat] emulating non-duplex media in linux qdiscs

[Luca Muscariello]

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=vicn/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 <dave.taht at gmail.com> 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äht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171010/0c4119b1/attachment.html>