[Bloat] dslreports and inbound rate shaping

[Bloat] dslreports and inbound rate shaping

[Dave Taht]

0) dslreports has a hires bufferbloat option now in their settings. It
reveals much detail that I like very much. It may not work well on
some browsers. Give it a shot, please.

1) I like that the graphic .png reports now a ping range, but I think
that is baseline latencies. but I think it would be clearer if it
showed the up and the down, under load, 98th percentile, also.

an unshaped, unmodified cable modem result in all it's horrible glory:

http://www.dslreports.com/speedtest/506793

I am puzzled as to why the idle portion of the test is so bad. Perhaps
it it measuring a new flow syn/synack/data? Or there is a need for the
lowat option on the server side so as to end the test more quickly? or
have we lost so badly there are still 10 seconds of data in flight??

(will take apart some captures when I have time)

2) the "cable" test (which keeps changing the number of flows - these
are all 16/6 flows) thoroughly breaks the sqm system's inbound rate
shaper, using cake or fq_codel (cake here), with my rate set 12% below
the delivered rate (100mbit vs 112Mbit).

http://www.dslreports.com/speedtest/509743

fq_codel:

http://www.dslreports.com/speedtest/509763

Pie:

http://www.dslreports.com/speedtest/509736

Desperate, I applied the linux policer to the inbound test, and got
huge reductions in latency, still with big bursts at a huge cost in
bandwidth.

http://www.dslreports.com/speedtest/506807

We have done too much testing with the gentler rrul test, and this
explains a lot about some bittorrent results I have got elsewhere.

So I finished writing up my thoughts on bobbie,
http://www.bufferbloat.net/projects/codel/wiki/Bobbie

which might work better than anything on the table in the face of huge
bursts like these, when the rate differential is so small.

3) I will try to add a few dslreports emulations into the netperf-wrapper suite.

Sigh. Still so much work left to perform on bufferbloat on conventional devices.

I think fixing wifi will be harder than this. Building spacecraft is
easier than this.

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

[Bloat] Fwd: dslreports and inbound rate shaping

[Dave Taht]

resending as the mail server seems to be mis-behaving.

---------- Forwarded message ----------
From: Dave Taht <dave.taht@gmail.com>
Date: Tue, May 19, 2015 at 12:17 PM
Subject: dslreports and inbound rate shaping
To: bloat <bloat@lists.bufferbloat.net>, Justin Beech
<justinbeech@gmail.com>, cake@lists.bufferbloat.net


0) dslreports has a hires bufferbloat option now in their settings. It
reveals much detail that I like very much. It may not work well on
some browsers. Give it a shot, please.

1) I like that the graphic .png reports now a ping range, but I think
that is baseline latencies. but I think it would be clearer if it
showed the up and the down, under load, 98th percentile, also.

an unshaped, unmodified cable modem result in all it's horrible glory:

http://www.dslreports.com/speedtest/506793

I am puzzled as to why the idle portion of the test is so bad. Perhaps
it it measuring a new flow syn/synack/data? Or there is a need for the
lowat option on the server side so as to end the test more quickly? or
have we lost so badly there are still 10 seconds of data in flight??

(will take apart some captures when I have time)

2) the "cable" test (which keeps changing the number of flows - these
are all 16/6 flows) thoroughly breaks the sqm system's inbound rate
shaper, using cake or fq_codel (cake here), with my rate set 12% below
the delivered rate (100mbit vs 112Mbit).

http://www.dslreports.com/speedtest/509743

fq_codel:

http://www.dslreports.com/speedtest/509763

Pie:

http://www.dslreports.com/speedtest/509736

Desperate, I applied the linux policer to the inbound test, and got
huge reductions in latency, still with big bursts at a huge cost in
bandwidth.

http://www.dslreports.com/speedtest/506807

We have done too much testing with the gentler rrul test, and this
explains a lot about some bittorrent results I have got elsewhere.

So I finished writing up my thoughts on bobbie,
http://www.bufferbloat.net/projects/codel/wiki/Bobbie

which might work better than anything on the table in the face of huge
bursts like these, when the rate differential is so small.

3) I will try to add a few dslreports emulations into the netperf-wrapper suite.

Sigh. Still so much work left to perform on bufferbloat on conventional devices.

I think fixing wifi will be harder than this. Building spacecraft is
easier than this.

--
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67


-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[Kevin Darbyshire-Bryant]

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

On 19/05/2015 23:37, Dave Taht wrote:
>
> 0) dslreports has a hires bufferbloat option now in their settings. It
> reveals much detail that I like very much. It may not work well on
> some browsers. Give it a shot, please.
Tried it - fun!  Here are some of the results of that fun, I've no idea if this will help anyone.
>
> 1) I like that the graphic .png reports now a ping range, but I think
> that is baseline latencies. but I think it would be clearer if it
> showed the up and the down, under load, 98th percentile, also.
>
> an unshaped, unmodified cable modem result in all it's horrible glory:
>
> http://www.dslreports.com/speedtest/506793

Ok so this is my HG612 unshaped VDSL2 modem sat behind Archer C7.  The VDSL2 link
is 40Mbit down, 10Mbit up as reported as its capped 'sync' rate.

http://www.dslreports.com/speedtest/513588

Up is horrendous and I think you can see classic TCP sawtoothing in the delay as well.
Peak just as 'up test' goes idle is strange though.
> 2) the "cable" test (which keeps changing the number of flows - these
> are all 16/6 flows) thoroughly breaks the sqm system's inbound rate
> shaper, using cake or fq_codel (cake here), with my rate set 12% below
> the delivered rate (100mbit vs 112Mbit).
Behaviour here is different.  In theory same test 16/6 flows, down is capped 38Mbit (5%), up at 9.7Mbit(3%)
These are all 'cake'

http://www.dslreports.com/speedtest/513627

There's a slight double bump at the beginning of the down latency test, but otherwise my
browsing/upload/download experience is vastly improved.

Tuning the down to 37Mbit helps that bump a little maybe: http://www.dslreports.com/speedtest/513652

It gets really interesting if I increase the down limit to 39Mbit: http://www.dslreports.com/speedtest/513782 where it
starts to look a bit like your test results.

Increasing the up limit showed an interesting step change in upload delay, this is the up cap set to 9.8Mbit
http://www.dslreports.com/speedtest/513863  (I had a really good example of the delay increasing in a linear
fashion as the buffer just couldn't drain fast enough...if I find that test result again I'll post it)

Tuning it back down, by even as little as 50kbits would remove that step, I settled on 9.7Mbit for safety.

The elephant in my personal room is the high latency baseline measurement.  None of the ping response time test
sites I've checked give me anywhere near a baseline ping rtt of 100ms.  Even dslreports say "London UK is ~10ms,
Google Europe is ~17ms, Dublin, Ireland, EU is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't understand
some thing(s) about this test.

Anyway, that's been an interesting 2 hours of playing!

Kevin

>
>
> 3) I will try to add a few dslreports emulations into the netperf-wrapper suite.
>
> Sigh. Still so much work left to perform on bufferbloat on conventional devices.
>
> I think fixing wifi will be harder than this. Building spacecraft is
> easier than this.
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[Alan Jenkins]

On 20/05/15 13:47, Kevin Darbyshire-Bryant wrote:
 > On 19/05/2015 23:37, Dave Taht wrote:
 >>
 >> 0) dslreports has a hires bufferbloat option now in their settings.
 >> It reveals much detail that I like very much. It may not work well
 >> on some browsers. Give it a shot, please.
 > Tried it - fun!  Here are some of the results of that fun, I've no
 > idea if this will help anyone.
 >>
 >> 1) I like that the graphic .png reports now a ping range, but I
 >> think that is baseline latencies. but I think it would be clearer
 >> if it showed the up and the down, under load, 98th percentile,
 >> also.
 >>
 >> an unshaped, unmodified cable modem result in all it's horrible
 >> glory:
 >>
 >> http://www.dslreports.com/speedtest/506793
 >
 > Ok so this is my HG612 unshaped VDSL2 modem sat behind Archer C7.
 > The VDSL2 link is 40Mbit down, 10Mbit up as reported as its capped
 > 'sync' rate.
 >
 > http://www.dslreports.com/speedtest/513588
 >
 > Up is horrendous and I think you can see classic TCP sawtoothing in
 > the delay as well. Peak just as 'up test' goes idle is strange
 > though.
 >
 >> 2) the "cable" test (which keeps changing the number of flows -
 >> these are all 16/6 flows) thoroughly breaks the sqm system's
 >> inbound rate shaper, using cake or fq_codel (cake here), with my
 >> rate set 12% below the delivered rate (100mbit vs 112Mbit).
 >
 > Behaviour here is different.  In theory same test 16/6 flows, down is
 > capped 38Mbit (5%), up at 9.7Mbit(3%) These are all 'cake'
 >
 > http://www.dslreports.com/speedtest/513627
 >
 > There's a slight double bump at the beginning of the down latency
 > test, but otherwise my browsing/upload/download experience is vastly
 > improved.
 >
 > Tuning the down to 37Mbit helps that bump a little maybe:
 > http://www.dslreports.com/speedtest/513652
 >
 > It gets really interesting if I increase the down limit to 39Mbit:
 > http://www.dslreports.com/speedtest/513782 where it starts to look a
 > bit like your test results.
 >
 > Increasing the up limit showed an interesting step change in upload
 > delay, this is the up cap set to 9.8Mbit
 > http://www.dslreports.com/speedtest/513863  (I had a really good
 > example of the delay increasing in a linear fashion as the buffer
 > just couldn't drain fast enough...if I find that test result again
 > I'll post it)
 >
 > Tuning it back down, by even as little as 50kbits would remove that
 > step, I settled on 9.7Mbit for safety.
 >
 > The elephant in my personal room is the high latency baseline
 > measurement.  None of the ping response time test sites I've checked
 > give me anywhere near a baseline ping rtt of 100ms.  Even dslreports
 > say "London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland, EU
 > is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't
 > understand some thing(s) about this test.
 >
 > Anyway, that's been an interesting 2 hours of playing!
 >
 > Kevin

Good fun :).

The baseline latency is because the bloat measurement uses a single 
websocket ping server in America.  Justin said in the forums it didn't 
seem worth the effort to set up more of them.  Seems worth an faq item 
though :(.

Alan

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[jb]

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

Regarding this part:

> The baseline latency is because the bloat measurement uses a single
websocket ping server in America.  Justin said in the forums it didn't seem
worth the effort to set up more of them.  Seems worth an faq item though :(.

Below huge speeds, upload testing is done with web socket now,
so there is a websocket address on every server now anyway.

The baseline pinging to dslreports.com doesn't seem broken
but if necessary it can be changed to baseline pinging to the
nearest server, wherever that is.

On Sat, May 23, 2015 at 12:05 AM, Alan Jenkins <
alan.christopher.jenkins@gmail.com> wrote:

> On 20/05/15 13:47, Kevin Darbyshire-Bryant wrote:
> > On 19/05/2015 23:37, Dave Taht wrote:
> >>
> >> 0) dslreports has a hires bufferbloat option now in their settings.
> >> It reveals much detail that I like very much. It may not work well
> >> on some browsers. Give it a shot, please.
> > Tried it - fun!  Here are some of the results of that fun, I've no
> > idea if this will help anyone.
> >>
> >> 1) I like that the graphic .png reports now a ping range, but I
> >> think that is baseline latencies. but I think it would be clearer
> >> if it showed the up and the down, under load, 98th percentile,
> >> also.
> >>
> >> an unshaped, unmodified cable modem result in all it's horrible
> >> glory:
> >>
> >> http://www.dslreports.com/speedtest/506793
> >
> > Ok so this is my HG612 unshaped VDSL2 modem sat behind Archer C7.
> > The VDSL2 link is 40Mbit down, 10Mbit up as reported as its capped
> > 'sync' rate.
> >
> > http://www.dslreports.com/speedtest/513588
> >
> > Up is horrendous and I think you can see classic TCP sawtoothing in
> > the delay as well. Peak just as 'up test' goes idle is strange
> > though.
> >
> >> 2) the "cable" test (which keeps changing the number of flows -
> >> these are all 16/6 flows) thoroughly breaks the sqm system's
> >> inbound rate shaper, using cake or fq_codel (cake here), with my
> >> rate set 12% below the delivered rate (100mbit vs 112Mbit).
> >
> > Behaviour here is different.  In theory same test 16/6 flows, down is
> > capped 38Mbit (5%), up at 9.7Mbit(3%) These are all 'cake'
> >
> > http://www.dslreports.com/speedtest/513627
> >
> > There's a slight double bump at the beginning of the down latency
> > test, but otherwise my browsing/upload/download experience is vastly
> > improved.
> >
> > Tuning the down to 37Mbit helps that bump a little maybe:
> > http://www.dslreports.com/speedtest/513652
> >
> > It gets really interesting if I increase the down limit to 39Mbit:
> > http://www.dslreports.com/speedtest/513782 where it starts to look a
> > bit like your test results.
> >
> > Increasing the up limit showed an interesting step change in upload
> > delay, this is the up cap set to 9.8Mbit
> > http://www.dslreports.com/speedtest/513863  (I had a really good
> > example of the delay increasing in a linear fashion as the buffer
> > just couldn't drain fast enough...if I find that test result again
> > I'll post it)
> >
> > Tuning it back down, by even as little as 50kbits would remove that
> > step, I settled on 9.7Mbit for safety.
> >
> > The elephant in my personal room is the high latency baseline
> > measurement.  None of the ping response time test sites I've checked
> > give me anywhere near a baseline ping rtt of 100ms.  Even dslreports
> > say "London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland, EU
> > is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't
> > understand some thing(s) about this test.
> >
> > Anyway, that's been an interesting 2 hours of playing!
> >
> > Kevin
>
> Good fun :).
>
> The baseline latency is because the bloat measurement uses a single
> websocket ping server in America.  Justin said in the forums it didn't seem
> worth the effort to set up more of them.  Seems worth an faq item though :(.
>
> Alan
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[Alan Jenkins]

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

On 25/05/15 22:39, jb wrote:
> Regarding this part:
>
> > The baseline latency is because the bloat measurement uses a single 
> websocket ping server in America.  Justin said in the forums it didn't 
> seem worth the effort to set up more of them.  Seems worth an faq item 
> though :(.
>
> Below huge speeds, upload testing is done with web socket now,
> so there is a websocket address on every server now anyway.
>
> The baseline pinging to dslreports.com <http://dslreports.com> doesn't 
> seem broken
> but if necessary it can be changed to baseline pinging to the
> nearest server, wherever that is.
>

Personally I might be skewed by using Firefox on Linux, I don't see the 
awesome live bloat-meter, only the awesome bloat graphs.

PS My firefox also doesn't show the new graph-based speedtest history.  
I disabled the obvious culprits (noscript, ghostery, ublock) & there's 
nothing on the JS console.  Happy to help if needed.

"Fixing" the bufferbloat ping graph would make it more directly 
comparable to the pings on other speedtests.  I think that makes the 
bufferbloat point clearer.  Again the issue is outside the US; in the UK 
I see a 100ms "baseline".  If it's simple to start using nearer servers, 
that would make me very happy :).

I agree it's not "broken".  (I also use netperf-eu at 59ms).  It's just 
confusing to interpret, if you don't already know what bufferbloat is 
going to look like.

Particularly as the "expected" low ping value shown at the start. The 
100ms server isn't even shown on the ping radar part.

If it's easier to just call out the destination country on the 
bufferbloat ping, or fudge the figures convincingly (just graph the 
increases from a minimum), that would answer my point too.

Thanks
Alan

> > > The elephant in my personal room is the high latency baseline
>
>     > measurement.  None of the ping response time test sites I've checked
>     > give me anywhere near a baseline ping rtt of 100ms.  Even dslreports
>     > say "London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland, EU
>     > is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't
>     > understand some thing(s) about this test.
>     >
>     > Anyway, that's been an interesting 2 hours of playing!
>     >
>     > Kevin
>
>     Good fun :).
>
>     The baseline latency is because the bloat measurement uses a
>     single websocket ping server in America.  Justin said in the
>     forums it didn't seem worth the effort to set up more of them. 
>     Seems worth an faq item though :(.
>


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

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[jb]

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

The test, and the issue of buffer bloat, got some coverage today
in the Houston Chronicle:

http://blog.chron.com/techblog/2015/05/new-speed-test-at-dslreports/



On Tue, May 26, 2015 at 7:13 PM, Alan Jenkins <
alan.christopher.jenkins@gmail.com> wrote:

>  On 25/05/15 22:39, jb wrote:
>
>  Regarding this part:
>
>  > The baseline latency is because the bloat measurement uses a single
> websocket ping server in America.  Justin said in the forums it didn't seem
> worth the effort to set up more of them.  Seems worth an faq item though :(.
>
>  Below huge speeds, upload testing is done with web socket now,
> so there is a websocket address on every server now anyway.
>
>  The baseline pinging to dslreports.com doesn't seem broken
> but if necessary it can be changed to baseline pinging to the
> nearest server, wherever that is.
>
>
> Personally I might be skewed by using Firefox on Linux, I don't see the
> awesome live bloat-meter, only the awesome bloat graphs.
>
> PS My firefox also doesn't show the new graph-based speedtest history.  I
> disabled the obvious culprits (noscript, ghostery, ublock) & there's
> nothing on the JS console.  Happy to help if needed.
>
> "Fixing" the bufferbloat ping graph would make it more directly comparable
> to the pings on other speedtests.  I think that makes the bufferbloat point
> clearer.  Again the issue is outside the US; in the UK I see a 100ms
> "baseline".  If it's simple to start using nearer servers, that would make
> me very happy :).
>
> I agree it's not "broken".  (I also use netperf-eu at 59ms).  It's just
> confusing to interpret, if you don't already know what bufferbloat is going
> to look like.
>
> Particularly as the "expected" low ping value shown at the start.  The
> 100ms server isn't even shown on the ping radar part.
>
> If it's easier to just call out the destination country on the bufferbloat
> ping, or fudge the figures convincingly (just graph the increases from a
> minimum), that would answer my point too.
>
> Thanks
> Alan
>
>   > > The elephant in my personal room is the high latency baseline
>
>>  > measurement.  None of the ping response time test sites I've checked
>> > give me anywhere near a baseline ping rtt of 100ms.  Even dslreports
>> > say "London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland, EU
>> > is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't
>> > understand some thing(s) about this test.
>> >
>> > Anyway, that's been an interesting 2 hours of playing!
>> >
>> > Kevin
>>
>>  Good fun :).
>>
>> The baseline latency is because the bloat measurement uses a single
>> websocket ping server in America.  Justin said in the forums it didn't seem
>> worth the effort to set up more of them.  Seems worth an faq item though :(.
>>
>
>

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

Re: [Bloat] Fwd: dslreports and inbound rate shaping

[Kevin Darbyshire-Bryant]

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

Found it!

http://www.dslreports.com/speedtest/513499



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@gmail.com> wrote:
> 
> So I finished writing up my thoughts on bobbie,
> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
> 
> which might work better than anything on the table in the face of huge
> bursts like these, when the rate differential is so small.

I wonder if there’s any profit in making fq_codel and cake behave more like a policer on ingress; that would be halfway to bobbie without writing a lot of new code.

A reasonable test would be to try configuring fq_codel with interval = target = 5ms.  If that works better, I could add similar functionality to cake.

- Jonathan Morton

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Kathleen Nichols]

On 5/21/15 9:21 AM, Jonathan Morton wrote:
> 
>> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> So I finished writing up my thoughts on bobbie, 
>> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
>> 
>> which might work better than anything on the table in the face of
>> huge bursts like these, when the rate differential is so small.
> 
> I wonder if there’s any profit in making fq_codel and cake behave
> more like a policer on ingress; that would be halfway to bobbie
> without writing a lot of new code.
> 
> A reasonable test would be to try configuring fq_codel with interval
> = target = 5ms.  If that works better, I could add similar
> functionality to cake.

I'm curious why you think that would be a "reasonable test".

		Kathie
> 
> - Jonathan Morton
> 
> _______________________________________________ Bloat mailing list 
> Bloat@lists.bufferbloat.net 
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

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

When Codel is applied on the upstream side of a link, a burst arrives in it
almost instantly, and thus it only takes 5ms to detect that 5ms of queue
has developed. The interval parameter then delays action on that detection
until it is certain that it's a standing queue and not simply a burst.

When applied on the downstream side of a link, however, it takes longer for
a burst to filter through to where Codel can see it. If the shaper is set
to 90% of the link rate, it takes at least 45ms to build a 5ms queue,
during which the receiver is acking data without any clue that congestion
is in place. At 95%, it requires at least 95ms. The delay in detection
might be even longer under some circumstances.

This means Codel has to be more aggressive at responding to a detected 5ms
queue on ingress in order to provide control of the flow comparable to
egress. I'm proposing using a reduced interval parameter to do that. A
drawback is that the response will be stronger than designed, and this may
have an impact on throughput, but the same is true (and more definitely so)
of a policer.

On the one hand, this might lead to an interim solution while Bobbie gets
fleshed out. On the other, it should provide more information on whether
Bobbie is likely to work.

- Jonathan Morton

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

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Kathleen Nichols]

It sounds like you are defining congestion as packets experiencing 5ms of
delay over a period of 5ms.

When you evaluate this, what metrics do you use to evaluate the effect on
the applications using this buffer?

	Kathie

On 5/21/15 8:26 AM, Jonathan Morton wrote:
> When Codel is applied on the upstream side of a link, a burst arrives in
> it almost instantly, and thus it only takes 5ms to detect that 5ms of
> queue has developed. The interval parameter then delays action on that
> detection until it is certain that it's a standing queue and not simply
> a burst.
> 
> When applied on the downstream side of a link, however, it takes longer
> for a burst to filter through to where Codel can see it. If the shaper
> is set to 90% of the link rate, it takes at least 45ms to build a 5ms
> queue, during which the receiver is acking data without any clue that
> congestion is in place. At 95%, it requires at least 95ms. The delay in
> detection might be even longer under some circumstances.
> 
> This means Codel has to be more aggressive at responding to a detected
> 5ms queue on ingress in order to provide control of the flow comparable
> to egress. I'm proposing using a reduced interval parameter to do that.
> A drawback is that the response will be stronger than designed, and this
> may have an impact on throughput, but the same is true (and more
> definitely so) of a policer.
> 
> On the one hand, this might lead to an interim solution while Bobbie
> gets fleshed out. On the other, it should provide more information on
> whether Bobbie is likely to work.
> 
> - Jonathan Morton
> 

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

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

No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue
has built up to 5ms over a continuous 50ms.  At 95%, it'll trigger at 100ms.

Remember, Codel can't see what's in the dumb FIFO on the upstream end of
the link. By the time it triggers, there's potentially a lot of queue there
that it doesn't know about and can't directly measure. That's why it has to
be more aggressive about the queue it can see.

- Jonathan Morton

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

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Aaron Wood]

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

But will it trigger at all?  If the inbound rate is say 50Mbps, and the
link to the in-home devices are over 100Mbps ethernet, will codel _ever_
see a 5ms buffer on inbound?

Or is the shaping buffering incoming packets, and creating a bundle that it
can measure?  (I don't know the internals of how htb(?) does the limiting)

-Aaron

On Thu, May 21, 2015 at 9:39 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

> No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue
> has built up to 5ms over a continuous 50ms.  At 95%, it'll trigger at 100ms.
>
> Remember, Codel can't see what's in the dumb FIFO on the upstream end of
> the link. By the time it triggers, there's potentially a lot of queue there
> that it doesn't know about and can't directly measure. That's why it has to
> be more aggressive about the queue it can see.
>
> - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

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

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

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

Yes, it will. That's the whole point of combining it with a shaper.

- Jonathan Morton

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

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 2453 bytes --]

On 21/05/2015 17:21, Jonathan Morton wrote:
>> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> So I finished writing up my thoughts on bobbie,
>> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
>>
>> which might work better than anything on the table in the face of huge
>> bursts like these, when the rate differential is so small.
> I wonder if there’s any profit in making fq_codel and cake behave more like a policer on ingress; that would be halfway to bobbie without writing a lot of new code.
>
> A reasonable test would be to try configuring fq_codel with interval = target = 5ms.  If that works better, I could add similar functionality to cake.
>
> - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Up for a challenge I tried it.  Line rate is 40000 down, 10000 up - Sky broadband UK VDSL2 PTM (manual overhead of 8 for VLAN tagging on WAN & VDSL2 flags)
note that I also use ECN everywhere.  From the dslreports site, with a new layout I note - nice!  Numbers at end of each line are
reported latency for idle (minimum), up (average), down (average) in ms.

Baseline:
fq_codel 37500 9700 interval 100ms http://www.dslreports.com/speedtest/526382 - 109 114 112
fq_codel 37500 9700 interval 5ms   http://www.dslreports.com/speedtest/526367 - 106 119 111


fq_codel 38500 9700 interval 100ms http://www.dslreports.com/speedtest/526318 - 106 120 110 standing q but managed slightly better than....
fq_codel 38500 9700 interval 5ms   http://www.dslreports.com/speedtest/526305 - 116 142 118 standing q


fq_codel 39000 9700 interval 100ms http://www.dslreports.com/speedtest/526335 - 110 153 113 spikey spaced
fq_codel 39000 9700 interval 5ms   http://www.dslreports.com/speedtest/526308 - 109 194 112 spikey closer


fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey
fq_codel 40000 9700 interval 5ms   http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey

I don't think tweaking intervals has given the hoped for result in my case.  If anything It looks like it increases standing latency though some of graph
scaling makes that difficult to see.  The final test looks like it's heading in a better direction but it still has 420+ms spikes.


-- 
Thanks,

Kevin@Darbyshire-Bryant.me.uk


[-- Attachment #1.2: Type: text/html, Size: 4492 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

> fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey 
> fq_codel 40000 9700 interval 5ms   http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey

On a 40Mbit downlink, setting ingress to 40Mbit will exert effectively no control over incoming traffic.  So what you’re seeing here is the raw performance of your ISP.

I’d really like to see Dave trying this, since he was noting the problem to solve originally.

 - Jonathan Morton

Re: [Bloat] [Cake] dslreports and inbound rate shaping

[Kevin Darbyshire-Bryant]

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

On 22/05/2015 12:07, Jonathan Morton wrote:
>> fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey 
>> fq_codel 40000 9700 interval 5ms   http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey
> On a 40Mbit downlink, setting ingress to 40Mbit will exert effectively no control over incoming traffic.  So what you’re seeing here is the raw performance of your ISP.
>
> I’d really like to see Dave trying this, since he was noting the problem to solve originally.
>
>  - Jonathan Morton
>

I followed it up with an outright lie to the limiter (and in interests of full disclosure I changed the outbound limit to be more conservative)

fq_codel 80000! 9500 interval 100ms http://www.dslreports.com/speedtest/526549 109 139 115
fq_codel 80000! 9500 interval 5ms   http://www.dslreports.com/speedtest/526556 111 183 115 - more & higher spikes

I'll keep quiet now and hopefully watch other's results come in!

-- 
Thanks,

Kevin@Darbyshire-Bryant.me.uk



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] dslreports and inbound rate shaping

[Mikael Abrahamsson]

On Tue, 19 May 2015, Dave Taht wrote:

> 0) dslreports has a hires bufferbloat option now in their settings. It
> reveals much detail that I like very much. It may not work well on
> some browsers. Give it a shot, please.

I tried it on my DOCSIS 3 connection 250/50 with my Apple Airport Extreme 
(via gige cable):

http://www.dslreports.com/speedtest/545437

I then cranked up the flows to 32/32 (max that was allowed)

http://www.dslreports.com/speedtest/545449

I then changed to use "fiber" instead of "coax" (I have no idea what that 
changes in the test):

http://www.dslreports.com/speedtest/545457

I get occasional delay spikes but at least 95% of the time this is kept 
very well under control.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se