From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm2-vm5.access.bullet.mail.gq1.yahoo.com (nm2-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 862113B25E for ; Thu, 20 Oct 2016 13:57:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s2048; t=1476986249; bh=wpMYZS202ff0mvhNSoO5XWcSHwB7cvFbv/rCdoq80L8=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From:Subject; b=bY+obgHGqV05kziLdpvNEfP2LA5Z0RETRfeygfbUdRbTxjLwu9M9Xju0JWsYjF6OGXwArmNv3zCoknE/08B4P1qqJVVZcQF/lmN8G38RonDobXVzZuaD+Sy4Gd2LfLDGAZdknzlkcRcalmeJcz3VUKk54s70och2RIQdQMAr0np3LDGSlNieOJsVM7zJpzR+7LFyfCSUIICqz6yr+oSpnjg5/+AKTQwgIxHtKLgF+qPADMmd2WYCsp7RP2OEUp6Tw04zAbMLiRzfm0lGi+BKmd41mIQs6SV67c9N3fiux3qu7EhiKgmCQNJmh/91ZPoGLdJy6z8UfAFyMbu3FLTdxw== Received: from [216.39.60.171] by nm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Oct 2016 17:57:29 -0000 Received: from [67.195.22.117] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Oct 2016 17:57:29 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.gq1.yahoo.com with NNFMP; 20 Oct 2016 17:57:29 -0000 X-Yahoo-Newman-Id: 629197.75670.bm@smtp112.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DRKeZ4gVM1naThGpOXFp.TCiYCgs3w9TWdPxFkCV1JKCtnE Idg2GADk_hjpX1FuBptZDY5vYW.4ll3ZAaFoPTHvWGOyKhOikOw9uAUQUf5N pQvJTuH24EfJKLEP.azijnsvgDty6MljMgIpEvnhmiPw1JGRHKJgv1NEBinb E_CPShjDkXA1gG4hmUbmr8QPoLWA0vBw_A.JZM7qtizREC76zZUI.QtwLytZ CtWQhR_zUTBBQwHQQARP25wXDWQZjkJVYUaP71PK0zYtTlOh9Qt1AlhB7KKR HB6OM0GzNyfxo26cJJSaJdrfpJhHjFv6DVv42E_0sSkCWwHHGztoB.TXTLZR 7M0.hJPWj7T3.J8fYk.3xTnH32Bog.q_EqxHpbwrVVv2H_Diwz8OJo7L547u 6z3GCN5Eu_Wb9FM1989RAIYpWc3HrZyS8a3Cj5h_Xnri2pDEllyJs6RnsZa4 qPY1_WHRuWbSyrld3bKIUzlWcbw2QEo0_ud9lqoAYeZpG66fX6d19d5NTQJt KtQhOx5hBPqLbhzUqu00qUqW0TjkThItR6mCePRL5nClh.SMbhTgUHelUtWV lxESi7dEkTmcuGBqRVqpe X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- To: bloat@lists.bufferbloat.net, alecrobertson13@gmail.com References: From: David Collier-Brown Reply-To: davecb@spamcop.net Message-ID: <62747e5a-6741-04b9-7078-745e545d0539@rogers.com> Date: Thu, 20 Oct 2016 13:57:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CDCE5D1A90BFEE16E49CC136" Subject: Re: [Bloat] Large decrease in speed needed to combat bufferbloat? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 17:57:30 -0000 This is a multi-part message in MIME format. --------------CDCE5D1A90BFEE16E49CC136 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > the ping only increases 1-2ms (pinging > bbc.co.uk ) and the same is true for dslreports.com > (maybe a little bit higher, maximum of about > 5ms) but on the 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 --------------CDCE5D1A90BFEE16E49CC136 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 the ping only increases 1-2ms (pinging bbc.co.uk) and the same is true for dslreports.com (maybe a little bit higher, maximum of about 5ms) but on the 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
--------------CDCE5D1A90BFEE16E49CC136--