* Re: [Bloat] Large decrease in speed needed to combat bufferbloat?
2016-08-17 8:21 [Bloat] Large decrease in speed needed to combat bufferbloat? Alec Robertson
@ 2016-10-20 17:57 ` David Collier-Brown
2016-10-21 3:53 ` jb
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: David Collier-Brown @ 2016-10-20 17:57 UTC (permalink / raw)
To: bloat, alecrobertson13
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Bloat] Large decrease in speed needed to combat bufferbloat?
2016-08-17 8:21 [Bloat] Large decrease in speed needed to combat bufferbloat? Alec Robertson
2016-10-20 17:57 ` David Collier-Brown
@ 2016-10-21 3:53 ` jb
2016-10-21 4:39 ` Mikael Abrahamsson
2016-10-21 8:32 ` Mario Hock
3 siblings, 0 replies; 5+ messages in thread
From: jb @ 2016-10-21 3:53 UTC (permalink / raw)
To: Alec Robertson; +Cc: bloat
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
Regarding bloat testing ping on my test at dslreports.com it is done with
web sockets so is sensitive to
a) how busy the single threaded javascript engine in the browser is
b) whether you are using https or http
The degree of vagueness depends on browser and CPU speed and how fast your
connection is generally however I would not suggest that it is as accurate
as a UDP or ICMP ping given the above factors.
thanks
-Justin
On Wed, Aug 17, 2016 at 6:21 PM, Alec Robertson <alecrobertson13@gmail.com>
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
>
>
[-- Attachment #2: Type: text/html, Size: 3515 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] Large decrease in speed needed to combat bufferbloat?
2016-08-17 8:21 [Bloat] Large decrease in speed needed to combat bufferbloat? Alec Robertson
2016-10-20 17:57 ` David Collier-Brown
2016-10-21 3:53 ` jb
@ 2016-10-21 4:39 ` Mikael Abrahamsson
2016-10-21 8:32 ` Mario Hock
3 siblings, 0 replies; 5+ messages in thread
From: Mikael Abrahamsson @ 2016-10-21 4:39 UTC (permalink / raw)
To: Alec Robertson; +Cc: bloat
On Wed, 17 Aug 2016, Alec Robertson wrote:
> 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.
I personally think that aiming for 3-4ms of bloat is excessive for the
applications we see today. Most of the time you're not going to notice
10-20ms bloat even when using quite time sensitive applications, and that
10-20ms PDV range is probably a better tradeoff between performance and
potential interactive performance downside.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] Large decrease in speed needed to combat bufferbloat?
2016-08-17 8:21 [Bloat] Large decrease in speed needed to combat bufferbloat? Alec Robertson
` (2 preceding siblings ...)
2016-10-21 4:39 ` Mikael Abrahamsson
@ 2016-10-21 8:32 ` Mario Hock
3 siblings, 0 replies; 5+ messages in thread
From: Mario Hock @ 2016-10-21 8:32 UTC (permalink / raw)
To: bloat
Hi,
Am 17.08.2016 um 10:21 schrieb Alec Robertson:
> 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?
you can get access to the internal RTT estimation of the TCP stack with
the tool TCPlog (https://git.scc.kit.edu/CPUnetLOG/TCPlog).
It shows (among other values): minRtt, maxRtt, avgRtt, meanRtt
But be aware that you have to run TCPlog on the sending end-system.
Also, TCPlog is only available for Linux.
Best regards,
Mario Hock
^ permalink raw reply [flat|nested] 5+ messages in thread