From: Jonathan Morton <chromatix99@gmail.com>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Latency target curiosity
Date: Thu, 7 May 2020 11:09:19 +0300 [thread overview]
Message-ID: <EEADF1AF-4471-4A94-BB2E-5669A521B1B4@gmail.com> (raw)
In-Reply-To: <E8AAEA5E-98A9-48A7-86F3-BE4621B4074B@darbyshire-bryant.me.uk>
> On 7 May, 2020, at 10:58 am, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
> A curiosity has arisen: I use diffserv4 mode on a 20Mbit egress link. Bulk tin has ‘capacity’ threshold of 1.2Mbit and because it’s a slow ’tin', the default target & interval values get overridden to 14.6ms and 109.6ms respectively. The 3 other tins are 5ms & 100ms defaults.
>
> I have a backup job that bulk uploads 5 simultaneous flows to Onedrive. The sparse_delay, average_delay & peak_delay figures settle on 32, 38 & 43 ms respectively with around 9 drops per second on that tin.
>
> I’m curious as to why the reported delays are over double the target latency?
It's likely that there's a minimum cwnd in your sender's TCP stack, which may be as large as 4 segments. In Linux it is 2 segments. No matter how much congestion signalling is asserted, the volume of data in flight (including retransmissions of dropped packets) will always correspond to at least that minimum per flow. If the path is short, most of that volume will exists in queues instead of on the wire.
Fortunately, backups are unlikely to suffer from a small amount of extra latency, and Cake will isolate their influence from other flows that may be more sensitive.
- Jonathan Morton
next prev parent reply other threads:[~2020-05-07 8:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 7:58 Kevin Darbyshire-Bryant
2020-05-07 8:09 ` Jonathan Morton [this message]
2020-05-07 9:11 ` Kevin Darbyshire-Bryant
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EEADF1AF-4471-4A94-BB2E-5669A521B1B4@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
/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