From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Dave Taht <dave@taht.net>
Cc: erik.taraldsen@telenor.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] emulating non-duplex media in linux qdiscs
Date: Tue, 10 Oct 2017 09:02:41 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1710100848030.31961@uplift.swm.pp.se> (raw)
In-Reply-To: <87376s6z5z.fsf@nemesis.taht.net>
On Mon, 9 Oct 2017, Dave Taht wrote:
> Saying that is half duplex, doesn't work for me. In their example of
> "half duplex", (using push to talk), it still means that everybody on
> that channel hears who is talking. "half duplex" to me, given the
> definition of duplex, means more that there is a *p2p* channel (a wire),
> that you can ping pong data across.
A 10base-T hub connected to a 10base-2 or 10base-5 segment, all in the
same broadcast domain, is considered to be "half duplex" in ethernet port
configuration term.
So it doesn't have to be p2p. And I do think this mimics a shared radio as
well (because a coax wire with multiple nodes on it seems very similar to
a radio channel over the air).
Now, radio has the difference that two stations might not hear each other,
and that's of course a problem in CSMA/CD terms.
Back to your netem problem. What you need is to force all packets through
the same queue, right? So I tried to dream up a complicated scheme with 4
bridges and some kind of "forced forwarding", but I don't think it'd pan
out.
So the best way is probably to have a shaper that feeds
transmit-tokens/does scheduling into two different shapers (rx/tx on the
same interface). So whatever scheduling they are fed in order to tell them
the rate they're allowed to transmit, they get it from the same source.
That way they have to compete for the same resources.
This will not perfectly mimic the exponential backoff of CSMA/CD, but it
might be good enough for what you need? Also, I just realised I have no
idea how wifi is scheduled. Is it even close to CSMA/CD?
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2017-10-10 7:02 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 [this message]
2017-10-10 8:38 ` erik.taraldsen
2017-10-10 13:21 ` Michael Richardson
2017-10-09 13:09 ` Y
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=alpine.DEB.2.20.1710100848030.31961@uplift.swm.pp.se \
--to=swmike@swm.pp.se \
--cc=bloat@lists.bufferbloat.net \
--cc=dave@taht.net \
--cc=erik.taraldsen@telenor.com \
/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