General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Collier-Brown <davec-b@rogers.com>
To: bloat@lists.bufferbloat.net, alecrobertson13@gmail.com
Subject: Re: [Bloat] Large decrease in speed needed to combat bufferbloat?
Date: Thu, 20 Oct 2016 13:57:28 -0400	[thread overview]
Message-ID: <62747e5a-6741-04b9-7078-745e545d0539@rogers.com> (raw)
In-Reply-To: <CAGwEnGxMt3XUpqUxk80Pdqkd1pfX42BMc3AQ1zXsSGUAZjmkJQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

I suspect you're seeing a decrease in the speed of data into a sink, not 
a decrease in end-to-end speed. Measurement results can often be 
puzzling here (;-))

My description of the situation is:

- an infinite (or just bloatily large) queue will accept data at just 
about any rate you offer it, and keep it around until the service centre 
can process it, which is in our case is the other end of the network 
link getting it. If the queue only reports ingress, it will show really 
large values, sometimes well above what the link can ever handle.  (Some 
folks report those rates as a marketing feature. I'm not sure that's 
exactly kosher (;-))

- a queue processes the same amount of data per unit time when latency 
is at a minimum as it does when it's at a maximum, so normal queues 
should be tuned for minimum latency.

- in TCP, there is a cost in retransmissions when we use drops to signal 
the sender that they've sent too much, so it's best to keep your rate 
just below the rate at which you get drops. That maximizes throughput 
for a given small latency.  TCP does this automatically when not 
bloatified, and on average stays really really close to the maximum 
speed of the channel.

- buffers are really good to smooth out brief stoppages or bursty 
senders, but have to be kept nearly empty to be able to do that, and 
then drained quickly when they get filled.

--dave (processing an email queue while waiting for a compile) c-b


On 17/08/16 04:21 AM, Alec Robertson wrote:
> I'm on a TalkTalk FTTC connection in the UK, with a sync speed of 
> 58976Kbps, via a Billion 8800NL in bridge mode to my TP-LINK Archer C7 
> (currently running LEDE r1348) with sqm-scripts 1.0.7-1 and 
> mod-sched-cake 4.4.15+2016-06-29-747..5-1.
>
> I have selected cake as the qdisc and piece_of_cake.qos as the queue 
> setup script.
>
> I've managed to get bufferbloat under control, with only 3-4ms of 
> added ping when downloading but I've had to set the ingress to 43000, 
> reducing my speed not hugely but more than I might have expected.
>
> On the upload side I'm syncing at 10422Kbps and the egress is set to 
> 9300, so not quite as bad. Bufferbloat here is also under control, at 
> maybe 2-3ms when downloading.
>
> Is there anything I can do to reclaim more of the download speed? How 
> can I diagnose this?
>
> The other question I would like to ask is, what's the absolute best 
> way to see what the ping maximum actually is? With speedtest.net 
> <http://speedtest.net> the ping only increases 1-2ms (pinging 
> bbc.co.uk <http://bbc.co.uk>) and the same is true for dslreports.com 
> <http://dslreports.com> (maybe a little bit higher, maximum of about 
> 5ms) but on the dslreports.com <http://dslreports.com> site it says 
> 9ms+ at times?
>
> Thanks.
>
>
>   --
>   Alec Robertson
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain


[-- Attachment #2: Type: text/html, Size: 5797 bytes --]

  reply	other threads:[~2016-10-20 17:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  8:21 Alec Robertson
2016-10-20 17:57 ` David Collier-Brown [this message]
2016-10-21  3:53 ` jb
2016-10-21  4:39 ` Mikael Abrahamsson
2016-10-21  8:32 ` Mario Hock

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=62747e5a-6741-04b9-7078-745e545d0539@rogers.com \
    --to=davec-b@rogers.com \
    --cc=alecrobertson13@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=davecb@spamcop.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