[solved] PPP sessions restarting, and Phone audio cutting out, what to do?

Okay, that pretty much looks like starvation, I agree (for what it is worth, I am no expert in this field).

Try installing iftop and look at it to get an idea what is causing these upstream spikes.

I guess the issue is that this phone is massively more latency sensitive than the other applications. You could run mtr against say the SIP server address to see how bad the cyclic delay increases actually are.

Sure, the bigger question is how difficult would it be to do so. How about you switch from piece_of_cake to layer_cake first? This will introduce a higher priority "tin" which if it has enough bandwidth might be sufficient to keep your voice calls audible from the outside.

If you switch to layer_cake, please post the output of tc -s qdisc so we can check how much bandwidth is reserved for high-priority traffic.

You could alternatively try to switch to per-internal-host-IP fairness, but that will only work if you have <= 7 concurrent computers active (I simply assume that a voip call requires around 100Kbps per direction... Let's try layer-cake first. In the unlikely event that your Cisco SPA112 already uses standard conforming DSCPs on its packets that might already fix you issue (but I would consider that to be very unlikely) But see page 8 of https://spiderwebsolutions.com.au/wp-content/uploads/2017/09/Cisco-SPA112-and-SPA-122-Simple-Configuration-Guide.pdf which seems to show how to configure DSCPs for your Cisco device....

Sure, but it comes with the same configuration challenges as increasing/guaranteeing the bandwith for the cisco ATA... (and layer_cake also has something up its sleeve for this case the bulk "tin" for background/low priority traffic which will yield to higher priority traffic quickly).

Well, traditional QoS systems give all the freedom to configure every last detail manually, but the goal of sqm is to pretty much work out of the box without the need for much configuration. But sqm can basically be used to run self-made qos scripts and hence still allows fine-detailled QoS schemes it just does not offer them out-of-the-box....

1 Like

DSL should operate at exactly the speed of your plan. If you're not getting the advertised speed you need to investigate with the phone company. I don't know exactly what the quality numbers mean but any SES at all seems bad. If you talk to the phone company they can check what their equipment is receiving.

Don't trust old phone wiring in the house. You should have a direct line of modern twisted pair cable (cat5e or at least cat3) from the phone company demarcation to your modem.

SQM doesn't do anything unless it is set for lower than the actual speed imposed by the line hardware or the rate limiter at the ISP end. The trick is of course to get it just slightly lower.

It does. Or at least it's easy to configure if not on by default. I had one of these.

1 Like

Excellent news, let's try the layer_cake route! BTW your sync is pretty high for your shaper settings, so could you say perform 3 dslreports speedtests in a row with SQM disabled and post them here? I have a hunch that we might be able to get decent bufferbloat results with higher usable bandwidth.

1 Like

I have disconnected my yunohost server and made test with the sip phone and it worked smoothly without any issue.

How do I run mtr? Do I need to logged in OpenWrt?

here it is :


root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 3307091959 bytes 10867650 pkt (dropped 0, overlimits 0 requeues 8) 
 backlog 0b 0p requeues 8
  maxpacket 1514 drop_overlimit 0 new_flow_count 800 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 803d: dev pppoa-wan root refcnt 2 bandwidth 770Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 449180 bytes 5041 pkt (dropped 1, overlimits 3786 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 48288b of 4Mb
 capacity estimate: 770Kbit
 min/max network layer size:           40 /    1460
 min/max overhead-adjusted size:      106 /    1643
 average network hdr offset:            0

                   Bulk  Best Effort        Voice
  thresh       48120bit      770Kbit    192496bit
  target        365.1ms       22.8ms       91.3ms
  interval      730.2ms      117.8ms      186.3ms
  pk_delay          0us        7.1ms        4.2ms
  av_delay          0us        606us        131us
  sp_delay          0us         27us         83us
  backlog            0b           0b           0b
  pkts                0         5000           42
  bytes               0       443642         6998
  way_inds            0            3            0
  way_miss            0          437           12
  way_cols            0            0            0
  drops               0            1            0
  marks               0            0            0
  ack_drop            0            0            0
  sp_flows            0            3            7
  bk_flows            0            2            0
  un_flows            0            0            0
  max_len             0         1460          432
  quantum           300          300          300

qdisc ingress ffff: dev pppoa-wan parent ffff:fff1 ---------------- 
 Sent 10515196 bytes 8381 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 803e: dev ifb4pppoa-wan root refcnt 2 bandwidth 8400Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 10328805 bytes 8252 pkt (dropped 129, overlimits 14268 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 66528b of 4Mb
 capacity estimate: 8400Kbit
 min/max network layer size:           40 /    1460
 min/max overhead-adjusted size:      106 /    1643
 average network hdr offset:            0

                  Tin 0
  thresh       8400Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay       12.5ms
  av_delay        4.6ms
  sp_delay         22us
  backlog            0b
  pkts             8381
  bytes        10515196
  way_inds            3
  way_miss          384
  way_cols            0
  drops             129
  marks               0
  ack_drop            0
  sp_flows            4
  bk_flows            1
  un_flows            0
  max_len          1460
  quantum           300

root@OpenWrt:~#

I can't access these setup. Only OVH does. After initializing the Cisco-SPA112 with default username/password, I've been logged out and only OVH can log in.

Sure, here are three test I did before enabling SQM and with only one computer connected to my modem/router and with one web browser page open.
I did 10 test in a a row to reach to an average upload of 8800 kbit/s (95% make it 8400) and download of 810 kbit/s (95% make it 770).

here is the list of the 10 tests before enabling SQM

2019-02-02 10:53:36 8.78 0.903 38 C C C DSL AS20766 8 / 2
2019-02-02 10:52:24 8.78 0.807 39 C C C DSL AS20766 8 / 2
2019-02-02 10:51:28 8.91 0.903 37 B C B DSL AS20766 8 / 2
2019-02-02 10:46:13 8.76 0.876 37 B C B DSL AS20766 8 / 2
2019-02-02 10:45:21 8.79 0.829 37 B C B DSL AS20766 8 / 2
2019-02-02 10:44:07 8.77 0.733 37 B C B DSL AS20766 8 / 2
2019-02-02 10:43:10 8.8 0.711 37 B C B DSL AS20766 8 / 2
2019-02-02 10:41:20 8.65 0.842 37 B C B DSL AS20766 8 / 2
2019-02-02 10:40:23 8.91 0.737 36 B C B DSL AS20766 8 / 2
2019-02-02 10:38:42 8.77 0.733 37 B C B DSL AS20766 8 / 2

and here are 10 test I did after enabling SQM, when I was testing if overhead should be 14,13,12,11 or even 10 and as you, in the last one with overhead at 10, I have what seems to be good result (for what I understand of them).

2019-02-02 11:23:47 6.95 0.61 37 A D B DSL AS20766 8 / 2
2019-02-02 11:22:55 7.08 0.699 36 A+ D B DSL AS20766 8 / 2
2019-02-02 11:20:42 7.1 0.603 37 A D B DSL AS20766 8 / 2
2019-02-02 11:19:48 6.95 0.55 37 A+ D B DSL AS20766 8 / 2
2019-02-02 11:17:33 6.94 0.54 36 A D B DSL AS20766 8 / 2
2019-02-02 11:16:38 6.82 0.563 37 A D B DSL AS20766 8 / 2
2019-02-02 11:14:23 6.95 0.638 37 A D B DSL AS20766 8 / 2
2019-02-02 11:13:29 6.95 0.519 37 A D B DSL AS20766 8 / 2
2019-02-02 11:10:00 6.68 0.513 37 A D B DSL AS20766 8 / 2
2019-02-02 11:09:06 6.82 0.571 37 A D B DSL AS20766 8 / 2

I'm going to try the SIP phone with the server connected now that I have changed to layer_cake and I'll come back to let you know the result of my tests.

That would work (you might need to run opkg update ; opkg install mtr first) or you can run it from linux/macos machines, for windows there is https://sourceforge.net/projects/winmtr/.

So 192496/1000 = 192.496 Kbps, that should be sufficient for roughly two concurrent VoIP calls with the usual codecs, so I believe this might actually work out...

Fair enough, or rather unfair enough. But try on your router the following:

cd /tmp
opkg update ; opkg install tcpdump
tcpdump -s 1600 -i pppoa-wan -w pppoa-VoIP-test.cap

then perform a voice call (not too long so the capture file does not get too large please)

press control-C on the router shell to stop tcpdump.

then copy the resulting capture file /tmp/pppoa-VoIP-test.cap from your router to a computer (using say scp or winscp), then open this file with wireshark and look at potential dscp markings on packets send by the cisco device. Please report your results here.

Great, so now these average values are net goodput while you should feed the shaper with gross rates.
So I would try the following (and then test and potentially reduce the rates until the bufferbloat plots looks acceptable):

8800 * 53/48 * (1510/(1500-20-20)) = 10049.42 * 0.9 = 9044.478 Mbps -> try 9000 Kbps
810 * 53/48 * (1510/(1500-20-20)) = 925 * 0.99 = 915.75 Mbps -> try 900 Kbps
Since for the upload you control the access to the bottleneck link you should be able to get really close to the real link's capacity than on ingress.

Curious about how that is going to work out...

1 Like

First long attempt of 14 min call without any issue. Yeah! Long live layer_cake! Well, before conclusion I'd rather wait few days and make several phone call to be sure it is indeed perfectly working.

Ok, I'll try that once I fell the SIP phone is really working. So you say that I should put 9000/900 instead of 8400/770 and then reduce till "bufferbloat plots looks acceptable". What means "bufferbloat plots looks acceptable"? How do I know that?

do you still want me to do that?

?

Ok, so I did it from my GNU/Linux machine.
mtr 91.121.128.137

and here is what is displaying for example :

That is the right approach! Give it some testing before declaring mission accomplished.

These should be independent of the SIP phone, or rather the increase in the upload direction should improve the situation somewhat. But again treating this as orthogonal to the SIP issue sounds like a decent plan.

Yes.

Make a dslreports speedtest and then go to the detailed results page, in the grades section you see the bar graphs for idle downloading and uploading, if you click the links under the 3 bars you will see all results from the individual latency probes, if they all stay nice and low, it would be acceptable to me; but your acceptance threshold might be different so just look at it yourself :wink: I would say the plots in https://www.dslreports.com/speedtest/45499092 certainly show acceptable bufferbloat for reference, at least for my taste; so if the results with 9000/900 look very similar -> mission accomplished ;).

Well, while it would be interesting to learn which DSCP marks your SIP traffic actually uses, it is less urgent as long as layer_cake really solves your problem.

So let me propose a simpler test:

tc -s qdisc, then do a call and immediate after do tc -s qdisc again, we should then see an increase in traffic in the counters for the egress voice tin...

1 Like

So it looks like your link is severely overloaded here, all worst and average RTTs increase to unhealthy levels (>100ms) after your modem.modem, I can see how voip could be affected by this (but only latency wise, I still fail to understand why your calls get silenced by this).

So I'll come back in few days about it.

here it is :


 OpenWrt 18.06.1, r7258-5eb055306f
 -----------------------------------------------------
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 647454354 bytes 1436247 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 1474 drop_overlimit 0 new_flow_count 45 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800a: dev pppoa-wan root refcnt 2 bandwidth 770Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 451250108 bytes 3713770 pkt (dropped 440219, overlimits 4237244 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 4196736b of 4Mb
 capacity estimate: 770Kbit
 min/max network layer size:           28 /    1460
 min/max overhead-adjusted size:       53 /    1643
 average network hdr offset:            0

                   Bulk  Best Effort        Voice
  thresh       48120bit      770Kbit    192496bit
  target        365.1ms       22.8ms       91.3ms
  interval      730.2ms      117.8ms      186.3ms
  pk_delay          0us       66.9ms       14.3ms
  av_delay          0us       15.1ms        3.5ms
  sp_delay          0us         26us         58us
  backlog            0b           0b           0b
  pkts                0      4120047        33942
  bytes               0    553098184      6079549
  way_inds            0       613943          946
  way_miss            0       352051         1382
  way_cols            0        29344            0
  drops               0       440219            0
  marks               0          439            0
  ack_drop            0            0            0
  sp_flows            0          310            3
  bk_flows            0            1            0
  un_flows            0            8            0
  max_len             0         2178          576
  quantum           300          300          300

qdisc ingress ffff: dev pppoa-wan parent ffff:fff1 ---------------- 
 Sent 7307360081 bytes 6075012 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800b: dev ifb4pppoa-wan root refcnt 2 bandwidth 8400Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 7223492514 bytes 6017194 pkt (dropped 57818, overlimits 9739445 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 147840b of 4Mb
 capacity estimate: 8400Kbit
 min/max network layer size:           28 /    1480
 min/max overhead-adjusted size:       53 /    1696
 average network hdr offset:            0

                  Tin 0
  thresh       8400Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay        784us
  av_delay         57us
  sp_delay         23us
  backlog            0b
  pkts          6075012
  bytes      7307360081
  way_inds       436889
  way_miss       401340
  way_cols            6
  drops           57818
  marks               1
  ack_drop            0
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len          1480
  quantum           300

root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 649310159 bytes 1444175 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 1474 drop_overlimit 0 new_flow_count 45 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800a: dev pppoa-wan root refcnt 2 bandwidth 770Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 452504777 bytes 3720410 pkt (dropped 445206, overlimits 4252502 requeues 0) 
 backlog 111048b 600p requeues 0
 memory used: 4196736b of 4Mb
 capacity estimate: 770Kbit
 min/max network layer size:           28 /    1460
 min/max overhead-adjusted size:       53 /    1643
 average network hdr offset:            0

                   Bulk  Best Effort        Voice
  thresh       48120bit      770Kbit    192496bit
  target        365.1ms       22.8ms       91.3ms
  interval      730.2ms      117.8ms      186.3ms
  pk_delay          0us         4.2s       30.8ms
  av_delay          0us      763.8ms        5.5ms
  sp_delay          0us       22.0ms        422us
  backlog            0b      111048b           0b
  pkts                0      4131112        35104
  bytes               0    555464731      6308672
  way_inds            0       617284          960
  way_miss            0       354100         1384
  way_cols            0        30518            0
  drops               0       445206            0
  marks               0          440            0
  ack_drop            0            0            0
  sp_flows            0          318            8
  bk_flows            0          364            0
  un_flows            0          339            0
  max_len             0         2178          576
  quantum           300          300          300

qdisc ingress ffff: dev pppoa-wan parent ffff:fff1 ---------------- 
 Sent 7309154087 bytes 6083102 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800b: dev ifb4pppoa-wan root refcnt 2 bandwidth 8400Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 7225286520 bytes 6025284 pkt (dropped 57818, overlimits 9741950 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 147840b of 4Mb
 capacity estimate: 8400Kbit
 min/max network layer size:           28 /    1480
 min/max overhead-adjusted size:       53 /    1696
 average network hdr offset:            0

                  Tin 0
  thresh       8400Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay        1.8ms
  av_delay        202us
  sp_delay         28us
  backlog            0b
  pkts          6083102
  bytes      7309154087
  way_inds       437216
  way_miss       404380
  way_cols            6
  drops           57818
  marks               1
  ack_drop            0
  sp_flows           35
  bk_flows            2
  un_flows            0
  max_len          1480
  quantum           300

root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 649626897 bytes 1445075 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 1474 drop_overlimit 0 new_flow_count 45 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800a: dev pppoa-wan root refcnt 2 bandwidth 770Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 452661848 bytes 3721293 pkt (dropped 445716, overlimits 4254535 requeues 0) 
 backlog 119373b 429p requeues 0
 memory used: 4196736b of 4Mb
 capacity estimate: 770Kbit
 min/max network layer size:           28 /    1460
 min/max overhead-adjusted size:       53 /    1643
 average network hdr offset:            0

                   Bulk  Best Effort        Voice
  thresh       48120bit      770Kbit    192496bit
  target        365.1ms       22.8ms       91.3ms
  interval      730.2ms      117.8ms      186.3ms
  pk_delay          0us         2.3s       28.2ms
  av_delay          0us      551.6ms        5.3ms
  sp_delay          0us       29.6ms        328us
  backlog            0b      119373b           0b
  pkts                0      4132309        35129
  bytes               0    555720319      6312578
  way_inds            0       617670          963
  way_miss            0       354326         1384
  way_cols            0        30608            0
  drops               0       445716            0
  marks               0          440            0
  ack_drop            0            0            0
  sp_flows            0          390            4
  bk_flows            0          274            0
  un_flows            0          331            0
  max_len             0         2178          576
  quantum           300          300          300

qdisc ingress ffff: dev pppoa-wan parent ffff:fff1 ---------------- 
 Sent 7309458591 bytes 6084010 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800b: dev ifb4pppoa-wan root refcnt 2 bandwidth 8400Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms atm overhead 10 
 Sent 7225591024 bytes 6026192 pkt (dropped 57818, overlimits 9742322 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 147840b of 4Mb
 capacity estimate: 8400Kbit
 min/max network layer size:           28 /    1480
 min/max overhead-adjusted size:       53 /    1696
 average network hdr offset:            0

                  Tin 0
  thresh       8400Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay        850us
  av_delay        154us
  sp_delay         25us
  backlog            0b
  pkts          6084010
  bytes      7309458591
  way_inds       437242
  way_miss       404733
  way_cols            6
  drops           57818
  marks               1
  ack_drop            0
  sp_flows           33
  bk_flows            1
  un_flows            0
  max_len          1480
  quantum           300

root@OpenWrt:~#

I discovered that when I did it mtr, someone was calling at the same time. As I'm imagining it could affect the result, here is a new one when nobody is calling.

These are the relevant counters from the three? calls to tc -s qdisc (why three?)
pkts 0 4120047 33942
pkts 0 4131112 35104
pkts 0 4132309 35129

Assuming the first and last to be relevant I see:
4132309-4120047 = 12262 best effort packets
and
35129-33942 = 1187 packets in the Voice tin
with voip typically sending at 50 packets per second (see e.g. https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html)
this would be 1187/50 = 23.74 seconds worth of a voip call, does this sound reasonable?

Anyway this does show that there is some usage of those dscp marks that get moved into the high priority voice tin.

Okay, that looks saner...

my mistake. I guess the third was unwanted...

Indeed.

Thank you @moeller0 for all your time!

I'll come back few days later, once I'm confident the SIP phone is working well and I'll do the test with 9000/900 and I'll let you know the result.

And I will do that test if it can be useful and you think someone could be curious about it.

1 Like

Take you time, if you problem is fixed by layer_cake, maybe you do not need to measure this at all, really I am just curious and my curiosity will subside eventually :wink:

What about the ppp dropping. Was that just an attempt to debug the phone issue or is that causing disconnects still?

I don't know because I restarted the router recently to make tests so I couldn't notice any new disconnection. If it happens, as you seem to be interested, I'll let you know.

Since in the end it seems the bigger issue was the phone I was thinking maybe to suggest an edit to the post title so others with similar phone issues might find it easier in searches...

1 Like

Oh, I see. It's true the subject has changed along the conversation and indeed, the SIP phone was a bigger issue and find its solution (it looks like it did so far).
So, yeah, sure, I'll change the title.

OK, phone is working well since I changed to cake_layer. So, thank you so much @moeller0!

I did it and I even tried to increase them +100 at a time to reach the couple 9800/1000. Results looks good to me even though sometime, the first bufferbloat sample for upload is a bit higher (but it was already the case when I was at 8400 so I guess it's ok).
If I increase to 10000/1100 then bufferbloat's samples on graphs become crazy so I reached the very maximum.
This one is good

but this one is less good (first sample for upload)

but of the five test done, none are worse than this one so I assume it's ok. Can you confirm?

2019-02-08 10:04:38 8.24 0.845 37 A C B DSL AS20766 8 / 2
2019-02-08 10:03:29 8.39 0.826 36 A C B DSL AS20766 8 / 2
2019-02-08 10:02:19 8.13 0.786 37 A C B DSL AS20766 8 / 2
2019-02-08 10:01:24 8.39 0.808 36 A C B DSL AS20766 8 / 2
2019-02-08 09:59:55 8.26 0.789 37 A D B DSL AS20766 8 / 2

I did it.
I have installed Wireshark and have tried to look for the information you asked me.
Here is what I've found.

"Start Time","Stop Time","Initial Speaker","From","To","Protocole","Duration","Paquets","State","Comments"
"9.588992","24.096831","80.67.176.70",""0033290380663" <sip:0033290380663@sip4.ovh.fr>","<sip:0766005589@sip4.ovh.fr>","SIP","00:00:14","10","IN CALL","INVITE 407 200"

I keep the file and I'm ready to look for more information into it if you explain me how.

This is a policy question, so you need to make this decision. I probably would go for 9000/1000 just to be prepared for multiple incoming bulk flows; on the other hand you did exactly what I recommend, iteratively probe your personally acceptable trade-off between latency-under-load-increase and bandwidth sacrifice. :wink: So if you are happy with 9800/1000 then by all means go for it. I note that the initial download spike is a consequence of setting the download value relative high, so the backspill of packets into the upstream buffers gets noticeable even for only 8 concurrent streams.

Great, merci! Just select one of the packets of this flow in wireshark and look at voip session packets (most likely UDP) and search in the internet protocol header for:

Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)
    1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)
    .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

and search for a SIP packet and also look in the internet protocol header for:

Differentiated Services Field: 0x88 (DSCP: AF41, ECN: Not-ECT)
    1000 10.. = Differentiated Services Codepoint: Assured Forwarding 41 (34)
    .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

as you can see in my case both are not using the default value of 0, I note that cake's diffserv3 will treat AF41 like 0, but the critical EF marking for the actual VoIP data packets end up in the high priority voice tin.

I hope this helps.