Re: [Cake] ack filter rrul result at 1000/100

Re: [Cake] ack filter rrul result at 1000/100

[Pete Heist]

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


> From: Dave Taht <dave.taht@gmail.com>
> To: Cake List <cake@lists.bufferbloat.net>
> Subject: Re: [Cake] ack filter rrul result at 1000/100
> Message-ID:
> 	<CAA93jw7sxna2Ot=Q86LaTGN+2z2Y=NzdV2-EcqU6ypkc6=DbTw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> This is a much saner test result[1], showing about a 20% improvement
> under the rrul_be test. I scaled back the topology to two instances of
> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> the other, and flipped filtering on or off. The win will improve more
> with upload/download ratios of ever worse than 10/1, and the rrul is
> not exactly a test of real traffic.
> 
> What other ratios are out there, particularly in the dsl world?

That’s quite nice. Attached is the ADSL connection info for what I had before I found FreeNet. I don’t miss this connection at all, _except_ that it might have been nice for testing this. 2048 / 135 kbit, that’s around 15 : 1.


[-- Attachment #2.1: Type: text/html, Size: 1995 bytes --]

[-- Attachment #2.2: lukasov_adsl.png --]
[-- Type: image/png, Size: 31359 bytes --]

Re: [Cake] ack filter rrul result at 1000/100

[Alan Jenkins]

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

On 16/11/17 09:24, Pete Heist wrote:
>
>> From: Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>>
>> To: Cake List <cake@lists.bufferbloat.net 
>> <mailto:cake@lists.bufferbloat.net>>
>> Subject: Re: [Cake] ack filter rrul result at 1000/100
>> Message-ID:
>> <CAA93jw7sxna2Ot=Q86LaTGN+2z2Y=NzdV2-EcqU6ypkc6=DbTw@mail.gmail.com 
>> <mailto:CAA93jw7sxna2Ot=Q86LaTGN+2z2Y=NzdV2-EcqU6ypkc6=DbTw@mail.gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> This is a much saner test result[1], showing about a 20% improvement
>> under the rrul_be test. I scaled back the topology to two instances of
>> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
>> the other, and flipped filtering on or off. The win will improve more
>> with upload/download ratios of ever worse than 10/1, and the rrul is
>> not exactly a test of real traffic.
>>
>> What other ratios are out there, particularly in the dsl world?
>
> That’s quite nice. Attached is the ADSL connection info for what I had 
> before I found FreeNet. I don’t miss this connection at all, _except_ 
> that it might have been nice for testing this. 2048 / 135 kbit, that’s 
> around 15 : 1.

I have a good UK ADSL2+ connection, which I am shaping at 15:0.9 mbit, 
using a LEDE box.  The raw sync rates are a bit more asymmetric too.

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

[Cake] ack filter rrul result at 1000/100

[Dave Taht]

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

I pulled together rmounce's patchset for ack filtering and my own
ongoing netem work and had a chance to run a few tests.

Pretty remarkable. The attached graph is a 1gbit (unshaped) link up
with a 100Mbit down, the classic rrul 4 upload and 4 download flows,
with the ping measurement....

Just an across the board win, unless the tcp gods rain hellfire down
on us. And wow, look at all those acks that got killed.

 backlog 0b 0p requeues 1
 memory used: 317312b of 5000000b
 capacity estimate: 100Mbit
                 Bulk   Best Effort      Voice
  thresh      6250Kbit     100Mbit      25Mbit
  target         5.0ms       5.0ms       5.0ms
  interval     100.0ms     100.0ms      10.0ms
  pk_delay         2us        10us        53us
  av_delay         1us         1us         4us
  sp_delay         1us         1us         3us
  pkts          228783     1937474      631425
  bytes      104982588  1189472341   380759260
  way_inds           0           0           0
  way_miss           6          63          19
  way_cols           0           0           0
  drops           6076        2091        1993
  marks              0           0           0
  ack_drop       67510      135880      102528
  sp_flows           0           1           0
  bk_flows           0           0           1
  un_flows           0           0           0
  max_len         6056       15140       10598


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

[-- Attachment #2: rrul-2017-11-15T185347.086665.ack_filter.flent.gz --]
[-- Type: application/x-gzip, Size: 78941 bytes --]

[-- Attachment #3: rrul-2017-11-15T185653.192762.no_ack_filter.flent.gz --]
[-- Type: application/x-gzip, Size: 82489 bytes --]

[-- Attachment #4: rrul_-_ack-filter.png --]
[-- Type: image/png, Size: 636016 bytes --]

Re: [Cake] ack filter rrul result at 1000/100

[Dave Taht]

Please disregard that result entirely, my test setup was wrong and I
jumped for joy too early.

(turned out on the second run I'd rate limited the wrong interface
also to 100mbit)

On Wed, Nov 15, 2017 at 7:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I pulled together rmounce's patchset for ack filtering and my own
> ongoing netem work and had a chance to run a few tests.
>
> Pretty remarkable. The attached graph is a 1gbit (unshaped) link up
> with a 100Mbit down, the classic rrul 4 upload and 4 download flows,
> with the ping measurement....
>
> Just an across the board win, unless the tcp gods rain hellfire down
> on us. And wow, look at all those acks that got killed.
>
>  backlog 0b 0p requeues 1
>  memory used: 317312b of 5000000b
>  capacity estimate: 100Mbit
>                  Bulk   Best Effort      Voice
>   thresh      6250Kbit     100Mbit      25Mbit
>   target         5.0ms       5.0ms       5.0ms
>   interval     100.0ms     100.0ms      10.0ms
>   pk_delay         2us        10us        53us
>   av_delay         1us         1us         4us
>   sp_delay         1us         1us         3us
>   pkts          228783     1937474      631425
>   bytes      104982588  1189472341   380759260
>   way_inds           0           0           0
>   way_miss           6          63          19
>   way_cols           0           0           0
>   drops           6076        2091        1993
>   marks              0           0           0
>   ack_drop       67510      135880      102528
>   sp_flows           0           1           0
>   bk_flows           0           0           1
>   un_flows           0           0           0
>   max_len         6056       15140       10598
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cake] ack filter rrul result at 1000/100

[Dave Taht]

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

This is a much saner test result[1], showing about a 20% improvement
under the rrul_be test. I scaled back the topology to two instances of
cake on the middlebox, shaping to 100mbits on one side and 10mbits on
the other, and flipped filtering on or off. The win will improve more
with upload/download ratios of ever worse than 10/1, and the rrul is
not exactly a test of real traffic.

What other ratios are out there, particularly in the dsl world?

I can think of a few ways to get more acks to filter out, for example,
not using the "sparse flow optimization" for acks.

[1] it also turned out my test target box, an odroid c2, couldn't push
more than 500mbits bidir in the first place.

[-- Attachment #2: rrul_be-2017-11-15T201221.312953.ack_filter_100Mbit_10Mbit.flent.gz --]
[-- Type: application/x-gzip, Size: 83889 bytes --]

[-- Attachment #3: rrul_be-2017-11-15T201510.970394.no_ack_filter_100Mbit_10Mbit.flent.gz --]
[-- Type: application/x-gzip, Size: 82641 bytes --]

[-- Attachment #4: rrul_be_-_ack-filter-100mbit-10mbit.png --]
[-- Type: image/png, Size: 993708 bytes --]

[-- Attachment #5: odroid_c2_limits.png --]
[-- Type: image/png, Size: 66686 bytes --]

Re: [Cake] ack filter rrul result at 1000/100

[Sebastian Moeller]

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

Hi Dave,


> On Nov 16, 2017, at 05:28, Dave Taht <dave.taht@gmail.com> wrote:
> 
> This is a much saner test result[1], showing about a 20% improvement
> under the rrul_be test. I scaled back the topology to two instances of
> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> the other, and flipped filtering on or off. The win will improve more
> with upload/download ratios of ever worse than 10/1, and the rrul is
> not exactly a test of real traffic.
> 
> What other ratios are out there, particularly in the dsl world?

All over the place ;) the nominal ratios often are (taken from Deutsche Tekekom):
ADSL:
16/1			= 16/1
16/2.5 		= 6.4/1	(this is the default)
16/0.8 		= 20/1
according to https://en.wikipedia.org/wiki/G.992.5 some ISPs even do
20/0.768 		= 26/1
But these are the upper limits for those plans any many users will see less:
The extreme cases according to the contract would be (exemplary taken fro Deutsche Telekom):
6.016/0.288 	= 20.9/1
2.047.0.224 	= 2./1
16/0.704 		= 22.7/1
But note that these last cases are unrealistic as on ADSL-links the upstream tends to be more robust than the downstream, so the realistic downstream for the listed upstreams will be well below the listed values (otherwise the line needs to be checked for external noise sources, I guess).

VDSL2:
16/1 	= 16/1 (rare)
25/5 	= 5/1
50/10 	= 5/1
100/40 	= 2.5/1
SVDSL (VDSL2 AnnexQ):
estimated 250/40 = 6.25/1

On the DOCSIS side I see:
500/50 = 10/1 
400/25 = 16/1
200/12 = 16.7/1
100/6 = 16.7/1
32/2 = 16/1
(I just skip the extreme cases for VDSL


But at least in Germany most DOCISS ISPs actually allot more gross bandwidth than put in the contract, but I assume the ratios to not change too much. I also read in a cisco document that ACK filtering might be performed by some cable ISPs already...

In short I guess there should be quite a number of end users experiencing downstream/upstream asymmetries > 10/1, with 16/1 probably an important number (at least in Germany).

> 
> I can think of a few ways to get more acks to filter out, for example,
> not using the "sparse flow optimization" for acks.

	Not using GRO/GSO/TSO on sender and receiver ;)

Best Regards
	Sebastian

> 
> [1] it also turned out my test target box, an odroid c2, couldn't push
> more than 500mbits bidir in the first place.

[-- Attachment #2: rrul_be-2017-11-15T201221.312953.ack_filter_100Mbit_10Mbit.flent.gz --]
[-- Type: application/x-gzip, Size: 83889 bytes --]

[-- Attachment #3: rrul_be-2017-11-15T201510.970394.no_ack_filter_100Mbit_10Mbit.flent.gz --]
[-- Type: application/x-gzip, Size: 82641 bytes --]

[-- Attachment #4: rrul_be_-_ack-filter-100mbit-10mbit.png --]
[-- Type: image/png, Size: 993708 bytes --]

[-- Attachment #5: odroid_c2_limits.png --]
[-- Type: image/png, Size: 66686 bytes --]

[-- Attachment #6: Type: text/plain, Size: 146 bytes --]

> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] ack filter rrul result at 1000/100

[Bret Towe]

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

I have a docsis setup atm that is 300/7


On Nov 15, 2017 8:28 PM, "Dave Taht" <dave.taht@gmail.com> wrote:

> This is a much saner test result[1], showing about a 20% improvement
> under the rrul_be test. I scaled back the topology to two instances of
> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> the other, and flipped filtering on or off. The win will improve more
> with upload/download ratios of ever worse than 10/1, and the rrul is
> not exactly a test of real traffic.
>
> What other ratios are out there, particularly in the dsl world?
>
> I can think of a few ways to get more acks to filter out, for example,
> not using the "sparse flow optimization" for acks.
>
> [1] it also turned out my test target box, an odroid c2, couldn't push
> more than 500mbits bidir in the first place.
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>

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

Re: [Cake] ack filter rrul result at 1000/100

[Sebastian Moeller]

> On Nov 16, 2017, at 14:55, Bret Towe <bret.towe@gmail.com> wrote:
> 
> I have a docsis setup atm that is 300/7

300/7 = 42.9/1

This is extreme, I do not envy you at all. I would venture a guess that your ISP would be a prime candidate for doing ACK filtering/thinning in its CPE. Is there an easy way to compare sent versus received ACKs over the internet?

Best Regards


> 
> 
> On Nov 15, 2017 8:28 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
> This is a much saner test result[1], showing about a 20% improvement
> under the rrul_be test. I scaled back the topology to two instances of
> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> the other, and flipped filtering on or off. The win will improve more
> with upload/download ratios of ever worse than 10/1, and the rrul is
> not exactly a test of real traffic.
> 
> What other ratios are out there, particularly in the dsl world?
> 
> I can think of a few ways to get more acks to filter out, for example,
> not using the "sparse flow optimization" for acks.
> 
> [1] it also turned out my test target box, an odroid c2, couldn't push
> more than 500mbits bidir in the first place.
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] ack filter rrul result at 1000/100

[Bret Towe]

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

I'm willing to-do tests just let me know what's required to-do so
current "router" is an arch Linux computer connected directly to the modem

On Nov 16, 2017 6:29 AM, "Sebastian Moeller" <moeller0@gmx.de> wrote:

>
> > On Nov 16, 2017, at 14:55, Bret Towe <bret.towe@gmail.com> wrote:
> >
> > I have a docsis setup atm that is 300/7
>
> 300/7 = 42.9/1
>
> This is extreme, I do not envy you at all. I would venture a guess that
> your ISP would be a prime candidate for doing ACK filtering/thinning in its
> CPE. Is there an easy way to compare sent versus received ACKs over the
> internet?
>
> Best Regards
>
>
> >
> >
> > On Nov 15, 2017 8:28 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
> > This is a much saner test result[1], showing about a 20% improvement
> > under the rrul_be test. I scaled back the topology to two instances of
> > cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> > the other, and flipped filtering on or off. The win will improve more
> > with upload/download ratios of ever worse than 10/1, and the rrul is
> > not exactly a test of real traffic.
> >
> > What other ratios are out there, particularly in the dsl world?
> >
> > I can think of a few ways to get more acks to filter out, for example,
> > not using the "sparse flow optimization" for acks.
> >
> > [1] it also turned out my test target box, an odroid c2, couldn't push
> > more than 500mbits bidir in the first place.
> >
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
> >
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>
>

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

Re: [Cake] ack filter rrul result at 1000/100

[Jonathan Morton]

On 16/11/17 15:55, Bret Towe wrote:
> I have a docsis setup atm that is 300/7

Obligatory:  https://www.youtube.com/watch?v=XnFSb8xcmN4

-- 
  - Jonathan Morton

Re: [Cake] ack filter rrul result at 1000/100

[Dave Taht]

Jonathan Morton <chromatix99@gmail.com> writes:

> On 16/11/17 15:55, Bret Towe wrote:
>> I have a docsis setup atm that is 300/7
>
> Obligatory:  https://www.youtube.com/watch?v=XnFSb8xcmN4

Thank you. That caused coffee to blow through my nose at the same time
the speakers blew out my officemates.

If we need a theme song, that one is right up toke's alley....