General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Collier-Brown <dave.collier-brown@indexexchange.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] [Cerowrt-devel] uplink bufferbloat and scheduling problems
Date: Thu, 2 Dec 2021 12:20:37 -0500	[thread overview]
Message-ID: <5f2d6491-c153-52db-0992-a90d73ec8831@indexexchange.com> (raw)
In-Reply-To: <alpine.DEB.2.02.2112011307210.6080@nftneq.ynat.uz>

On 12/1/21 16:09, David Lang wrote:

> On Wed, 1 Dec 2021, David P. Reed wrote:
>
>> To say it again: More memory *doesn't* improve throughput when the
>> queue depths exceed one packet on average
>
> slight disagreement here. the buffer improves throughput up to the
> point where it handles one burst of packets. When packets are
> transmitted individually, that's about one packet (insert hand waving
> about scheduling delays, etc). but with wifi where you can transmit
> multiple packets in one airtime slot, you need enough buffer to handle
> the entire burst.


A different hand-wave: what about "packet trains"? They make using
queuing networks mis-estimate, do they come close together enough that
routers need to be sensitive to them, and affect the number of packets
they need to buffer?

--dave

--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

  parent reply	other threads:[~2021-12-02 17:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01  0:13 [Bloat] " Dave Taht
2021-12-01 20:26 ` [Bloat] [Cerowrt-devel] " David P. Reed
2021-12-01 21:06   ` David Lang
2021-12-01 21:09   ` David Lang
2021-12-01 22:28     ` Valdis Klētnieks
2021-12-02  0:10       ` Toke Høiland-Jørgensen
2021-12-02  9:09         ` David Lang
2021-12-02 17:20     ` Dave Collier-Brown [this message]
2021-12-02 19:33       ` David Lang
2021-12-02  8:11   ` Jan Ceuleers
2021-12-02  8:45   ` Sebastian Moeller

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=5f2d6491-c153-52db-0992-a90d73ec8831@indexexchange.com \
    --to=dave.collier-brown@indexexchange.com \
    --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