From: Jonathan Morton <chromatix99@gmail.com>
To: Azin Neishaboori <azin.neishaboori@gmail.com>
Cc: bloat-devel@lists.bufferbloat.net
Subject: Re: monitoring queue length
Date: Sat, 1 Dec 2018 05:13:41 +0200 [thread overview]
Message-ID: <3D0D58C0-B601-413B-B3EA-80C396E6187B@gmail.com> (raw)
In-Reply-To: <CADXq5+--g2-oOsgrhKwBCDYZxtDAkhAmfT-vE1mmrcsb74CiEQ@mail.gmail.com>
> On 1 Dec, 2018, at 12:05 am, Azin Neishaboori <azin.neishaboori@gmail.com> wrote:
>
> I do not know if this backlog is indeed queue length or not. It seems strange to be queue length, because even when I flood the network with high UDP data rates over capacity, it still shows 0b of backlog. Am I looking at the wrong parameter? If so, could you please point out the tool that shows the instantaneous queue length?
There are two potential points of confusion here:
1: Linux throttles both TCP and UDP at the application socket level to prevent queues building up in the qdiscs and HW devices. If it's your machine producing the packets, that's probably the effect you're seeing; there'll be a few packets queued in the HW (invisibly) and none in the qdisc. That's approximately true regardless of which qdisc is in use, though with a shaping qdisc you might see a few packets collect there instead of in the HW.
2: If your traffic is coming from outside, it won't be queued upon receipt unless you introduce an artificial bottleneck. There are ways of doing that.
For queuing experiments, we normally set up a "dumbbell" topology in which two different machines act as source and drain of traffic, and a third machine in the middle acts as a network emulator with artificial delays, losses and bandwidth limits. That middlebox is where you would then observe the queuing.
- Jonathan Morton
next prev parent reply other threads:[~2018-12-01 3:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 22:05 Azin Neishaboori
2018-12-01 3:13 ` Jonathan Morton [this message]
2018-12-01 7:37 ` Azin Neishaboori
2018-12-01 7:47 ` Jonathan Morton
2018-12-01 8:04 ` Azin Neishaboori
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D0D58C0-B601-413B-B3EA-80C396E6187B@gmail.com \
--to=chromatix99@gmail.com \
--cc=azin.neishaboori@gmail.com \
--cc=bloat-devel@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