From: Sebastian Moeller <moeller0@gmx.de>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Simon Barber <simon@superduper.net>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] buffer sizing meeting notes
Date: Sat, 24 Aug 2019 09:59:36 +0200 [thread overview]
Message-ID: <36973E7C-0B93-4512-AB0B-917C807E9684@gmx.de> (raw)
In-Reply-To: <20190824095453.1a15ca5a@carbon>
Another nugget from the notes (http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/):
Chuanxiong Guo, Bytedance
Talked about buffering in Bytedance’s datacenters. The top of rack switches have buffers of 12-32MB, and the aggregation switches have larger buffers of several GB. Were hoping to use ECN to reduce buffers for aggregation switches, but argued that precise ECN marking on egress queue length in VoQs is hard. However, Arista and Barefoot said they’ve fixed this using the packet latency instead of queue length for ECN.
This looks like an argument for fq_codel/cake's use of time instead of queue length, OR an argument for fq, because in a non-overwhelmed fq_system the local bucket's queue length should be somewhat stronger correlated with the sojurn times, than the sojurn time of a packet though a shared queue, no?
Best Regards
Sebastian
> On Aug 24, 2019, at 09:54, Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>
> On Fri, 23 Aug 2019 10:13:39 -0700
> Simon Barber <simon@superduper.net> wrote:
>
>>> On Aug 23, 2019, at 9:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> There's some good preso from various representatives in the dc market here.
>>>
>>> The p4 stuff, in particular (from barefoot) is looking impressive.
>>>
>>> http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/
>
> I followed the link to the animation of AIMD (Additive
> Increase/Multiplicative Decrease), that was really cool!
>
> https://dabh.github.io/network_animations/
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2019-08-24 7:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-23 16:07 Dave Taht
2019-08-23 17:13 ` Simon Barber
2019-08-23 17:24 ` Dave Taht
2019-08-24 7:54 ` Jesper Dangaard Brouer
2019-08-24 7:59 ` Sebastian Moeller [this message]
2019-08-24 9:15 ` 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=36973E7C-0B93-4512-AB0B-917C807E9684@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=brouer@redhat.com \
--cc=simon@superduper.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