[Cake] fq_codel on 3g network in Mauritius

[Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

Hi guys,

I've been playing with fq_codel on 3g internet connection. the 3g
internet box has no bridge mode, and just forwards every packet to the
Openwrt router.

Here are the results without:
http://www.dslreports.com/speedtest/4470186

And here is the result with fq_codel on and 300 ms target latency:

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

Is there anything that could be done to get the rating up to A+ by
tweaking the code ?



Kind regards,

Re: [Cake] fq_codel on 3g network in Mauritius

[Jonathan Morton]

> On 19 Jul, 2016, at 07:29, Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> I've been playing with fq_codel on 3g internet connection. the 3g
> internet box has no bridge mode, and just forwards every packet to the
> Openwrt router.
> 
> Here are the results without:
> http://www.dslreports.com/speedtest/4470186
> 
> And here is the result with fq_codel on and 300 ms target latency:
> 
> http://www.dslreports.com/speedtest/4470286
> 
> Is there anything that could be done to get the rating up to A+ by
> tweaking the code ?

You say fq_codel, rather than Cake.  Presumably it is paired with some sort of shaper, such as HTB?  This is important, because I think the shaper is influencing part of your results.

On downstream, you have one high latency sample (750ms) in the middle of a series of reasonable ones (250ms).  This implies a momentary glitch in your connection, which isn’t unusual with wireless links.  Re-measuring might eliminate it.

On upstream, you have two very high latency samples at the *beginning* of the run, which then clear out to approximately the baseline latency.  This is a classic sign that your shaper is letting a burst of traffic through before actually starting to control it, which is typical behaviour for token-bucket shapers.  That initial burst collects in the dumb queue of your 3G modem and takes time to drain away.

Cake uses a shaper carefully designed to *not* burst in that manner, while still maintaining full throughput regardless of timer resolution and latency.  Using Cake instead of fq_codel+HTB will therefore probably improve your upload characteristics.

 - Jonathan Morton

Re: [Cake] fq_codel on 3g network in Mauritius

[moeller0]

Hi Loganaden,

> On Jul 19, 2016, at 10:09 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 19 Jul, 2016, at 07:29, Loganaden Velvindron <loganaden@gmail.com> wrote:
>> 
>> I've been playing with fq_codel on 3g internet connection. the 3g
>> internet box has no bridge mode, and just forwards every packet to the
>> Openwrt router.
>> 
>> Here are the results without:
>> http://www.dslreports.com/speedtest/4470186
>> 
>> And here is the result with fq_codel on and 300 ms target latency:
>> 
>> http://www.dslreports.com/speedtest/4470286
>> 
>> Is there anything that could be done to get the rating up to A+ by
>> tweaking the code ?
> 
> You say fq_codel, rather than Cake.  Presumably it is paired with some sort of shaper, such as HTB?  This is important, because I think the shaper is influencing part of your results.
> 
> On downstream, you have one high latency sample (750ms) in the middle of a series of reasonable ones (250ms).  This implies a momentary glitch in your connection, which isn’t unusual with wireless links.  Re-measuring might eliminate it.
> 
> On upstream, you have two very high latency samples at the *beginning* of the run, which then clear out to approximately the baseline latency.  This is a classic sign that your shaper is letting a burst of traffic through before actually starting to control it, which is typical behaviour for token-bucket shapers.  That initial burst collects in the dumb queue of your 3G modem and takes time to drain away.
> 
> Cake uses a shaper carefully designed to *not* burst in that manner, while still maintaining full throughput regardless of timer resolution and latency.  Using Cake instead of fq_codel+HTB will therefore probably improve your upload characteristics.

	I believe that the way sqm-scripts simple.qos and simplest.qos use the HTB shaper are not subject to this specific issue (we do not configure/allow HTB to burst at all). Looking at a number of my speed tests seems to support this observation (https://www.dslreports.com/speedtest/636817 simplest.qos, HTB+fq_codel no initial bursting).

Best Regards
        Sebastian

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

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

On Tue, Jul 19, 2016 at 12:09 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 19 Jul, 2016, at 07:29, Loganaden Velvindron <loganaden@gmail.com> wrote:
>>
>> I've been playing with fq_codel on 3g internet connection. the 3g
>> internet box has no bridge mode, and just forwards every packet to the
>> Openwrt router.
>>
>> Here are the results without:
>> http://www.dslreports.com/speedtest/4470186
>>
>> And here is the result with fq_codel on and 300 ms target latency:
>>
>> http://www.dslreports.com/speedtest/4470286
>>
>> Is there anything that could be done to get the rating up to A+ by
>> tweaking the code ?
>
> You say fq_codel, rather than Cake.  Presumably it is paired with some sort of shaper, such as HTB?  This is important, because I think the shaper is influencing part of your results.
>
> On downstream, you have one high latency sample (750ms) in the middle of a series of reasonable ones (250ms).  This implies a momentary glitch in your connection, which isn’t unusual with wireless links.  Re-measuring might eliminate it.
>
> On upstream, you have two very high latency samples at the *beginning* of the run, which then clear out to approximately the baseline latency.  This is a classic sign that your shaper is letting a burst of traffic through before actually starting to control it, which is typical behaviour for token-bucket shapers.  That initial burst collects in the dumb queue of your 3G modem and takes time to drain away.
>
> Cake uses a shaper carefully designed to *not* burst in that manner, while still maintaining full throughput regardless of timer resolution and latency.  Using Cake instead of fq_codel+HTB will therefore probably improve your upload characteristics.
>

here's the output from tc:

qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
quantum 300 target 5.0ms interval 100.0ms ecn
qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
direct_packets_stat 0 direct_qlen 1000
qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
quantum 300 target 300.0ms interval 100.0ms
qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
quantum 300 target 300.0ms interval 100.0ms
qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
quantum 300 target 300.0ms interval 100.0ms
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
qdisc mq 0: dev wlan0 root
qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
direct_packets_stat 0 direct_qlen 32
qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
quantum 300 target 300.0ms interval 100.0ms ecn

I will give CAKE a try. However, I'm not sure if there's enough space
(4mb NAND flash) on the tp-link wr841nd for sqm-qos. I will need to
get another box like the tp-link archer c7.

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

>         It seems the initial burst like behavior from the earlier test was a false positive; these test are still not beautiful, but at least they do not indicate that HTB+fq_codel as configured on your system do not suffer from uncontrolled bursty-ness. Unfortunately, I have no real insight or advice to offer how to improve your situation (short f setting the shaper rates considerably lower).
>         BTW, “tc -d qdisc” and “tc -s disc” give a bit more information, and “tc class show dev eth1” and “tc class show dev ifb4eth1” will also offer more detail about your setup.
>
>
> Best Regards
>         Sebastian
>
>
>

tc -d qdisc:

qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
quantum 300 target 5.0ms interval 100.0ms ecn
qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
direct_packets_stat 5 ver 3.17 direct_qlen 1000
qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
qdisc mq 0: dev wlan0 root
qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
direct_packets_stat 0 ver 3.17 direct_qlen 32
qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms ecn

tc -s qdisc:

qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
quantum 300 target 5.0ms interval 100.0ms ecn
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
direct_packets_stat 5 direct_qlen 1000
 Sent 23456195 bytes 109776 pkt (dropped 0, overlimits 86210 requeues 0)
 backlog 0b 4p requeues 0
qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
 Sent 14760 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 163 ecn_mark 0
  new_flows_len 1 old_flows_len 0
qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
 Sent 23440300 bytes 109600 pkt (dropped 115, overlimits 0 requeues 0)
 backlog 5816b 4p requeues 0
  maxpacket 1454 drop_overlimit 0 new_flow_count 15749 ecn_mark 0
  new_flows_len 0 old_flows_len 1
qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
 Sent 190858989 bytes 149884 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc mq 0: dev wlan0 root
 Sent 194287835 bytes 153002 pkt (dropped 0, overlimits 0 requeues 7)
 backlog 0b 0p requeues 7
qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
direct_packets_stat 0 direct_qlen 32
 Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 41505 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
quantum 300 target 500.0ms interval 100.0ms ecn
 Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1454 drop_overlimit 0 new_flow_count 16778 ecn_mark 0
  new_flows_len 1 old_flows_len 2


tc class show dev eth1
class htb 1:11 parent 1:1 leaf 110: prio 1 rate 128Kbit ceil 100Kbit
burst 1600b cburst 1600b
class htb 1:1 root rate 300Kbit ceil 300Kbit burst 1599b cburst 1599b
class htb 1:10 parent 1:1 prio 0 rate 300Kbit ceil 300Kbit burst 1599b
cburst 1599b
class htb 1:13 parent 1:1 leaf 130: prio 3 rate 50Kbit ceil 284Kbit
burst 1600b cburst 1599b
class htb 1:12 parent 1:1 leaf 120: prio 2 rate 50Kbit ceil 284Kbit
burst 1600b cburst 1599b
class fq_codel 110:188 parent 110:
class fq_codel 120:3d6 parent 120:


tc class show dev ifb4eth1:
class htb 1:10 parent 1:1 leaf 110: prio 0 rate 19600Kbit ceil
19600Kbit burst 1597b cburst 1597b
class htb 1:1 root rate 19600Kbit ceil 19600Kbit burst 1597b cburst 1597b
class fq_codel 110:2f1 parent 110:
class fq_codel 110:330 parent 110:

I changed the target from 350ms to 500ms for both ingress and egree,
and the throughput seem to be better:

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

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

After going through:

https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06

I think that I should remove the itarget and etarget, and set the
Interval rather to 500ms.



   The _interval_ parameter has the same semantics as CoDel and is used
   to ensure that the minimum sojourn time of packets in a queue used as
   an estimator by the CoDel control algorithm is a relatively up-to-
   date value.  That is, CoDel only reacts to delay experienced in the
   last epoch of length interval.  It SHOULD be set to be on the order
   of the worst-case RTT through the bottleneck to give end-points
   sufficient time to react.

   The default interval value is 100 ms.

The default interval value is not suited for my 3g connection where
the worse-case RTT is much higher.



On Sat, Jul 23, 2016 at 10:36 PM, Loganaden Velvindron
<loganaden@gmail.com> wrote:
>>         It seems the initial burst like behavior from the earlier test was a false positive; these test are still not beautiful, but at least they do not indicate that HTB+fq_codel as configured on your system do not suffer from uncontrolled bursty-ness. Unfortunately, I have no real insight or advice to offer how to improve your situation (short f setting the shaper rates considerably lower).
>>         BTW, “tc -d qdisc” and “tc -s disc” give a bit more information, and “tc class show dev eth1” and “tc class show dev ifb4eth1” will also offer more detail about your setup.
>>
>>
>> Best Regards
>>         Sebastian
>>
>>
>>
>
> tc -d qdisc:
>
> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
> quantum 300 target 5.0ms interval 100.0ms ecn
> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
> direct_packets_stat 5 ver 3.17 direct_qlen 1000
> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
> qdisc mq 0: dev wlan0 root
> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
> direct_packets_stat 0 ver 3.17 direct_qlen 32
> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms ecn
>
> tc -s qdisc:
>
> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
> quantum 300 target 5.0ms interval 100.0ms ecn
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
> direct_packets_stat 5 direct_qlen 1000
>  Sent 23456195 bytes 109776 pkt (dropped 0, overlimits 86210 requeues 0)
>  backlog 0b 4p requeues 0
> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
>  Sent 14760 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 256 drop_overlimit 0 new_flow_count 163 ecn_mark 0
>   new_flows_len 1 old_flows_len 0
> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
>  Sent 23440300 bytes 109600 pkt (dropped 115, overlimits 0 requeues 0)
>  backlog 5816b 4p requeues 0
>   maxpacket 1454 drop_overlimit 0 new_flow_count 15749 ecn_mark 0
>   new_flows_len 0 old_flows_len 1
> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>  Sent 190858989 bytes 149884 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc mq 0: dev wlan0 root
>  Sent 194287835 bytes 153002 pkt (dropped 0, overlimits 0 requeues 7)
>  backlog 0b 0p requeues 7
> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
> direct_packets_stat 0 direct_qlen 32
>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 41505 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
> quantum 300 target 500.0ms interval 100.0ms ecn
>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 1454 drop_overlimit 0 new_flow_count 16778 ecn_mark 0
>   new_flows_len 1 old_flows_len 2
>
>
> tc class show dev eth1
> class htb 1:11 parent 1:1 leaf 110: prio 1 rate 128Kbit ceil 100Kbit
> burst 1600b cburst 1600b
> class htb 1:1 root rate 300Kbit ceil 300Kbit burst 1599b cburst 1599b
> class htb 1:10 parent 1:1 prio 0 rate 300Kbit ceil 300Kbit burst 1599b
> cburst 1599b
> class htb 1:13 parent 1:1 leaf 130: prio 3 rate 50Kbit ceil 284Kbit
> burst 1600b cburst 1599b
> class htb 1:12 parent 1:1 leaf 120: prio 2 rate 50Kbit ceil 284Kbit
> burst 1600b cburst 1599b
> class fq_codel 110:188 parent 110:
> class fq_codel 120:3d6 parent 120:
>
>
> tc class show dev ifb4eth1:
> class htb 1:10 parent 1:1 leaf 110: prio 0 rate 19600Kbit ceil
> 19600Kbit burst 1597b cburst 1597b
> class htb 1:1 root rate 19600Kbit ceil 19600Kbit burst 1597b cburst 1597b
> class fq_codel 110:2f1 parent 110:
> class fq_codel 110:330 parent 110:
>
> I changed the target from 350ms to 500ms for both ingress and egree,
> and the throughput seem to be better:
>
> http://www.dslreports.com/speedtest/4515961

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

I've set the interval to 350ms, by using advanced option:

Result is better:

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


I will submit a patch for sqm-luci so that the interval is
configurable easily via web ui for African countries where the latency
tends to be of the order of 300ms to 600ms, particularly on 3g
connections.


tc -s qdisc
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
quantum 300 target 5.0ms interval 100.0ms ecn
 Sent 3493746 bytes 5455 pkt (dropped 0, overlimits 0 requeues 2)
 backlog 0b 0p requeues 2
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
direct_packets_stat 3 direct_qlen 1000
 Sent 4869533 bytes 18710 pkt (dropped 0, overlimits 8200 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
quantum 300 target 41.1ms interval 350.0ms
 Sent 12742 bytes 115 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 84 ecn_mark 0
  new_flows_len 0 old_flows_len 1
qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
quantum 300 target 41.1ms interval 350.0ms
 Sent 4854326 bytes 18569 pkt (dropped 85, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1454 drop_overlimit 0 new_flow_count 4831 ecn_mark 0
  new_flows_len 1 old_flows_len 1
qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
quantum 300 target 41.1ms interval 350.0ms
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
 Sent 21938964 bytes 23336 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc mq 0: dev wlan0 root
 Sent 18874833 bytes 18494 pkt (dropped 0, overlimits 0 requeues 2)
 backlog 0b 0p requeues 2
qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
direct_packets_stat 0 direct_qlen 32
 Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 5193 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
quantum 300 target 5.0ms interval 350.0ms ecn
 Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1454 drop_overlimit 0 new_flow_count 4392 ecn_mark 0
  new_flows_len 1 old_flows_len 1

On Sat, Jul 23, 2016 at 10:59 PM, Loganaden Velvindron
<loganaden@gmail.com> wrote:
> After going through:
>
> https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06
>
> I think that I should remove the itarget and etarget, and set the
> Interval rather to 500ms.
>
>
>
>    The _interval_ parameter has the same semantics as CoDel and is used
>    to ensure that the minimum sojourn time of packets in a queue used as
>    an estimator by the CoDel control algorithm is a relatively up-to-
>    date value.  That is, CoDel only reacts to delay experienced in the
>    last epoch of length interval.  It SHOULD be set to be on the order
>    of the worst-case RTT through the bottleneck to give end-points
>    sufficient time to react.
>
>    The default interval value is 100 ms.
>
> The default interval value is not suited for my 3g connection where
> the worse-case RTT is much higher.
>
>
>
> On Sat, Jul 23, 2016 at 10:36 PM, Loganaden Velvindron
> <loganaden@gmail.com> wrote:
>>>         It seems the initial burst like behavior from the earlier test was a false positive; these test are still not beautiful, but at least they do not indicate that HTB+fq_codel as configured on your system do not suffer from uncontrolled bursty-ness. Unfortunately, I have no real insight or advice to offer how to improve your situation (short f setting the shaper rates considerably lower).
>>>         BTW, “tc -d qdisc” and “tc -s disc” give a bit more information, and “tc class show dev eth1” and “tc class show dev ifb4eth1” will also offer more detail about your setup.
>>>
>>>
>>> Best Regards
>>>         Sebastian
>>>
>>>
>>>
>>
>> tc -d qdisc:
>>
>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>> direct_packets_stat 5 ver 3.17 direct_qlen 1000
>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>> qdisc mq 0: dev wlan0 root
>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>> direct_packets_stat 0 ver 3.17 direct_qlen 32
>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms ecn
>>
>> tc -s qdisc:
>>
>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>   new_flows_len 0 old_flows_len 0
>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>> direct_packets_stat 5 direct_qlen 1000
>>  Sent 23456195 bytes 109776 pkt (dropped 0, overlimits 86210 requeues 0)
>>  backlog 0b 4p requeues 0
>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>>  Sent 14760 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>>   maxpacket 256 drop_overlimit 0 new_flow_count 163 ecn_mark 0
>>   new_flows_len 1 old_flows_len 0
>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>>  Sent 23440300 bytes 109600 pkt (dropped 115, overlimits 0 requeues 0)
>>  backlog 5816b 4p requeues 0
>>   maxpacket 1454 drop_overlimit 0 new_flow_count 15749 ecn_mark 0
>>   new_flows_len 0 old_flows_len 1
>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms
>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>   new_flows_len 0 old_flows_len 0
>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>>  Sent 190858989 bytes 149884 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>> qdisc mq 0: dev wlan0 root
>>  Sent 194287835 bytes 153002 pkt (dropped 0, overlimits 0 requeues 7)
>>  backlog 0b 0p requeues 7
>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>> direct_packets_stat 0 direct_qlen 32
>>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 41505 requeues 0)
>>  backlog 0b 0p requeues 0
>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>> quantum 300 target 500.0ms interval 100.0ms ecn
>>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>>   maxpacket 1454 drop_overlimit 0 new_flow_count 16778 ecn_mark 0
>>   new_flows_len 1 old_flows_len 2
>>
>>
>> tc class show dev eth1
>> class htb 1:11 parent 1:1 leaf 110: prio 1 rate 128Kbit ceil 100Kbit
>> burst 1600b cburst 1600b
>> class htb 1:1 root rate 300Kbit ceil 300Kbit burst 1599b cburst 1599b
>> class htb 1:10 parent 1:1 prio 0 rate 300Kbit ceil 300Kbit burst 1599b
>> cburst 1599b
>> class htb 1:13 parent 1:1 leaf 130: prio 3 rate 50Kbit ceil 284Kbit
>> burst 1600b cburst 1599b
>> class htb 1:12 parent 1:1 leaf 120: prio 2 rate 50Kbit ceil 284Kbit
>> burst 1600b cburst 1599b
>> class fq_codel 110:188 parent 110:
>> class fq_codel 120:3d6 parent 120:
>>
>>
>> tc class show dev ifb4eth1:
>> class htb 1:10 parent 1:1 leaf 110: prio 0 rate 19600Kbit ceil
>> 19600Kbit burst 1597b cburst 1597b
>> class htb 1:1 root rate 19600Kbit ceil 19600Kbit burst 1597b cburst 1597b
>> class fq_codel 110:2f1 parent 110:
>> class fq_codel 110:330 parent 110:
>>
>> I changed the target from 350ms to 500ms for both ingress and egree,
>> and the throughput seem to be better:
>>
>> http://www.dslreports.com/speedtest/4515961

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

Hi Sebastian,

Since dslreports disable the ping due to high latency:

I did a ping test during the test:

--- youtube-ui.l.google.com ping statistics ---
61 packets transmitted, 61 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 336.631/369.733/493.473/30.946 ms

It looks to me that configuring the interval to be high for fq_codel
(350ms) does improve the latency under load.







On Sun, Jul 24, 2016 at 9:53 AM, Loganaden Velvindron
<loganaden@gmail.com> wrote:
> I've set the interval to 350ms, by using advanced option:
>
> Result is better:
>
> http://www.dslreports.com/speedtest/4520697
>
>
> I will submit a patch for sqm-luci so that the interval is
> configurable easily via web ui for African countries where the latency
> tends to be of the order of 300ms to 600ms, particularly on 3g
> connections.
>
>
> tc -s qdisc
> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
> quantum 300 target 5.0ms interval 100.0ms ecn
>  Sent 3493746 bytes 5455 pkt (dropped 0, overlimits 0 requeues 2)
>  backlog 0b 0p requeues 2
>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
> direct_packets_stat 3 direct_qlen 1000
>  Sent 4869533 bytes 18710 pkt (dropped 0, overlimits 8200 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
>  Sent 12742 bytes 115 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 256 drop_overlimit 0 new_flow_count 84 ecn_mark 0
>   new_flows_len 0 old_flows_len 1
> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
>  Sent 4854326 bytes 18569 pkt (dropped 85, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 1454 drop_overlimit 0 new_flow_count 4831 ecn_mark 0
>   new_flows_len 1 old_flows_len 1
> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>  Sent 21938964 bytes 23336 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc mq 0: dev wlan0 root
>  Sent 18874833 bytes 18494 pkt (dropped 0, overlimits 0 requeues 2)
>  backlog 0b 0p requeues 2
> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
> direct_packets_stat 0 direct_qlen 32
>  Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 5193 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
> quantum 300 target 5.0ms interval 350.0ms ecn
>  Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 1454 drop_overlimit 0 new_flow_count 4392 ecn_mark 0
>   new_flows_len 1 old_flows_len 1
>
> On Sat, Jul 23, 2016 at 10:59 PM, Loganaden Velvindron
> <loganaden@gmail.com> wrote:
>> After going through:
>>
>> https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06
>>
>> I think that I should remove the itarget and etarget, and set the
>> Interval rather to 500ms.
>>
>>
>>
>>    The _interval_ parameter has the same semantics as CoDel and is used
>>    to ensure that the minimum sojourn time of packets in a queue used as
>>    an estimator by the CoDel control algorithm is a relatively up-to-
>>    date value.  That is, CoDel only reacts to delay experienced in the
>>    last epoch of length interval.  It SHOULD be set to be on the order
>>    of the worst-case RTT through the bottleneck to give end-points
>>    sufficient time to react.
>>
>>    The default interval value is 100 ms.
>>
>> The default interval value is not suited for my 3g connection where
>> the worse-case RTT is much higher.
>>
>>
>>
>> On Sat, Jul 23, 2016 at 10:36 PM, Loganaden Velvindron
>> <loganaden@gmail.com> wrote:
>>>>         It seems the initial burst like behavior from the earlier test was a false positive; these test are still not beautiful, but at least they do not indicate that HTB+fq_codel as configured on your system do not suffer from uncontrolled bursty-ness. Unfortunately, I have no real insight or advice to offer how to improve your situation (short f setting the shaper rates considerably lower).
>>>>         BTW, “tc -d qdisc” and “tc -s disc” give a bit more information, and “tc class show dev eth1” and “tc class show dev ifb4eth1” will also offer more detail about your setup.
>>>>
>>>>
>>>> Best Regards
>>>>         Sebastian
>>>>
>>>>
>>>>
>>>
>>> tc -d qdisc:
>>>
>>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> quantum 300 target 5.0ms interval 100.0ms ecn
>>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>>> direct_packets_stat 5 ver 3.17 direct_qlen 1000
>>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>>> qdisc mq 0: dev wlan0 root
>>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>>> direct_packets_stat 0 ver 3.17 direct_qlen 32
>>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms ecn
>>>
>>> tc -s qdisc:
>>>
>>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> quantum 300 target 5.0ms interval 100.0ms ecn
>>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>>  backlog 0b 0p requeues 0
>>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>>   new_flows_len 0 old_flows_len 0
>>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>>> direct_packets_stat 5 direct_qlen 1000
>>>  Sent 23456195 bytes 109776 pkt (dropped 0, overlimits 86210 requeues 0)
>>>  backlog 0b 4p requeues 0
>>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>>  Sent 14760 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
>>>  backlog 0b 0p requeues 0
>>>   maxpacket 256 drop_overlimit 0 new_flow_count 163 ecn_mark 0
>>>   new_flows_len 1 old_flows_len 0
>>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>>  Sent 23440300 bytes 109600 pkt (dropped 115, overlimits 0 requeues 0)
>>>  backlog 5816b 4p requeues 0
>>>   maxpacket 1454 drop_overlimit 0 new_flow_count 15749 ecn_mark 0
>>>   new_flows_len 0 old_flows_len 1
>>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>>  backlog 0b 0p requeues 0
>>>   maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>>   new_flows_len 0 old_flows_len 0
>>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>>>  Sent 190858989 bytes 149884 pkt (dropped 0, overlimits 0 requeues 0)
>>>  backlog 0b 0p requeues 0
>>> qdisc mq 0: dev wlan0 root
>>>  Sent 194287835 bytes 153002 pkt (dropped 0, overlimits 0 requeues 7)
>>>  backlog 0b 0p requeues 7
>>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>>> direct_packets_stat 0 direct_qlen 32
>>>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 41505 requeues 0)
>>>  backlog 0b 0p requeues 0
>>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms ecn
>>>  Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 0 requeues 0)
>>>  backlog 0b 0p requeues 0
>>>   maxpacket 1454 drop_overlimit 0 new_flow_count 16778 ecn_mark 0
>>>   new_flows_len 1 old_flows_len 2
>>>
>>>
>>> tc class show dev eth1
>>> class htb 1:11 parent 1:1 leaf 110: prio 1 rate 128Kbit ceil 100Kbit
>>> burst 1600b cburst 1600b
>>> class htb 1:1 root rate 300Kbit ceil 300Kbit burst 1599b cburst 1599b
>>> class htb 1:10 parent 1:1 prio 0 rate 300Kbit ceil 300Kbit burst 1599b
>>> cburst 1599b
>>> class htb 1:13 parent 1:1 leaf 130: prio 3 rate 50Kbit ceil 284Kbit
>>> burst 1600b cburst 1599b
>>> class htb 1:12 parent 1:1 leaf 120: prio 2 rate 50Kbit ceil 284Kbit
>>> burst 1600b cburst 1599b
>>> class fq_codel 110:188 parent 110:
>>> class fq_codel 120:3d6 parent 120:
>>>
>>>
>>> tc class show dev ifb4eth1:
>>> class htb 1:10 parent 1:1 leaf 110: prio 0 rate 19600Kbit ceil
>>> 19600Kbit burst 1597b cburst 1597b
>>> class htb 1:1 root rate 19600Kbit ceil 19600Kbit burst 1597b cburst 1597b
>>> class fq_codel 110:2f1 parent 110:
>>> class fq_codel 110:330 parent 110:
>>>
>>> I changed the target from 350ms to 500ms for both ingress and egree,
>>> and the throughput seem to be better:
>>>
>>> http://www.dslreports.com/speedtest/4515961

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

I am getting A to A+  for quality when setting the interval to 350ms.

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

I am getting - to C  for quality when setting the interval to the
default value of 100ms.

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

Re: [Cake] fq_codel on 3g network in Mauritius

[moeller0]

Hi Loganaden,

this is exactly the right idea; interval basically defines the “reaction time” window, or the time the endpoints of a connection minimally require to actually react to the drop/mark signal. So on a slow link with RTTs in the order of 300ms set interval to 300ms.
Target should be set to around 5-10% of interval to optimze the bandwidth latency tradeoff, but in any case target should be larger than the time required to send an individual packet, so that no queue builds up for sparse flows.
It is not quite clear to me whether in your case you would account the long “pipeline” depth to the target or simply bandwidth/1540…

Best Regards
        Sebastian

> On Jul 24, 2016, at 09:03 , Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> I am getting A to A+  for quality when setting the interval to 350ms.
> 
> http://www.dslreports.com/speedtest/4520977
> 
> I am getting - to C  for quality when setting the interval to the
> default value of 100ms.
> 
> http://www.dslreports.com/speedtest/4520957

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

On Sun, Jul 24, 2016 at 12:27 PM, moeller0 <moeller0@gmx.de> wrote:
> Hi Loganaden,
>
> this is exactly the right idea; interval basically defines the “reaction time” window, or the time the endpoints of a connection minimally require to actually react to the drop/mark signal. So on a slow link with RTTs in the order of 300ms set interval to 300ms.
> Target should be set to around 5-10% of interval to optimze the bandwidth latency tradeoff, but in any case target should be larger than the time required to send an individual packet, so that no queue builds up for sparse flows.
> It is not quite clear to me whether in your case you would account the long “pipeline” depth to the target or simply bandwidth/1540…
>
> Best Regards
>         Sebastian
>

Thank you !

I did the same with the OpenWRT router which is bridged with a fiber
connection (30Mbit/s down, 4 Mbit/s up), and I see improvement for
quality and bufferbloat:

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

I switched from 100ms interval to 270ms interval. Now, i'm getting A+ for both.

Re: [Cake] fq_codel on 3g network in Mauritius

[moeller0]

Hi Loganaden,


> On Jul 24, 2016, at 07:53 , Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> I've set the interval to 350ms, by using advanced option:
> 
> Result is better:
> 
> http://www.dslreports.com/speedtest/4520697
> 
> 
> I will submit a patch for sqm-luci so that the interval is
> configurable easily via web ui for African countries where the latency
> tends to be of the order of 300ms to 600ms, particularly on 3g
> connections.

	Good idea, I would propose to offer the choice from a drop down bow of the values that cake already uses (while not the biggest fan of cake’s names I believe consistency will be helpful) as well as the ability to add a numeric value. In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.

Best Regards
	Sebastian



> 
> 
> tc -s qdisc
> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
> quantum 300 target 5.0ms interval 100.0ms ecn
> Sent 3493746 bytes 5455 pkt (dropped 0, overlimits 0 requeues 2)
> backlog 0b 0p requeues 2
>  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>  new_flows_len 0 old_flows_len 0
> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
> direct_packets_stat 3 direct_qlen 1000
> Sent 4869533 bytes 18710 pkt (dropped 0, overlimits 8200 requeues 0)
> backlog 0b 0p requeues 0
> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
> Sent 12742 bytes 115 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>  maxpacket 256 drop_overlimit 0 new_flow_count 84 ecn_mark 0
>  new_flows_len 0 old_flows_len 1
> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
> Sent 4854326 bytes 18569 pkt (dropped 85, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>  maxpacket 1454 drop_overlimit 0 new_flow_count 4831 ecn_mark 0
>  new_flows_len 1 old_flows_len 1
> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
> quantum 300 target 41.1ms interval 350.0ms
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>  new_flows_len 0 old_flows_len 0
> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
> Sent 21938964 bytes 23336 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> qdisc mq 0: dev wlan0 root
> Sent 18874833 bytes 18494 pkt (dropped 0, overlimits 0 requeues 2)
> backlog 0b 0p requeues 2
> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
> direct_packets_stat 0 direct_qlen 32
> Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 5193 requeues 0)
> backlog 0b 0p requeues 0
> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
> quantum 300 target 5.0ms interval 350.0ms ecn
> Sent 22265602 bytes 23335 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>  maxpacket 1454 drop_overlimit 0 new_flow_count 4392 ecn_mark 0
>  new_flows_len 1 old_flows_len 1
> 
> On Sat, Jul 23, 2016 at 10:59 PM, Loganaden Velvindron
> <loganaden@gmail.com> wrote:
>> After going through:
>> 
>> https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06
>> 
>> I think that I should remove the itarget and etarget, and set the
>> Interval rather to 500ms.
>> 
>> 
>> 
>>   The _interval_ parameter has the same semantics as CoDel and is used
>>   to ensure that the minimum sojourn time of packets in a queue used as
>>   an estimator by the CoDel control algorithm is a relatively up-to-
>>   date value.  That is, CoDel only reacts to delay experienced in the
>>   last epoch of length interval.  It SHOULD be set to be on the order
>>   of the worst-case RTT through the bottleneck to give end-points
>>   sufficient time to react.
>> 
>>   The default interval value is 100 ms.
>> 
>> The default interval value is not suited for my 3g connection where
>> the worse-case RTT is much higher.
>> 
>> 
>> 
>> On Sat, Jul 23, 2016 at 10:36 PM, Loganaden Velvindron
>> <loganaden@gmail.com> wrote:
>>>>        It seems the initial burst like behavior from the earlier test was a false positive; these test are still not beautiful, but at least they do not indicate that HTB+fq_codel as configured on your system do not suffer from uncontrolled bursty-ness. Unfortunately, I have no real insight or advice to offer how to improve your situation (short f setting the shaper rates considerably lower).
>>>>        BTW, “tc -d qdisc” and “tc -s disc” give a bit more information, and “tc class show dev eth1” and “tc class show dev ifb4eth1” will also offer more detail about your setup.
>>>> 
>>>> 
>>>> Best Regards
>>>>        Sebastian
>>>> 
>>>> 
>>>> 
>>> 
>>> tc -d qdisc:
>>> 
>>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> quantum 300 target 5.0ms interval 100.0ms ecn
>>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>>> direct_packets_stat 5 ver 3.17 direct_qlen 1000
>>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>>> qdisc mq 0: dev wlan0 root
>>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>>> direct_packets_stat 0 ver 3.17 direct_qlen 32
>>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms ecn
>>> 
>>> tc -s qdisc:
>>> 
>>> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> quantum 300 target 5.0ms interval 100.0ms ecn
>>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>>  new_flows_len 0 old_flows_len 0
>>> qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 12
>>> direct_packets_stat 5 direct_qlen 1000
>>> Sent 23456195 bytes 109776 pkt (dropped 0, overlimits 86210 requeues 0)
>>> backlog 0b 4p requeues 0
>>> qdisc fq_codel 110: dev eth1 parent 1:11 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> Sent 14760 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>  maxpacket 256 drop_overlimit 0 new_flow_count 163 ecn_mark 0
>>>  new_flows_len 1 old_flows_len 0
>>> qdisc fq_codel 120: dev eth1 parent 1:12 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> Sent 23440300 bytes 109600 pkt (dropped 115, overlimits 0 requeues 0)
>>> backlog 5816b 4p requeues 0
>>>  maxpacket 1454 drop_overlimit 0 new_flow_count 15749 ecn_mark 0
>>>  new_flows_len 0 old_flows_len 1
>>> qdisc fq_codel 130: dev eth1 parent 1:13 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms
>>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>>  new_flows_len 0 old_flows_len 0
>>> qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
>>> Sent 190858989 bytes 149884 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>> qdisc mq 0: dev wlan0 root
>>> Sent 194287835 bytes 153002 pkt (dropped 0, overlimits 0 requeues 7)
>>> backlog 0b 0p requeues 7
>>> qdisc htb 1: dev ifb4eth1 root refcnt 2 r2q 10 default 10
>>> direct_packets_stat 0 direct_qlen 32
>>> Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 41505 requeues 0)
>>> backlog 0b 0p requeues 0
>>> qdisc fq_codel 110: dev ifb4eth1 parent 1:10 limit 1001p flows 1024
>>> quantum 300 target 500.0ms interval 100.0ms ecn
>>> Sent 192953486 bytes 149877 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>  maxpacket 1454 drop_overlimit 0 new_flow_count 16778 ecn_mark 0
>>>  new_flows_len 1 old_flows_len 2
>>> 
>>> 
>>> tc class show dev eth1
>>> class htb 1:11 parent 1:1 leaf 110: prio 1 rate 128Kbit ceil 100Kbit
>>> burst 1600b cburst 1600b
>>> class htb 1:1 root rate 300Kbit ceil 300Kbit burst 1599b cburst 1599b
>>> class htb 1:10 parent 1:1 prio 0 rate 300Kbit ceil 300Kbit burst 1599b
>>> cburst 1599b
>>> class htb 1:13 parent 1:1 leaf 130: prio 3 rate 50Kbit ceil 284Kbit
>>> burst 1600b cburst 1599b
>>> class htb 1:12 parent 1:1 leaf 120: prio 2 rate 50Kbit ceil 284Kbit
>>> burst 1600b cburst 1599b
>>> class fq_codel 110:188 parent 110:
>>> class fq_codel 120:3d6 parent 120:
>>> 
>>> 
>>> tc class show dev ifb4eth1:
>>> class htb 1:10 parent 1:1 leaf 110: prio 0 rate 19600Kbit ceil
>>> 19600Kbit burst 1597b cburst 1597b
>>> class htb 1:1 root rate 19600Kbit ceil 19600Kbit burst 1597b cburst 1597b
>>> class fq_codel 110:2f1 parent 110:
>>> class fq_codel 110:330 parent 110:
>>> 
>>> I changed the target from 350ms to 500ms for both ingress and egree,
>>> and the throughput seem to be better:
>>> 
>>> http://www.dslreports.com/speedtest/4515961

Re: [Cake] fq_codel on 3g network in Mauritius

[Jonathan Morton]

> On 24 Jul, 2016, at 13:53, moeller0 <moeller0@gmx.de> wrote:
> 
> In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.

Since the interval parameter depends on the RTT, not the one-way delay, it should always be the same both ways (except for inter-packet-time effects).

 - Jonathan Morton

Re: [Cake] fq_codel on 3g network in Mauritius

[moeller0]

Hi Jonathan,

> On Jul 24, 2016, at 13:28 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 24 Jul, 2016, at 13:53, moeller0 <moeller0@gmx.de> wrote:
>> 
>> In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.
> 
> Since the interval parameter depends on the RTT, not the one-way delay, it should always be the same both ways (except for inter-packet-time effects).

	Thanks for setting this straight. I was confused; the thing that lingered at the back of my mind was that if we do the target extension for one direction and correct the interval in that direction, we should also correct the interval in the other direction, especially since as Jonathan points out the interval describes the full back-and-forth path…

Best Regards
	Sebastian


> 
> - Jonathan Morton
> 

Re: [Cake] fq_codel on 3g network in Mauritius

[Jonathan Morton]

> On 24 Jul, 2016, at 17:40, moeller0 <moeller0@gmx.de> wrote:
> 
>>> In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.
>> 
>> Since the interval parameter depends on the RTT, not the one-way delay, it should always be the same both ways (except for inter-packet-time effects).
> 
> 	Thanks for setting this straight. I was confused; the thing that lingered at the back of my mind was that if we do the target extension for one direction and correct the interval in that direction, we should also correct the interval in the other direction, especially since as Jonathan points out the interval describes the full back-and-forth path…

To be more precise:

- The overhead compensation may differ in each direction, either due to asymmetric quirks of a particular link technology (DOCSIS), or because different links are used for each direction (unidirectional satellite).

- The “target" parameter must be set above one MTU serialisation delay, otherwise a “perfect” flow where each packet is enqueued just as the previous one is dequeued will trigger Codel.  Hence the ideal target may differ per direction, if bandwidth is relatively low and asymmetric.  Cake automatically performs this adjustment.

- The “interval” parameter should be higher than “target” by some minimum factor, which for significant asymmetry may also cause it to differ per direction.  Cake also automatically performs this adjustment, but does not rigidly hold it to the original recommendation of 20:1.

Hence, when using Cake, it is sufficient to set an “rtt” parameter (or associated keywords) consistent with expected path RTTs, and this should be the same in both directions.

 - Jonathan Morton

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

On Sun, Jul 24, 2016 at 6:40 PM, moeller0 <moeller0@gmx.de> wrote:
> Hi Jonathan,
>
>> On Jul 24, 2016, at 13:28 , Jonathan Morton <chromatix99@gmail.com> wrote:
>>
>>
>>> On 24 Jul, 2016, at 13:53, moeller0 <moeller0@gmx.de> wrote:
>>>
>>> In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.
>>
>> Since the interval parameter depends on the RTT, not the one-way delay, it should always be the same both ways (except for inter-packet-time effects).
>
>         Thanks for setting this straight. I was confused; the thing that lingered at the back of my mind was that if we do the target extension for one direction and correct the interval in that direction, we should also correct the interval in the other direction, especially since as Jonathan points out the interval describes the full back-and-forth path…
>
> Best Regards
>         Sebastian
>

I've updated the target to be 22ms based on my current interval of 450ms.

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

It's not pretty, but the quality is A or A+.

It's interesting to see the saw tooth pattern for the upload. This was
not the case when the target was 5ms, which I believe was calculated
based on a 100ms worse rtt.

Re: [Cake] fq_codel on 3g network in Mauritius

[moeller0]

Hi Loganaden,

> On Jul 24, 2016, at 19:13 , Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> On Sun, Jul 24, 2016 at 6:40 PM, moeller0 <moeller0@gmx.de> wrote:
>> Hi Jonathan,
>> 
>>> On Jul 24, 2016, at 13:28 , Jonathan Morton <chromatix99@gmail.com> wrote:
>>> 
>>> 
>>>> On 24 Jul, 2016, at 13:53, moeller0 <moeller0@gmx.de> wrote:
>>>> 
>>>> In theory interval can be different for ingress and egress (think old-school SAT-internet with modem upload) it probably is easiest to only configure one interval setting for the time being.
>>> 
>>> Since the interval parameter depends on the RTT, not the one-way delay, it should always be the same both ways (except for inter-packet-time effects).
>> 
>>        Thanks for setting this straight. I was confused; the thing that lingered at the back of my mind was that if we do the target extension for one direction and correct the interval in that direction, we should also correct the interval in the other direction, especially since as Jonathan points out the interval describes the full back-and-forth path…
>> 
>> Best Regards
>>        Sebastian
>> 
> 
> I've updated the target to be 22ms based on my current interval of 450ms.
> 
> http://www.dslreports.com/speedtest/4523668
> 
> It's not pretty, but the quality is A or A+.
> 
> It's interesting to see the saw tooth pattern for the upload. This was
> not the case when the target was 5ms, which I believe was calculated
> based on a 100ms worse rtt.


I just noticed you use the dslreports pre-canned profiles for measuring. I would recommend against doing that. As these will use different number of upstream/downstream flows per profile making comparisons between different profiles harder. I would recommend to get a free dslreports account and use the speed test configuration to use a fixed number of flows per direction (I typically use 16/16, but on slower links often I do not get all 16 going, in that case I retry with a lower number of flows, also set manually). After registration you can also request high resolution buffer bloat measurements, which nicely illustrate a link’s behavior under load (but might not work well on very slow links, so maybe you are already running the optimum configuration).

Best Regards
	Sebastian

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

>>
>> It's interesting to see the saw tooth pattern for the upload. This was
>> not the case when the target was 5ms, which I believe was calculated
>> based on a 100ms worse rtt.
>
>
> I just noticed you use the dslreports pre-canned profiles for measuring. I would recommend against doing that. As these will use different number of upstream/downstream flows per profile making comparisons between different profiles harder. I would recommend to get a free dslreports account and use the speed test configuration to use a fixed number of flows per direction (I typically use 16/16, but on slower links often I do not get all 16 going, in that case I retry with a lower number of flows, also set manually). After registration you can also request high resolution buffer bloat measurements, which nicely illustrate a link’s behavior under load (but might not work well on very slow links, so maybe you are already running the optimum configuration).


Thank you.

I did so, and here's the latest result:

https://www.dslreports.com/speedtest/4524841

It varies greatly. I think that it's due to the nature of the 3g connection.

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

I think what's happening is that regardless of what I apply on the
OpenWRT router, the modem is queueing & possibly re-ordering packets
its way.

The huawei B6A modem has a linux firmware. If I could access the cli
to reduce the tx length, I think that this may help.

Also, the 3g connection definitely looks bad and I blame that on the
mobile operator who cares only about bandwidth and has done little for
latency.

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

Hi Sebastian,

After reading about how much has been done in the latest kernel, I
decided to find a quick and easy way to get 3g mobile internet. I went
to another provider, and just put the SIM in an android one (Karbonn
Sparkle V) smartphone running Android 6.0.1.


Then, I activated the hotspot, and configured the TP-link WR841nd
(atheros wifi) to act as a client (STA mode). Everything else, just
connects to the ethernet switch, including a tiny wireless AP.

I did a test before applying any QoS:
https://www.dslreports.com/speedtest/4542608

Then, I applied sqm-qos on the wireless interface acting as an STA.

Next, I proceeded to use more connections on DSLreports:
Here are the results:

https://www.dslreports.com/speedtest/4542930
https://www.dslreports.com/speedtest/4542908
https://www.dslreports.com/speedtest/4542900
https://www.dslreports.com/speedtest/4542908

I'm consistently getting A and in one instance A+. Personally, I don't
think that it's possible to get A+ consistently on a 3g link, unless
android fixes the buffering in the USB/wifi subsystem+drivers.
However, moving from B/C to A/A+ for a 3g connection is encouraging,
even if it's not significant.

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

I went further, and rooted the android phone.

Then I set the txqueulen to 0 on ccimni0 and wlan0.

Here are the results:
https://www.dslreports.com/speedtest/4569339
https://www.dslreports.com/speedtest/4569379


Despite disabling the txqueuelen, The inbuilt TX/RX buffers are still
pretty high:

https://android.googlesource.com/kernel/mediatek/+/android-6.0.1_r0.100/drivers/misc/mediatek/dual_ccci/ccmni_net.c


#define CCMNI_TX_QUEUE 1000
#define CCMNI_UART_OFFSET 2

So my idea is to reduce the size of the queues so that it's just
enough for 21Mbit/s (down) , and 4Mbit/s (up), in the absence of BQL
support.

Re: [Cake] fq_codel on 3g network in Mauritius

[Mario Ferreira]

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

You could also use a custom kernel that would allow you to add
fq_codel/cake then add custom rules to it.

I would advise a setup such as: AFWall to run scripts depending on whether
it's WiFi or Mobile (3G/4G). The script would be a simplified debloat.sh
just adding simple tc fq_codel/cake commands.

I tried this before on the Samsung Galaxy Nexus back on 2013 [1] [2] with
AK_Kernel. I had interesting results though mixed ones. It was mostly due
to mobile data quality being awfully varied. Therefore, I wasn't
knowledgeable to find a good script setup that catered for all the moving
parts. Nonetheless, it improved my situation. I recommend it.

I've been meaning to try this again using a modified Franco kernel [2] for
Huawei Nexus 6P. However, as with everyone else, Real Life(TM) has a
tendency to get in the way. :) I don't use custom ROMs. It would be a stock
Nexus ROM installation, SU root for scripts/tc and custom kernel for
fq_codel/cake kernels.

We could try if people are interested. However, I can only be of help after
November.

1.
http://forum.xda-developers.com/galaxy-nexus/general/kernel-codel-kernel-modules-android-t2163790
2. https://github.com/lioux/ (Be kind, I know my github account looks like
a junior developer's sandbox :)

On Sat, Jul 30, 2016 at 12:45 AM Loganaden Velvindron <loganaden@gmail.com>
wrote:

> I went further, and rooted the android phone.
>
> Then I set the txqueulen to 0 on ccimni0 and wlan0.
>
> Here are the results:
> https://www.dslreports.com/speedtest/4569339
> https://www.dslreports.com/speedtest/4569379
>
>
> Despite disabling the txqueuelen, The inbuilt TX/RX buffers are still
> pretty high:
>
>
> https://android.googlesource.com/kernel/mediatek/+/android-6.0.1_r0.100/drivers/misc/mediatek/dual_ccci/ccmni_net.c
>
>
> #define CCMNI_TX_QUEUE 1000
> #define CCMNI_UART_OFFSET 2
>
> So my idea is to reduce the size of the queues so that it's just
> enough for 21Mbit/s (down) , and 4Mbit/s (up), in the absence of BQL
> support.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-- 

Mario S F Ferreira - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature

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

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

On Sat, Jul 30, 2016 at 5:04 PM, Mario Ferreira <liouxbsd@gmail.com> wrote:
> You could also use a custom kernel that would allow you to add fq_codel/cake
> then add custom rules to it.
>
CeroAndroid :)

> I would advise a setup such as: AFWall to run scripts depending on whether
> it's WiFi or Mobile (3G/4G). The script would be a simplified debloat.sh
> just adding simple tc fq_codel/cake commands.

I was thinking along the same line. However, my end goal would be to
build a case for Android to consider shipping fq_codel instead of
fifo_fast for android one. Instead of keeping the patches out of
android one tree, at least we could try to make them accept it.

>
> I tried this before on the Samsung Galaxy Nexus back on 2013 [1] [2] with
> AK_Kernel. I had interesting results though mixed ones. It was mostly due to
> mobile data quality being awfully varied. Therefore, I wasn't knowledgeable
> to find a good script setup that catered for all the moving parts.
> Nonetheless, it improved my situation. I recommend it.
>
> I've been meaning to try this again using a modified Franco kernel [2] for
> Huawei Nexus 6P. However, as with everyone else, Real Life(TM) has a
> tendency to get in the way. :) I don't use custom ROMs. It would be a stock
> Nexus ROM installation, SU root for scripts/tc and custom kernel for
> fq_codel/cake kernels.
>
> We could try if people are interested. However, I can only be of help after
> November.
>

I think that if I could get some kind of BQL/DQL into the mediatek
driver, and convince the mediatek folks to take the patch by showing
them the benefits, we could get a long way towards seeing an upcoming
release of android with support for this.

The nice thing is that it appears that the mediatek driver on the
android repository is complete.


> 1.
> http://forum.xda-developers.com/galaxy-nexus/general/kernel-codel-kernel-modules-android-t2163790
> 2. https://github.com/lioux/ (Be kind, I know my github account looks like a
> junior developer's sandbox :)

:)

>
> On Sat, Jul 30, 2016 at 12:45 AM Loganaden Velvindron <loganaden@gmail.com>
> wrote:
>>
>> I went further, and rooted the android phone.
>>
>> Then I set the txqueulen to 0 on ccimni0 and wlan0.
>>
>> Here are the results:
>> https://www.dslreports.com/speedtest/4569339
>> https://www.dslreports.com/speedtest/4569379
>>
>>
>> Despite disabling the txqueuelen, The inbuilt TX/RX buffers are still
>> pretty high:
>>
>>
>> https://android.googlesource.com/kernel/mediatek/+/android-6.0.1_r0.100/drivers/misc/mediatek/dual_ccci/ccmni_net.c
>>
>>
>> #define CCMNI_TX_QUEUE 1000
>> #define CCMNI_UART_OFFSET 2
>>
>> So my idea is to reduce the size of the queues so that it's just
>> enough for 21Mbit/s (down) , and 4Mbit/s (up), in the absence of BQL
>> support.
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
> --
>
> Mario S F Ferreira - Brazil - "I guess this is a signature."
> feature, n: a documented bug | bug, n: an undocumented feature

Re: [Cake] fq_codel on 3g network in Mauritius

[Mario Ferreira]

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

On Sat, Jul 30, 2016 at 10:48 AM Loganaden Velvindron <loganaden@gmail.com>
wrote:

> On Sat, Jul 30, 2016 at 5:04 PM, Mario Ferreira <liouxbsd@gmail.com>
> wrote:
> > You could also use a custom kernel that would allow you to add
> fq_codel/cake
> > then add custom rules to it.
> >
> CeroAndroid :)
>

  Nothing so grand. As in all things software, simpler/smaller/faster is
better (usually in that order). There are TOO many voices to interfere.


> > I would advise a setup such as: AFWall to run scripts depending on
> whether
> > it's WiFi or Mobile (3G/4G). The script would be a simplified debloat.sh
> > just adding simple tc fq_codel/cake commands.
>
> I was thinking along the same line. However, my end goal would be to
> build a case for Android to consider shipping fq_codel instead of
> fifo_fast for android one. Instead of keeping the patches out of
> android one tree, at least we could try to make them accept it.
>

  My experience has been that you FIRST make a proof of concept. Get it
working, write the instructions, make it baby proof to code merge, etc.
THEN, you try to convince them to accept it.

  Franco kernel or any other custom kernel follows the official Android
git. We need to get it out there so that it gets attention. David Taht et
al have been working for YEARS on getting people to notice something that
has PHYSICAL verifiable proof = facts. It's a
technical/political/financial/faith/crazy issue. No intention to offend
anyone.


> > I tried this before on the Samsung Galaxy Nexus back on 2013 [1] [2] with
> > AK_Kernel. I had interesting results though mixed ones. It was mostly
> due to
> > mobile data quality being awfully varied. Therefore, I wasn't
> knowledgeable
> > to find a good script setup that catered for all the moving parts.
> > Nonetheless, it improved my situation. I recommend it.
> >
> > I've been meaning to try this again using a modified Franco kernel [2]
> for
> > Huawei Nexus 6P. However, as with everyone else, Real Life(TM) has a
> > tendency to get in the way. :) I don't use custom ROMs. It would be a
> stock
> > Nexus ROM installation, SU root for scripts/tc and custom kernel for
> > fq_codel/cake kernels.
> >
> > We could try if people are interested. However, I can only be of help
> after
> > November.
> >
>
> I think that if I could get some kind of BQL/DQL into the mediatek
> driver, and convince the mediatek folks to take the patch by showing
> them the benefits, we could get a long way towards seeing an upcoming
> release of android with support for this.
>
> The nice thing is that it appears that the mediatek driver on the
> android repository is complete.


  I am all for it. Keep us posted. :) A lot of folks here have experience
on getting GOOD/NECESSARY/PROVED things going when everyone else disagrees.
Reach out. We can all benefit from it.
-- 

Mario S F Ferreira - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature

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

Re: [Cake] fq_codel on 3g network in Mauritius

[Loganaden Velvindron]

My conclusion from playing with fq_codel, cake, and txqueuelen 0 hacks
is that as a pre-requisite, we need to have ISPs that are able to give
latency with little variations to various places around the earth.

Proving that any QoS on high bandwidth with volatile RTTs is difficult
due to the "jitter".


Please correct me if I'm wrong.

Re: [Cake] fq_codel on 3g network in Mauritius

[David Lang]

On Wed, 3 Aug 2016, Loganaden Velvindron wrote:

> My conclusion from playing with fq_codel, cake, and txqueuelen 0 hacks
> is that as a pre-requisite, we need to have ISPs that are able to give
> latency with little variations to various places around the earth.
>
> Proving that any QoS on high bandwidth with volatile RTTs is difficult
> due to the "jitter".
>
>
> Please correct me if I'm wrong.

I think you have the order wrong. In order for the ISPs to provide consistant 
latencies, we need fq_codel, cake, or similar to be deployed widely, including 
in the ISP equipment so that the latencies are managed sanely when overloads 
hit.

David Lang