[Cake] Configuring cake for VDSL2 bridged connection

[Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

I am using a TalkTalk (UK) VDSL2 connection via bridged PTM to my TP-LINK
Archer C7 V2. I am running LEDE.

TalkTalk uses DHCP to obtain an IP address and not DHCP as most other ISPs
do.

I am trying to configure cake and I see these options on bufferbloat.net:


*There are eight new keywords which deal with the basic ADSL
configurations. These switch on ATM cell-framing compensation, and set the
overhead based on the raw IP packet as a baseline.*

*ipoa-vcmux (8)*
*ipoa-llcsnap (16)*
*bridged-vcmux (24)*
*bridged-llcsnap (32)*
*pppoa-vcmux (10)*
*pppoa-llc (14)*
*pppoe-vcmux (32)*
*pppoe-llcsnap (40)bvn*


How do I go about using these with OpenWRT?

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[moeller0]

Hi techicist,


> On Aug 23, 2016, at 15:44 , techicist@gmail.com wrote:
> 
> I am using a TalkTalk (UK) VDSL2 connection via bridged PTM to my TP-LINK Archer C7 V2. I am running LEDE.
> 
> TalkTalk uses DHCP to obtain an IP address and not DHCP as most other ISPs do.

	I take it that one of the DHCPs should read PPPoE?

> 
> I am trying to configure cake and I see these options on bufferbloat.net:
> 
> There are eight new keywords which deal with the basic ADSL configurations. These switch on ATM cell-framing compensation, and set the overhead based on the raw IP packet as a baseline.
> 
> ipoa-vcmux (8)
> ipoa-llcsnap (16)
> bridged-vcmux (24)
> bridged-llcsnap (32)
> pppoa-vcmux (10)
> pppoa-llc (14)
> pppoe-vcmux (32)
> pppoe-llcsnap (40)bvn
> 
> How do I go about using these with OpenWRT?

	(C) None of the above ;)

Really, all f the above keywords only deal with encapsulations used on ATM links, not PTM links. All of these will automatically enable ATM cell accounting and hence will not do the right thing on PTM links even if the per-packet overhead should be correct. cake offers two PTM specific keywords, pppoe-ptm and pppoe-bridged that translate into 27 and 19 bytes respectively. It looks like they are not well enough documented though*. I would recommend to simply ignoring these keywords wholesale and use the explicit “overhead 27” statement instead, but we are getting ahead of ourselves here:

The first question is what is the true bottleneck link and what bandwidth and encapsulation is in use on that link. Often the VDSL2-link is the true bottleneck, but some ISPS like DTAG in Germany actually implement a shaper/policer at the BRAS/BNG level with lower thresholds than the vdsl2 link itself. Be that is it may, the first issue is figuring out the relevant bottleneck link bandwidth (we just assume that your ISP has no shaper in use):

Look into the status page of your VDSL2-modem and write down the values of the actual synchronization bandwidth for uplink and downlink.

Multiply both with 64/65 = 0.984615384615 as VDSL2 uses a continuous 64/65 encapsulation that will eat roughly 1.6% of the sync bandwidth; this now are your reference values for what can be sent over that link. Often 85 to 90%** of that reference bandwidth works well for downlinks, uplinks can work well up to 100% of the reference. I initially recommend to set both uplink and downlink to 50% of the reference values and run a speedtest (e.q. the dslreports of the sourceforge one that both also measure latency under load, or preferentially flent to a well connected netperf server) to get a feeling for the best case latency uunder load increase (at 50% of line rate both a potential ISPs shper as well as the real pe-packet overhead will not matter under real-world conditions).

Next you need to figure out the per-packet overhead, here is my handy cheat sheet:

###ATM: see RFC2684 http://www.faqs.org/rfcs/rfc2684.html
ATM (ADSL2+ PPPoE):	
	2 Byte PPP + 6 Byte PPPoE + 6 destination MAC + 6 source MAC + 2 ethertype + 3 ATM LLC + 5 ATM SNAP + 2 ATM pad + 8 ATM AAL5 SAR = 40 Byte
ATM (ADSL2+ PPPoE VLAN): 
	2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + + 6 destination MAC + 6 source MAC + 2 ethertype + 3 ATM LLC + 5 ATM SNAP + 2 ATM pad + 8 ATM AAL5 SAR = 44 Byte

###VDSL2 see IEEE 802.3-2012 61.3 relevant for VDSL2: Note VDSL2 typically transports full ethernet frames including the FCS (shown as COMON below) 
VDSL2 (PPPoE VLAN)
	2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + 1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), = 16 Byte
	COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
	total: 34 Byte
VDSL2 (your case?)
	1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), = 4 Byte
	COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
	total: 22 Byte

### Ethernet
FAST-ETHERNET (should also be valid for GB ethernet): 
	7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter frame gap (IFG) = 20 Byte
	COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
	total: 38 Bytes worth of transmission time


So a per-packet overhead of 22 seems correct for your case. But the linux kernel will already add 14 bytes (for the part of the ethernet header it actually send to the device the MACs and the ethertype) automatically for most interfaces, so in all likelihood (assuming you connect via ethernet from your router to the DSL modem) you should specify 22-14 = 8 Bytes per packet overhead for SQM.


Now redo the tests from before but first keep the uplink at 50% and iteratively increase the downlink until you encounter too much latency under load increase (for your taste); set the uplink to 50% and iteratively increase the uplink until latency will increase (which might only happen once you increase above the uplink reference value calculated above). Finally set both values to the the independently tested optimal values and test again. Please note that reaching 100% of reference on egress without bufferbloat showing up is a decent indicator that you did not underestimate the per-packet overhead. The opposite unfortunately is not true, as you might simply have run into an ISP shaper.


*) There is still an open discussion how to best deal with the fact that there is considerable complexity in the different encapsulations schemes used on ATM and PTM links. I would prefer a table of encapsulation schemes wit the resulting numerical overheads and cake simply exposing the explicit numeric “overhead NN” argument. But others have argued that named symbolic keywords for common variant can be quite helpful. (My counter argument is that without more explanation neither alternative is self-explanatory and at least the numeric alternative is less work to maintain). But please let us know your opinion as a user.

**) Downlink shaping is more approximate than uplink shaping as sufficiently high incoming traffic rates will sort of back-spill also into your ISPs uplink buffers and that will cause unwanted latency under load increases that get more unlikely the larger the speed delta between the true bottleneck and the artificial bottleneck created by SQM actually is. In essence downlink shaping requires larger margins than uplink shaping…
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Hello,

Thank you for your quick reply.

I take it that one of the DHCPs should read PPPoE?


Yes, you are quite correct. It should read: "TalkTalk uses DHCP to obtain
an IP address and not PPPoE as most other ISPs do." But I think you
understood that :)

My sync speeds on VDSL2 have been very stable for the last 84+ days so my
calculated figures will stay the same for some time, I would like to think.
My DS sync speed is 58976Kbps and thus I have calculated a reference value
of 58068Kbps based on your formula. The US sync speed is 10422Kbps and the
reference value for this is 10261Kbps.

Setting the reference values to 50%, I have: 29034Kbps for the DS; and
5130Kbps for the US. I will test with these numbers shortly. Am I right to
assume I can just paste these into the SQM interface on LuCI? I will set
the "Queuing discipline" to *cake* and the "Queue setup script" to
*piece_of_cake.qos*.

I assume also at this stage, to set "Which link layer to account for" as *none
(default)*?

I will then increment the values I have pasted into LuCI (assuming that is
correct) as you have said. At this point, with an assumed overhead of 8, do
I just choose *Ethernet with overhead...* and then set the "Per Packet
Overhead (byte)" to *8*?

Is there any benefit of going through UCI?

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Sebastian Moeller]

Hello techicist,

On August 23, 2016 5:13:19 PM GMT+02:00, "techicist@gmail.com" <techicist@gmail.com> wrote:
>Hello,
>
>Thank you for your quick reply.
>
>I take it that one of the DHCPs should read PPPoE?
>
>
>Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
>obtain
>an IP address and not PPPoE as most other ISPs do." But I think you
>understood that :)
>
>My sync speeds on VDSL2 have been very stable for the last 84+ days so
>my
>calculated figures will stay the same for some time, I would like to
>think.

Yes, that is what I see as well.

>My DS sync speed is 58976Kbps and thus I have calculated a reference
>value
>of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
>the
>reference value for this is 10261Kbps.
>
>Setting the reference values to 50%, I have: 29034Kbps for the DS; and
>5130Kbps for the US. I will test with these numbers shortly. Am I right
>to
>assume I can just paste these into the SQM interface on LuCI? 

       Yes, that should work.

>I will set
>the "Queuing discipline" to *cake* and the "Queue setup script" to
>*piece_of_cake.qos*.
>
>I assume also at this stage, to set "Which link layer to account for"
>as *none
>(default)*?

        Should work, but also Ethernet should work, as long as you do not specify anything, or rather -14 ;)

>
>I will then increment the values I have pasted into LuCI (assuming that
>is
>correct) as you have said. At this point, with an assumed overhead of
>8, do
>I just choose *Ethernet with overhead...* and then set the "Per Packet
>Overhead (byte)" to *8*?

Yes. In essence that is the trick, it might make sense to look at cake' statistics especially the max length field, which if you have lla set at none reach 1514 if the kernel automatically adds it's 14 bytes.


>
>Is there any benefit of going through UCI?

        Only if you despise the GUI or only have ssh access, I guess... Functionally it should boil down to the same, as the GUI simply fills /etc/config/sqm with values and then calls /etc/init.d/sqm to actually start the scripts...

Best Regards
        Sebastian


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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Kevin Darbyshire-Bryant]

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

The 'less wrong' overhead figure is 12.  The incumbent telco BT who 
provide access to the 'last mile' (or the bit from the nearest FTTC 
cabinet and the property) use a VLAN tag, adding another 4 bytes to each 
frame going over the wire.


The above guesswork based on SIN498 http://www.sinet.bt.com/sinet/SINs/  
(and inspection of the default settings on a BT supplied modem)  I offer 
it as in theory being 'less wrong' rather than a practical 'correct'.


On 23/08/16 16:13, techicist@gmail.com wrote:
> Hello,
>
> Thank you for your quick reply.
>
>     I take it that one of the DHCPs should read PPPoE?
>
>
> Yes, you are quite correct. It should read: "TalkTalk uses DHCP to 
> obtain an IP address and not PPPoE as most other ISPs do." But I think 
> you understood that :)
>
> My sync speeds on VDSL2 have been very stable for the last 84+ days 
> so my calculated figures will stay the same for some time, I would 
> like to think. My DS sync speed is 58976Kbps and thus I have 
> calculated a reference value of 58068Kbps based on your formula. The 
> US sync speed is 10422Kbps and the reference value for this is 10261Kbps.
>
> Setting the reference values to 50%, I have: 29034Kbps for the DS; and 
> 5130Kbps for the US. I will test with these numbers shortly. Am I 
> right to assume I can just paste these into the SQM interface on LuCI? 
> I will set the "Queuing discipline" to /cake/ and the "Queue setup 
> script" to /piece_of_cake.qos/.
>
> I assume also at this stage, to set "Which link layer to account for" 
> as /none (default)/?
>
> I will then increment the values I have pasted into LuCI (assuming 
> that is correct) as you have said. At this point, with an assumed 
> overhead of 8, do I just choose /Ethernet with overhead.../ and then 
> set the "Per Packet Overhead (byte)" to /8/?
>
> Is there any benefit of going through UCI?
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

I have today been using flent to do RRUL tests with the values set at 50%.

I have uploaded the first test I have performed. It can be seen at,
http://imgur.com/6DrMJKI.

I'm a bit confused why the DS speed is only 7Mb/s when every other speed
test I have done is around 28Mb/s (as it should be). Can anyone explain why
this might be? Am I doing something wrong?

I would appreciate an expert analysis of the graph, if possible :)

On 23 August 2016 at 21:09, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hello techicist,
>
> On August 23, 2016 5:13:19 PM GMT+02:00, "techicist@gmail.com" <
> techicist@gmail.com> wrote:
> >Hello,
> >
> >Thank you for your quick reply.
> >
> >I take it that one of the DHCPs should read PPPoE?
> >
> >
> >Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
> >obtain
> >an IP address and not PPPoE as most other ISPs do." But I think you
> >understood that :)
> >
> >My sync speeds on VDSL2 have been very stable for the last 84+ days so
> >my
> >calculated figures will stay the same for some time, I would like to
> >think.
>
> Yes, that is what I see as well.
>
> >My DS sync speed is 58976Kbps and thus I have calculated a reference
> >value
> >of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
> >the
> >reference value for this is 10261Kbps.
> >
> >Setting the reference values to 50%, I have: 29034Kbps for the DS; and
> >5130Kbps for the US. I will test with these numbers shortly. Am I right
> >to
> >assume I can just paste these into the SQM interface on LuCI?
>
>        Yes, that should work.
>
> >I will set
> >the "Queuing discipline" to *cake* and the "Queue setup script" to
> >*piece_of_cake.qos*.
> >
> >I assume also at this stage, to set "Which link layer to account for"
> >as *none
> >(default)*?
>
>         Should work, but also Ethernet should work, as long as you do not
> specify anything, or rather -14 ;)
>
> >
> >I will then increment the values I have pasted into LuCI (assuming that
> >is
> >correct) as you have said. At this point, with an assumed overhead of
> >8, do
> >I just choose *Ethernet with overhead...* and then set the "Per Packet
> >Overhead (byte)" to *8*?
>
> Yes. In essence that is the trick, it might make sense to look at cake'
> statistics especially the max length field, which if you have lla set at
> none reach 1514 if the kernel automatically adds it's 14 bytes.
>
>
> >
> >Is there any benefit of going through UCI?
>
>         Only if you despise the GUI or only have ssh access, I guess...
> Functionally it should boil down to the same, as the GUI simply fills
> /etc/config/sqm with values and then calls /etc/init.d/sqm to actually
> start the scripts...
>
> Best Regards
>         Sebastian
>
>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Cake mailing list
> >Cake@lists.bufferbloat.net
> >https://lists.bufferbloat.net/listinfo/cake
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Many apologies, the link should be, http://imgur.com/6DrMJKI.

On 24 August 2016 at 18:01, techicist@gmail.com <techicist@gmail.com> wrote:

> I have today been using flent to do RRUL tests with the values set at 50%.
>
> I have uploaded the first test I have performed. It can be seen at,
> http://imgur.com/6DrMJKI.
>
> I'm a bit confused why the DS speed is only 7Mb/s when every other speed
> test I have done is around 28Mb/s (as it should be). Can anyone explain why
> this might be? Am I doing something wrong?
>
> I would appreciate an expert analysis of the graph, if possible :)
>
> On 23 August 2016 at 21:09, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hello techicist,
>>
>> On August 23, 2016 5:13:19 PM GMT+02:00, "techicist@gmail.com" <
>> techicist@gmail.com> wrote:
>> >Hello,
>> >
>> >Thank you for your quick reply.
>> >
>> >I take it that one of the DHCPs should read PPPoE?
>> >
>> >
>> >Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
>> >obtain
>> >an IP address and not PPPoE as most other ISPs do." But I think you
>> >understood that :)
>> >
>> >My sync speeds on VDSL2 have been very stable for the last 84+ days so
>> >my
>> >calculated figures will stay the same for some time, I would like to
>> >think.
>>
>> Yes, that is what I see as well.
>>
>> >My DS sync speed is 58976Kbps and thus I have calculated a reference
>> >value
>> >of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
>> >the
>> >reference value for this is 10261Kbps.
>> >
>> >Setting the reference values to 50%, I have: 29034Kbps for the DS; and
>> >5130Kbps for the US. I will test with these numbers shortly. Am I right
>> >to
>> >assume I can just paste these into the SQM interface on LuCI?
>>
>>        Yes, that should work.
>>
>> >I will set
>> >the "Queuing discipline" to *cake* and the "Queue setup script" to
>> >*piece_of_cake.qos*.
>> >
>> >I assume also at this stage, to set "Which link layer to account for"
>> >as *none
>> >(default)*?
>>
>>         Should work, but also Ethernet should work, as long as you do not
>> specify anything, or rather -14 ;)
>>
>> >
>> >I will then increment the values I have pasted into LuCI (assuming that
>> >is
>> >correct) as you have said. At this point, with an assumed overhead of
>> >8, do
>> >I just choose *Ethernet with overhead...* and then set the "Per Packet
>> >Overhead (byte)" to *8*?
>>
>> Yes. In essence that is the trick, it might make sense to look at cake'
>> statistics especially the max length field, which if you have lla set at
>> none reach 1514 if the kernel automatically adds it's 14 bytes.
>>
>>
>> >
>> >Is there any benefit of going through UCI?
>>
>>         Only if you despise the GUI or only have ssh access, I guess...
>> Functionally it should boil down to the same, as the GUI simply fills
>> /etc/config/sqm with values and then calls /etc/init.d/sqm to actually
>> start the scripts...
>>
>> Best Regards
>>         Sebastian
>>
>>
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >Cake mailing list
>> >Cake@lists.bufferbloat.net
>> >https://lists.bufferbloat.net/listinfo/cake
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
>

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

My apologies again. The link should be, http://imgur.com/6DrMJKI

On 24 August 2016 at 18:03, techicist@gmail.com <techicist@gmail.com> wrote:

> Many apologies, the link should be, http://imgur.com/6DrMJKI.
>
> On 24 August 2016 at 18:01, techicist@gmail.com <techicist@gmail.com>
> wrote:
>
>> I have today been using flent to do RRUL tests with the values set at 50%.
>>
>> I have uploaded the first test I have performed. It can be seen at,
>> http://imgur.com/6DrMJKI.
>>
>> I'm a bit confused why the DS speed is only 7Mb/s when every other speed
>> test I have done is around 28Mb/s (as it should be). Can anyone explain why
>> this might be? Am I doing something wrong?
>>
>> I would appreciate an expert analysis of the graph, if possible :)
>>
>> On 23 August 2016 at 21:09, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>> Hello techicist,
>>>
>>> On August 23, 2016 5:13:19 PM GMT+02:00, "techicist@gmail.com" <
>>> techicist@gmail.com> wrote:
>>> >Hello,
>>> >
>>> >Thank you for your quick reply.
>>> >
>>> >I take it that one of the DHCPs should read PPPoE?
>>> >
>>> >
>>> >Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
>>> >obtain
>>> >an IP address and not PPPoE as most other ISPs do." But I think you
>>> >understood that :)
>>> >
>>> >My sync speeds on VDSL2 have been very stable for the last 84+ days so
>>> >my
>>> >calculated figures will stay the same for some time, I would like to
>>> >think.
>>>
>>> Yes, that is what I see as well.
>>>
>>> >My DS sync speed is 58976Kbps and thus I have calculated a reference
>>> >value
>>> >of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
>>> >the
>>> >reference value for this is 10261Kbps.
>>> >
>>> >Setting the reference values to 50%, I have: 29034Kbps for the DS; and
>>> >5130Kbps for the US. I will test with these numbers shortly. Am I right
>>> >to
>>> >assume I can just paste these into the SQM interface on LuCI?
>>>
>>>        Yes, that should work.
>>>
>>> >I will set
>>> >the "Queuing discipline" to *cake* and the "Queue setup script" to
>>> >*piece_of_cake.qos*.
>>> >
>>> >I assume also at this stage, to set "Which link layer to account for"
>>> >as *none
>>> >(default)*?
>>>
>>>         Should work, but also Ethernet should work, as long as you do
>>> not specify anything, or rather -14 ;)
>>>
>>> >
>>> >I will then increment the values I have pasted into LuCI (assuming that
>>> >is
>>> >correct) as you have said. At this point, with an assumed overhead of
>>> >8, do
>>> >I just choose *Ethernet with overhead...* and then set the "Per Packet
>>> >Overhead (byte)" to *8*?
>>>
>>> Yes. In essence that is the trick, it might make sense to look at cake'
>>> statistics especially the max length field, which if you have lla set at
>>> none reach 1514 if the kernel automatically adds it's 14 bytes.
>>>
>>>
>>> >
>>> >Is there any benefit of going through UCI?
>>>
>>>         Only if you despise the GUI or only have ssh access, I guess...
>>> Functionally it should boil down to the same, as the GUI simply fills
>>> /etc/config/sqm with values and then calls /etc/init.d/sqm to actually
>>> start the scripts...
>>>
>>> Best Regards
>>>         Sebastian
>>>
>>>
>>> >
>>> >
>>> >-----------------------------------------------------------
>>> -------------
>>> >
>>> >_______________________________________________
>>> >Cake mailing list
>>> >Cake@lists.bufferbloat.net
>>> >https://lists.bufferbloat.net/listinfo/cake
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>
>>
>

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

The RRUL graph shows 4 simultaneous flows.  The total of 4 flows 
averaging 7Mb/s is 28Mb/s :).

I think it's more obvious when you know what the legend means. The flows 
have different service markings (which may or may not have any effect).

BE = "Best effort" (neither high nor low priority)
BK = Background
EF = "Expedited forwarding"

I think CS5 is another high priority mark.  The abbreviation doesn't 
mean anything specific, it's just how it's coded really...  it's a bit 
of a swamp, because there's no standard that works internet-wide, even 
for a low priority mark.  IIRC there's one mark that ends up being 
treated as low priority in one "standard" and high priority in another.

On 24/08/16 18:03, techicist@gmail.com wrote:
> My apologies again. The link should be, http://imgur.com/6DrMJKI
>
> On 24 August 2016 at 18:03, techicist@gmail.com <techicist@gmail.com> wrote:
>
>> Many apologies, the link should be, http://imgur.com/6DrMJKI.
>>
>> On 24 August 2016 at 18:01, techicist@gmail.com <techicist@gmail.com>
>> wrote:
>>
>>> I have today been using flent to do RRUL tests with the values set at 50%.
>>>
>>> I have uploaded the first test I have performed. It can be seen at,
>>> http://imgur.com/6DrMJKI.
>>>
>>> I'm a bit confused why the DS speed is only 7Mb/s when every other speed
>>> test I have done is around 28Mb/s (as it should be). Can anyone explain why
>>> this might be? Am I doing something wrong?
>>>
>>> I would appreciate an expert analysis of the graph, if possible :)
>>>
>>> On 23 August 2016 at 21:09, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>
>>>> Hello techicist,
>>>>
>>>> On August 23, 2016 5:13:19 PM GMT+02:00, "techicist@gmail.com" <
>>>> techicist@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> Thank you for your quick reply.
>>>>>
>>>>> I take it that one of the DHCPs should read PPPoE?
>>>>>
>>>>>
>>>>> Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
>>>>> obtain
>>>>> an IP address and not PPPoE as most other ISPs do." But I think you
>>>>> understood that :)
>>>>>
>>>>> My sync speeds on VDSL2 have been very stable for the last 84+ days so
>>>>> my
>>>>> calculated figures will stay the same for some time, I would like to
>>>>> think.
>>>> Yes, that is what I see as well.
>>>>
>>>>> My DS sync speed is 58976Kbps and thus I have calculated a reference
>>>>> value
>>>>> of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
>>>>> the
>>>>> reference value for this is 10261Kbps.
>>>>>
>>>>> Setting the reference values to 50%, I have: 29034Kbps for the DS; and
>>>>> 5130Kbps for the US. I will test with these numbers shortly. Am I right
>>>>> to
>>>>> assume I can just paste these into the SQM interface on LuCI?
>>>>         Yes, that should work.
>>>>
>>>>> I will set
>>>>> the "Queuing discipline" to *cake* and the "Queue setup script" to
>>>>> *piece_of_cake.qos*.
>>>>>
>>>>> I assume also at this stage, to set "Which link layer to account for"
>>>>> as *none
>>>>> (default)*?
>>>>          Should work, but also Ethernet should work, as long as you do
>>>> not specify anything, or rather -14 ;)
>>>>
>>>>> I will then increment the values I have pasted into LuCI (assuming that
>>>>> is
>>>>> correct) as you have said. At this point, with an assumed overhead of
>>>>> 8, do
>>>>> I just choose *Ethernet with overhead...* and then set the "Per Packet
>>>>> Overhead (byte)" to *8*?
>>>> Yes. In essence that is the trick, it might make sense to look at cake'
>>>> statistics especially the max length field, which if you have lla set at
>>>> none reach 1514 if the kernel automatically adds it's 14 bytes.
>>>>
>>>>
>>>>> Is there any benefit of going through UCI?
>>>>          Only if you despise the GUI or only have ssh access, I guess...
>>>> Functionally it should boil down to the same, as the GUI simply fills
>>>> /etc/config/sqm with values and then calls /etc/init.d/sqm to actually
>>>> start the scripts...
>>>>
>>>> Best Regards
>>>>          Sebastian
>>>>
>>>>
>>>>>
>>>>> -----------------------------------------------------------
>>>> -------------
>>>>> _______________________________________________
>>>>> Cake mailing list
>>>>> Cake@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/cake
>>>> --
>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>>
>>>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Thanks for the reply. I understand now 😀

What can be taken from these graphs? I'm afraid I really am lost now.

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

So you can read off (+calculate) overall throughput, in both directions.

And it looks like your latency under load rises by only about 2ms.  
That's the sort of thing we're aiming for.

Pure codel aims for 5ms, so I take it you're using fq_codel. And... yes

(1500 * 8) / 4_000_000 = 0.003

It takes 3ms to transmit a full packet in the slower direction. So when 
it's busy, ping can be delayed on average by 1.5ms (while the current 
packet is transmitted).  Something like that anyway.


On 24/08/16 20:33, techicist@gmail.com wrote:
> Thanks for the reply. I understand now 😀
>
> What can be taken from these graphs? I'm afraid I really am lost now.
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 24/08/16 20:47, Alan Jenkins wrote:
> So you can read off (+calculate) overall throughput, in both directions.
>
> And it looks like your latency under load rises by only about 2ms.  
> That's the sort of thing we're aiming for.
>
> Pure codel aims for 5ms, so I take it you're using fq_codel.
/reads subject line

or using standard cake, and not passing `flowblind` to disable the fair 
queuing

> And... yes
>
> (1500 * 8) / 4_000_000 = 0.003
>
> It takes 3ms to transmit a full packet in the slower direction. So 
> when it's busy, ping can be delayed on average by 1.5ms (while the 
> current packet is transmitted).  Something like that anyway.
>
>
> On 24/08/16 20:33, techicist@gmail.com wrote:
>> Thanks for the reply. I understand now 😀
>>
>> What can be taken from these graphs? I'm afraid I really am lost now.
>>
>>
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>


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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Sorry, what is flowblind? Yes, I am using cake :)

So is that latency increase when uploading and downloading? And so I should
be aiming to achieve that as I slowly increase the bandwidth?

On 24 August 2016 at 20:49, Alan Jenkins <alan.christopher.jenkins@gmail.com
> wrote:

> On 24/08/16 20:47, Alan Jenkins wrote:
>
> So you can read off (+calculate) overall throughput, in both directions.
>
> And it looks like your latency under load rises by only about 2ms.  That's
> the sort of thing we're aiming for.
>
> Pure codel aims for 5ms, so I take it you're using fq_codel.
>
> /reads subject line
>
> or using standard cake, and not passing `flowblind` to disable the fair
> queuing
>
> And... yes
>
> (1500 * 8) / 4_000_000 = 0.003
>
> It takes 3ms to transmit a full packet in the slower direction. So when
> it's busy, ping can be delayed on average by 1.5ms (while the current
> packet is transmitted).  Something like that anyway.
>
>
> On 24/08/16 20:33, techicist@gmail.com wrote:
>
> Thanks for the reply. I understand now 😀
>
> What can be taken from these graphs? I'm afraid I really am lost now.
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>
>
>
>

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 25/08/16 15:53, techicist@gmail.com wrote:
> Sorry, what is flowblind? Yes, I am using cake :)

flowblind gives you a single queue, who's maximum size is managed by (a 
modified) codel.  It's useful for testing the codel.

In the default (non- flowblind), each stream is randomly assigned to one 
of hundreds of queues.  In fact cake magically avoids flows sharing 
queues until they have to.  Then each queue is treated "fairly" w.r.t 
the bandwidth it can use.

> So is that latency increase when uploading and downloading? And so I should
> be aiming to achieve that as I slowly increase the bandwidth?

That's the general idea, yes.

For looking at latency statistics, FLENT also has a cumulative 
probability graph.

If you'd rather have the numbers summarized for you, you might prefer 
Richard's netperfrunner.  That's what I used to start with. It's not 
100% the same but very close.  (It's designed to only use ping for 
latency, which means it can use as close a target - on the other side of 
the ISP link - as possible.  E.g. taken from "traceroute".  I found that 
was useful for sensitivity).

https://github.com/richb-hanover/CeroWrtScripts

>
> On 24 August 2016 at 20:49, Alan Jenkins <alan.christopher.jenkins@gmail.com
>> wrote:
>> On 24/08/16 20:47, Alan Jenkins wrote:
>>
>> So you can read off (+calculate) overall throughput, in both directions.
>>
>> And it looks like your latency under load rises by only about 2ms.  That's
>> the sort of thing we're aiming for.
>>
>> Pure codel aims for 5ms, so I take it you're using fq_codel.
>>
>> /reads subject line
>>
>> or using standard cake, and not passing `flowblind` to disable the fair
>> queuing
>>
>> And... yes
>>
>> (1500 * 8) / 4_000_000 = 0.003
>>
>> It takes 3ms to transmit a full packet in the slower direction. So when
>> it's busy, ping can be delayed on average by 1.5ms (while the current
>> packet is transmitted).  Something like that anyway.
>>
>>
>> On 24/08/16 20:33, techicist@gmail.com wrote:
>>
>> Thanks for the reply. I understand now 😀
>>
>> What can be taken from these graphs? I'm afraid I really am lost now.
>>
>>
>>
>> _______________________________________________
>> 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: 4098 bytes --]

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Is flowblind likely to give better performance?

netperfrunner looks very useful. Thank you for that.

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[moeller0]

Hi techicist,

> On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote:
> 
> Is flowblind likely to give better performance?

	That depends on your definition of better, I guess. Typically flow-fair queuing seems to be what most people prefer (unless an application either does not respond to AQM signals or open an excessive amount of individual flows flow-fair queueing effectively treats most traffic sources equal, pretty much what people seem to want, add to this a bit of classification to exempt e.g. VOIP traffic from only getting its flow-fair share of the bandwidth and the whole thing also works reasonably well with slow links). People suffering from unruly applications (like mis-configured? bit-torrent clients or recently windows update) often ask for per-application fairness, but that is not something a router will ever be able to deliver in my opinion; the closest we get to this would be fairnes by internal or external end-IP addresses. Luckily cake offers just these modes “dsthost”, “srchost” and even better offers a combination modes that will on a first level attempt per host-IP fairness and within each host IP also per-flow fairness (“dual-srchost” and “dual-dsthost”, and even “triple-isolate” which systematically might be better called “dual-srchost-dsthost” since it offers fist level fairness based on an under-documented mix of src and dst addresses, but I digress). Please note that on a typical homerouter, due to NAT, all the IP addressed based fairness modes will not work for IPv4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically degrades into a computationally more intensive version of flow-fairness (as after NAT cake only sees the routers external IP for all internal hosts). This might have been more than you wanted to know…

Best Regards
	Sebastian

> 
> netperfrunner looks very useful. Thank you for that.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

So best to just leave well alone I think :)

I do have one question. I sometimes use the thinkbroadband.com Ping Monitor
and it shows my ping as being 40-50ms a lot of the time, even with cake.
What's going on here?

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 26/08/16 12:29, moeller0 wrote:
> Hi techicist,
>
>> On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote:
>>
>> Is flowblind likely to give better performance?
> 	That depends on your definition of better, I guess. Typically flow-fair queuing seems to be what most people prefer (unless an application either does not respond to AQM signals or open an excessive amount of individual flows flow-fair queueing effectively treats most traffic sources equal, pretty much what people seem to want, add to this a bit of classification to exempt e.g. VOIP traffic from only getting its flow-fair share of the bandwidth and the whole thing also works reasonably well with slow links). People suffering from unruly applications (like mis-configured? bit-torrent clients or recently windows update) often ask for per-application fairness, but that is not something a router will ever be able to deliver in my opinion; the closest we get to this would be fairnes by internal or external end-IP addresses. Luckily cake offers just these modes “dsthost”, “srchost” and even better offers a combination modes that will on a first level attempt per host-IP fairness and within each host IP also per-flow fairness (“dual-srchost” and “dual-dsthost”, and even “triple-isolate” which systematically might be better called “dual-srchost-dsthost” since it offers fist level fairness based on an under-documented mix of src and dst addresses, but I digress). Please note that on a typical homerouter, due to NAT, all the IP addressed based fairness modes will not work for IPv4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically degrades into a computationally more intensive version of flow-fairness (as after NAT cake only sees the routers external IP for all internal hosts). This might have been more than you wanted to know…
>
> Best Regards
> 	Sebastian

flowblind is an option for testing purposes or advanced use cases. The 
design goal for Cake is to avoid understanding and fiddling with options 
to get good performance for common cases.

If you try enabling flowblind, your latency under load will jump by 
5ms+.  "Head of line blocking".  A full queue will be 5ms.  This will 
delay flows which do not need a full fair share of the link, like VOIP 
or gaming.  Lower latency is  better for VOIP or gaming.

You should find this is small compared to the latency increase under 
load without cake.  You wouldn't notice it in web browsing. (Frankly I 
don't seem to notice 100ms extra latency in web browsing.

I run fq_codel for similar performance to cake, mainly to increase my 
confidence that torrent uploads don't have noticable effects for other 
household users.  Torrent downloads still suck, but I haven't seen any 
Cake results promoted on that basis.  It either needs to be fixed at the 
ISP end, or in the torrent software.  QUIC are emulating the 
competitiveness of 2x TCP flows in a single UDP flow. BT should be able 
to emulate half a TCP flow when downloading from two peers simultaneously).

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

How would I go about enabling flowblind in OpenWRT? :)

And the 5ms+ jump you're talking about, that would compare to an ideal 3ms
jump not using flowblind. Is that right?

We do use the connection for gaming and so it might be useful. Without
flowblind, are you saying that latency in games would be worse with just
standard cake?

Thanks so much for your help so far.

On 26 August 2016 at 12:52, Alan Jenkins <alan.christopher.jenkins@gmail.com
> wrote:

> On 26/08/16 12:29, moeller0 wrote:
>
> Hi techicist,
>
>
> On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote:
>
> Is flowblind likely to give better performance?
>
> 	That depends on your definition of better, I guess. Typically flow-fair queuing seems to be what most people prefer (unless an application either does not respond to AQM signals or open an excessive amount of individual flows flow-fair queueing effectively treats most traffic sources equal, pretty much what people seem to want, add to this a bit of classification to exempt e.g. VOIP traffic from only getting its flow-fair share of the bandwidth and the whole thing also works reasonably well with slow links). People suffering from unruly applications (like mis-configured? bit-torrent clients or recently windows update) often ask for per-application fairness, but that is not something a router will ever be able to deliver in my opinion; the closest we get to this would be fairnes by internal or external end-IP addresses. Luckily cake offers just these modes “dsthost”, “srchost” and even better offers a combination modes that will on a first level attempt per host-IP fairness and within each host IP also per-flow fairness (“dual-srchost” and “dual-dsthost”, and even “triple-isolate” which systematically might be better called “dual-srchost-dsthost” since it offers fist level fairness based on an under-documented mix of src and dst addresses, but I digress). Please note that on a typical homerouter, due to NAT, all the IP addressed based fairness modes will not work for IPv4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically degrades into a computationally more intensive version of flow-fairness (as after NAT cake only sees the routers external IP for all internal hosts). This might have been more than you wanted to know…
>
> Best Regards
> 	Sebastian
>
>
> flowblind is an option for testing purposes or advanced use cases.  The
> design goal for Cake is to avoid understanding and fiddling with options to
> get good performance for common cases.
>
> If you try enabling flowblind, your latency under load will jump by 5ms+.
> "Head of line blocking".  A full queue will be 5ms.  This will delay flows
> which do not need a full fair share of the link, like VOIP or gaming.
> Lower latency is  better for VOIP or gaming.
>
> You should find this is small compared to the latency increase under load
> without cake.  You wouldn't notice it in web browsing.  (Frankly I don't
> seem to notice 100ms extra latency in web browsing.
>
> I run fq_codel for similar performance to cake, mainly to increase my
> confidence that torrent uploads don't have noticable effects for other
> household users.  Torrent downloads still suck, but I haven't seen any Cake
> results promoted on that basis.  It either needs to be fixed at the ISP
> end, or in the torrent software.  QUIC are emulating the competitiveness of
> 2x TCP flows in a single UDP flow.  BT should be able to emulate half a TCP
> flow when downloading from two peers simultaneously).
>

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 26/08/16 13:04, techicist@gmail.com wrote:
> How would I go about enabling flowblind in OpenWRT? :)

Add the flowblind option.  If you're using SQM-scripts, the GUI for it 
has a freeform field for extra options.  (It's hidden under a couple of 
"advanced" and "dangerous" expanders).  You can see that the option has 
been applied & accepted by looking for `flowblind` in the output of `tc 
qdisc`, run on the router using `ssh`.

> And the 5ms+ jump you're talking about, that would compare to an ideal 3ms
> jump not using flowblind. Is that right?

I think flowblind would add 5ms+, on top of the 3ms you measured without 
it, i.e. 8ms+ increase.

> We do use the connection for gaming and so it might be useful. Without
> flowblind, are you saying that latency in games would be worse with just
> standard cake?

*with* flowblind, latency in games would be slightly worse.  When 
someone else is uploading/downloading files at the same time.  Or 
potentially when a computer is doing both in the background, because it 
gets software updates over P2P.

>
> Thanks so much for your help so far.
>
> On 26 August 2016 at 12:52, Alan Jenkins <alan.christopher.jenkins@gmail.com
>> wrote:
>> On 26/08/16 12:29, moeller0 wrote:
>>
>> Hi techicist,
>>
>>
>> On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote:
>>
>> Is flowblind likely to give better performance?
>>
>> 	That depends on your definition of better, I guess. Typically flow-fair queuing seems to be what most people prefer (unless an application either does not respond to AQM signals or open an excessive amount of individual flows flow-fair queueing effectively treats most traffic sources equal, pretty much what people seem to want, add to this a bit of classification to exempt e.g. VOIP traffic from only getting its flow-fair share of the bandwidth and the whole thing also works reasonably well with slow links). People suffering from unruly applications (like mis-configured? bit-torrent clients or recently windows update) often ask for per-application fairness, but that is not something a router will ever be able to deliver in my opinion; the closest we get to this would be fairnes by internal or external end-IP addresses. Luckily cake offers just these modes “dsthost”, “srchost” and even better offers a combination modes that will on a first level attempt per host-IP fairness and within each host IP also per-flow fairness (“dual-srchost” and “dual-dsthost”, and even “triple-isolate” which systematically might be better called “dual-srchost-dsthost” since it offers fist level fairness based on an under-documented mix of src and dst addresses, but I digress). Please note that on a typical homerouter, due to NAT, all the IP addressed based fairness modes will not work for IPv4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically degrades into a computationally more intensive version of flow-fairness (as after NAT cake only sees the routers external IP for all internal hosts). This might have been more than you wanted to know…
>>
>> Best Regards
>> 	Sebastian
>>
>>
>> flowblind is an option for testing purposes or advanced use cases.  The
>> design goal for Cake is to avoid understanding and fiddling with options to
>> get good performance for common cases.
>>
>> If you try enabling flowblind, your latency under load will jump by 5ms+.
>> "Head of line blocking".  A full queue will be 5ms.  This will delay flows
>> which do not need a full fair share of the link, like VOIP or gaming.
>> Lower latency is  better for VOIP or gaming.
>>
>> You should find this is small compared to the latency increase under load
>> without cake.  You wouldn't notice it in web browsing.  (Frankly I don't
>> seem to notice 100ms extra latency in web browsing.
>>
>> I run fq_codel for similar performance to cake, mainly to increase my
>> confidence that torrent uploads don't have noticable effects for other
>> household users.  Torrent downloads still suck, but I haven't seen any Cake
>> results promoted on that basis.  It either needs to be fixed at the ISP
>> end, or in the torrent software.  QUIC are emulating the competitiveness of
>> 2x TCP flows in a single UDP flow.  BT should be able to emulate half a TCP
>> flow when downloading from two peers simultaneously).
>>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 26/08/16 12:32, techicist@gmail.com wrote:
> So best to just leave well alone I think :)
>
> I do have one question. I sometimes use the thinkbroadband.com Ping Monitor
> and it shows my ping as being 40-50ms a lot of the time, even with cake.
> What's going on here?

Meaning sometimes it's lower, I assume.  Can you send a link?  I forget 
if it reveals the IP, you can send just to me if that's less risky.

They give you the Ping Monitor IP address in the FAQ (so you can allow 
it).  It means you can try ping (or traceroute) to it yourself if you 
want to play with it.

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Here you go:
http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins]

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

On 27/08/16 17:17, techicist@gmail.com wrote:
> Here you go:
> http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html

ok.

- Average latency is perfectly fine (for the points you mentioned)

- Reading the docs for this tool ("How do I interpret my BQM graph?"), 
they suggest that spikes which show in yellow (the maximum, taken from 
100 pings) but don't show in blue (average) "do not affect gaming".  
"The connection is good".  (Also, your yellow spikes are shorter than 
some of the ones they show).

http://www.thinkbroadband.com/faq/sections/bqm.html#313

I think they mean that 1% "late" packets will effectively be treated as 
lost packets for latency-sensitive apps, and such apps should be 
designed to handle low-level loss.  Our Dave might call this a bit of a 
cop out though.

- They're only to do with your bufferbloat / AQM, if they happen while 
the connection is used.  If your connection is idle, you don't have any 
queue you could manage to decrease the queuing latency :).

That said, the BQM docs suggest that if there was congestion at a larger 
shared link within your ISP, you would generally see an increase in the 
minimum latency (green).  Because when the problem is caused by a large 
number users, the load will be averaged out and be much more consistent.

-> They could be transient bufferbloat.

Cake isn't running at the ISP end.  If your connection was maliciously 
flooded >100% capacity, then a dumb ISP queue could fill, and delay the 
lucky packets that got through.  Despite the cake on your end.

Flooding the connection >100% is not that different to what a TCP 
connection does while starting up, in order to find what the current 
link capacity actually is.  Browsing to a new web page typically 
involves starting a surprisingly large number of TCP connections.

I run smokeping on a slower connection with fq_codel.  I don't think my 
spikes are as high - I'd say +5-10ms to your +30-40.  However my ISP's 
(download) queue management is relatively good (against web browsing).

  -> I don't think you've posted "bufferbloat" measurements for your ISP 
download queue, i.e. _without_ using rate-limiting on your router.

That's my first cut.

You could compare cake to traditional fq_codel (I think you might have 
to disable TCP offloads, in case you're effectively relying on Cake's 
peeling feature).  I believe fq_codel is well characterized, whereas 
cake is more experimental.  I don't expect that's the issue though.

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

I'm back again, been quite busy so lost track of this. I'm using LEDE now
too.

Is there an easy way to see cake is actually working? A command or
something I can type in just to get clarification?

Also, I've set the overhead to 12 as recommended before, due to the VLAN BT
Openreach use in the UK, which I believe OpenWRT cannot account for. Whilst
in this section of the LuCi GUI, I noticed "Which linklayer adaptation
mechanism to use; for testing only", has a "cake" option? Should this be
enabled?

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Kevin Darbyshire-Bryant]

On 14/09/16 21:06, techicist@gmail.com wrote:
> I'm back again, been quite busy so lost track of this. I'm using LEDE
> now too.
>
> Is there an easy way to see cake is actually working? A command or
> something I can type in just to get clarification?

You can prove that cake is being used as the queue discipline (qdisc) by 
doing something like 'tc qdisc'

On my LEDE box it returns:

qdisc noqueue 0: dev lo root refcnt 2
qdisc cake 800d: dev eth0 root refcnt 2 bandwidth 9840Kbit diffserv4 
dual-srchost rtt 100.0ms noatm overhead 12
qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
qdisc fq_codel 0: dev eth1 root refcnt 2 limit 10240p flows 1024 quantum 
1514 target 5.0ms interval 100.0ms ecn
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc mq 0: dev wlan0 root
qdisc fq_codel 0: dev wlan0 parent :1 limit 10240p flows 1024 quantum 
1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :2 limit 10240p flows 1024 quantum 
1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :3 limit 10240p flows 1024 quantum 
1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :4 limit 10240p flows 1024 quantum 
1514 target 5.0ms interval 100.0ms ecn
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc cake 800e: dev ifb4eth0 root refcnt 2 bandwidth 39300Kbit 
diffserv4 dual-dsthost rtt 100.0ms noatm overhead 12

eth0 is my WAN facing interface, which is why it's the only interface 
with 'cake' as the qdisc.  You'll also note the overhead parameter.

'tc -s qdisc' will show some more interesting stats for all the qdiscs. 
Narrowing to a particular interface is often more helpful e.g. 'tc -s 
qdisc show dev ifb4eth0' would show those same stats for the 'incoming' 
side of my wan interface.

The outgoing interface is probably where most of the cake action is 
taking place.  Look at 'drops & marks' for cases where cake has 
signalled flows to back off.  Also the more dynamic stats of sparse 
(sp), bulk (bk) and unresponsive (un) flows give a snapshot of how many 
flows cake is dealing with right now.

>
> Also, I've set the overhead to 12 as recommended before, due to the VLAN
> BT Openreach use in the UK, which I believe OpenWRT cannot account for.
> Whilst in this section of the LuCi GUI, I noticed "Which linklayer
> adaptation mechanism to use; for testing only", has a "cake" option?
> Should this be enabled?

Yes it should be enabled.


Kevin

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Sebastian Moeller]

On September 14, 2016 10:41:22 PM GMT+02:00, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
>
>On 14/09/16 21:06, techicist@gmail.com wrote:
>> I'm back again, been quite busy so lost track of this. I'm using LEDE
>> now too.
>>
>> Is there an easy way to see cake is actually working? A command or
>> something I can type in just to get clarification?
>
>You can prove that cake is being used as the queue discipline (qdisc)
>by 
>doing something like 'tc qdisc'
>
>On my LEDE box it returns:
>
>qdisc noqueue 0: dev lo root refcnt 2
>qdisc cake 800d: dev eth0 root refcnt 2 bandwidth 9840Kbit diffserv4 
>dual-srchost rtt 100.0ms noatm overhead 12
>qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
>qdisc fq_codel 0: dev eth1 root refcnt 2 limit 10240p flows 1024
>quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc noqueue 0: dev br-lan root refcnt 2
>qdisc mq 0: dev wlan0 root
>qdisc fq_codel 0: dev wlan0 parent :1 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :2 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :3 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :4 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc noqueue 0: dev wlan1 root refcnt 2
>qdisc cake 800e: dev ifb4eth0 root refcnt 2 bandwidth 39300Kbit 
>diffserv4 dual-dsthost rtt 100.0ms noatm overhead 12
>
>eth0 is my WAN facing interface, which is why it's the only interface 
>with 'cake' as the qdisc.  You'll also note the overhead parameter.
>
>'tc -s qdisc' will show some more interesting stats for all the qdiscs.
>
>Narrowing to a particular interface is often more helpful e.g. 'tc -s 
>qdisc show dev ifb4eth0' would show those same stats for the 'incoming'
>
>side of my wan interface.
>
>The outgoing interface is probably where most of the cake action is 
>taking place.  Look at 'drops & marks' for cases where cake has 
>signalled flows to back off.  Also the more dynamic stats of sparse 
>(sp), bulk (bk) and unresponsive (un) flows give a snapshot of how many
>
>flows cake is dealing with right now.
>
>>
>> Also, I've set the overhead to 12 as recommended before, due to the
>VLAN
>> BT Openreach use in the UK, which I believe OpenWRT cannot account
>for.
>> Whilst in this section of the LuCi GUI, I noticed "Which linklayer
>> adaptation mechanism to use; for testing only", has a "cake" option?
>> Should this be enabled?
>
>Yes it should be enabled.

This really depends... Tc's stab (size table) method really is not so bad as long as you do not need to account for ATM cells; cake' s in build overhead accounting is not necessarily better for non-atm links. That said it is still on my to-do list to switch sqm-scripts to use cake' native method as the default if cake is used. But since the default to stab seems to work just as well and is rather universal (and cake' s whole overhead handling is massively under-documented) I never really got around to implement this...

Best Regards
        Sebastian


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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Cake] Configuring cake for VDSL2 bridged connection

[Kevin Darbyshire-Bryant]

On 14/09/16 21:48, Sebastian Moeller wrote:
>
>

>>> Whilst in this section of the LuCi GUI, I noticed "Which linklayer
>>> adaptation mechanism to use; for testing only", has a "cake" option?
>>> Should this be enabled?
>>
>> Yes it should be enabled.
>
> This really depends... Tc's stab (size table) method really is not so bad as long as you do not need to account for ATM cells; cake' s in build overhead accounting is not necessarily better for non-atm links. That said it is still on my to-do list to switch sqm-scripts to use cake' native method as the default if cake is used. But since the default to stab seems to work just as well and is rather universal (and cake' s whole overhead handling is massively under-documented) I never really got around to implement this...

I prefer to keep all the manipulation in one module....I'd like to think 
it more cpu and cache efficient. Whether cake's add/mul/div calculation 
in the case of atm framing as faster than stab's memory table & 
potential cache miss is one for the clever people.

>
> Best Regards
>         Sebastian

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

Re: [Cake] Configuring cake for VDSL2 bridged connection

[techicist]

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

Thanks for all your replies again. They are most helpful.
>
>
In "Show Advanced Linklayer Options", there are other options too. Are
these best left alone? From the top, the numbers there are: 2047, 128, 0.

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