From: Y <intruder_tkyf@yahoo.fr>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] emulating non-duplex media in linux qdiscs
Date: Mon, 9 Oct 2017 22:09:55 +0900 [thread overview]
Message-ID: <1545372c-86df-2c03-72c1-d7f146ae6b16@yahoo.fr> (raw)
In-Reply-To: <CAA93jw6qwOgrnqxmPtBY2kOKY8gM24ZZg=86yZvMeMSUrVRbRA@mail.gmail.com>
Interesting :)
On 2017年10月09日 10:54, 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....
>
next prev parent reply other threads:[~2017-10-09 13:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 1:54 Dave Taht
2017-10-09 7:41 ` erik.taraldsen
2017-10-09 16:53 ` Dave Taht
2017-10-09 19:05 ` Andrew Shewmaker
2017-10-10 7:02 ` Mikael Abrahamsson
2017-10-10 8:38 ` erik.taraldsen
2017-10-10 13:21 ` Michael Richardson
2017-10-09 13:09 ` Y [this message]
2017-10-09 20:21 ` Stephen Hemminger
2017-10-09 21:04 ` Michael Richardson
2017-10-10 9:25 ` Luca Muscariello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1545372c-86df-2c03-72c1-d7f146ae6b16@yahoo.fr \
--to=intruder_tkyf@yahoo.fr \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox