Limiter does not calc right on ingress devices

I might be doing something wrong, but in my setup today I discovered that cake might double the actually used datarate on the ingress device and accordingly shaping everything ingressing to the device to the half of the configured limiter.

tc qdisc add dev ifb0 root cake bandwidth 50mbit

Would limit the device which has attached ifb0 to something around 25mbit.

If appropriate I might provide some sample configs. :)

Please do - it works fine on ingress here, so there may be some subtlety in your config that is confusing matters.

Jonathan Morton

Good morning,

thanks for your fast response, I've attached some lines from my script.

I've doublechecked my math, so cake actually prints on it's own statistics the right values for the bandwidth.

bugreport_cake_ingress.txt

So I fixed the issue temporary by doubling the USE_DOWNPERCENT in my calcs :)

On 22 Jun, 2016, at 09:31, @RubenKelevra notifications@github.com wrote:

thanks for your fast response, I've attached some lines from my script.

This setup looks sane.

If you’re running this on top of some other system, however, there may be other things filtering into ifb0 and ifb1 which aren’t reflected in the script. This could cause packets to pass through Cake twice, causing each to occupy twice the “airtime” it should.

You should be able to diagnose this fault by running tcpdump or Wireshark on, say, ifb0 and watching for duplicate packets. You may need to turn up the verbosity to get enough detail to recognise duplicates. Probably you don’t need (or want) a fully loaded network to uncover the problem - a simple once-per-second ping is likely to suffice.

If that isn’t the problem, then I might have to suspect your device’s high-resolution timer of being miscalibrated, ie. running at half speed. I’m not sure how likely that is or how best to verify it. Check for duplicate packets first.

Jonathan Morton

Hi Ruben,

could you also post the output of:

tc -d qdisc

tc -s class show dev ppp0 tc -s class show dev ifb1

tc -s class show dev tun0 tc -s class show dev ifb0

So your hierarchy looks like this, if I understood correctly:

“logical”: egress: UPLINK_IF=ppp0 -> cake(NEAR_MAX_UPRATE) VPN_IF=tun0 -> cake(NEAR_MAX_UPRATE_VPN)

ingress: VPN_IF(ingress) : VPN_INGRESS=ifb0 -> cake(NEAR_MAX_DOWNRATE_VPN) UPLINK_IF(ingress): UPLINK_INGRESS=ifb1-> cake(NEAR_MAX_DOWNRATE)

with the biggest difference being the added src/dsthost keywords for the VPN cake instances.

“physical”: assuming: tun0->ppp0->ethN?

So in essence you have two cake instances per direction: ingress: UPLINK_INGRESS -> VPN_INGRESS -> “user” egress “user” -> VPN_IF -> UPLINK_IF

A few questions:

1a) Why do you nest your shapers like this? What exact fairness are you looking for with this setup? 1b) If you dump packet on tun0 do you really still see the internal IP addresses?

2) For fun, what happens if you only instantiate one of the shapers, and send test traffic over the according interface, do you still see the bandwidth reduction?

3) Why do you not account for the VPN overhead using the “overhead N” option instead of statically accounting for it by reducing the bandwidth by a fixed percentage? I assume your VPN will simply encrypt and wrap user packets one-by-one into its own container packet, so for each user packet you get one VPN packet.

4) Final question, you really have a PTM using link with only 10/1 Mbps? The slowest PTM links I have heard of are 16/1Mbps VDSL@ fallbacks for users with non-vectoring capable modems on a vectoring enabled DSLAM/MSAN. Typically in that speed range users get ATM-based adsl links. Now, in theory it is possible to use PTM on an ATM link (after all PTM is described in an Annex to the ADSL2 standard by ITU) but I have never heard that being actually implemented in the real world, so I am really curious to learn more about your actual link. If you please could elaborate a bit I would be quite happy.

Best Regards Sebastian

On Jun 22, 2016, at 08:31 , @RubenKelevra notifications@github.com wrote:

Good morning,

thanks for your fast response, I've attached some lines from my script.

I've doublechecked my math, so cake actually prints on it's own statistics the right values for the bandwidth.

bugreport_cake_ingress.txt

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

“physical”: assuming: tun0->ppp0->ethN? Assumption was correct and ppp0 goes over eth0 out of the router.

1a) Why do you nest your shapers like this? What exact fairness are you looking for with this setup?

We use a Side-to-Side VPN, which goes over tun0, there are several remote-desktop connections which has to be fair. I classify the tun0 packages for the ppp0 shaper as a higher class than other traffic to get a lower latency.

With this remote desktop setup over PPPoE it's all about latency. :)

1b) If you dump packet on tun0 do you really still see the internal IP addresses?

Yep, it's routed within the 10.0.0.0/8 range.

2) For fun, what happens if you only instantiate one of the shapers, and send test traffic over the according interface, do you still see the bandwidth reduction?

Have to test it out, since I'm not at this customer at the moment this have to wait a bit, sorry.

3) Why do you not account for the VPN overhead using the “overhead N” option instead of statically accounting for it by reducing the bandwidth by a fixed percentage? I assume your VPN will simply encrypt and wrap user packets one-by-one into its own container packet, so for each user packet you get one VPN packet.

Well actually I needed a bit headroom and my setup started with fq_codel, so this is a remain. I'm using OpenVPN UDP which breaks the packages in two chucks, so I don't know the exact overhead here ... and didn't found the keyword either.

4) Final question, you really have a PTM using link with only 10/1 Mbps? The slowest PTM links I have heard of are 16/1Mbps VDSL@ fallbacks for users with non-vectoring capable modems on a vectoring enabled DSLAM/MSAN. Typically in that speed range users get ATM-based adsl links. Now, in theory it is possible to use PTM on an ATM link (after all PTM is described in an Annex to the ADSL2 standard by ITU) but I have never heard that being actually implemented in the real world, so I am really curious to learn more about your actual link. If you please could elaborate a bit I would be quite happy.

This is actually a 16/1 Mbit/s VDSL with a very low latency of 8 ms to the nearst peers in the internet. So it's just a bit crappy You'll get just 600 - 650 kbit/s up and 9.5 to 11.2 down, so I just selected 10 to get enough headroom here, but today I reduced it again to 9.5 because it was bad today.

Some days ago this was actually a adsl link with around 60 ms ping, but they (Telekom) just install fiber to the curb, 100 meteres away, and switched to vdsl. We expect to get in September vdsl with vectoring 100/40 Mbit at this location.

Hi Ruben,

On Jun 27, 2016, at 16:02 , @RubenKelevra notifications@github.com wrote:

“physical”: assuming: tun0->ppp0->ethN? Assumption was correct and ppp0 goes over eth0 out of the router.

1a) Why do you nest your shapers like this? What exact fairness are you looking for with this setup? We use a Side-to-Side VPN, which goes over tun0, there are several remote-desktop connections which has to be fair. I classify the tun0 packages for the ppp0 shaper as a higher class than other traffic to get a lower latency.

Ah, so its just remote desktop sessions over the VPN? What else is being send over ppp0?

With this remote desktop setup over PPPoE it's all about latency. :)

1b) If you dump packet on tun0 do you really still see the internal IP addresses? Yep, it’s routed within the 10.0.0.0/8 range.

This is great, it also means you might want to try dual-scrhost and dual-dsthost to also flow fairness per internal IP on the VPN. Or maybe even triple-isolate which tries to be fair to both sides…

2) For fun, what happens if you only instantiate one of the shapers, and send test traffic over the according interface, do you still see the bandwidth reduction? Have to test it out, since I’m not at this customer at the moment this have to wait a bit, sorry.

Okay.

3) Why do you not account for the VPN overhead using the “overhead N” option instead of statically accounting for it by reducing the bandwidth by a fixed percentage? I assume your VPN will simply encrypt and wrap user packets one-by-one into its own container packet, so for each user packet you get one VPN packet. Well actually I needed a bit headroom and my setup started with fq_codel, so this is a remain. I’m using OpenVPN UDP which breaks the packages in two chucks,

So you are getting two IP fragments per unencrypted IP packet, or two full UDP packets. I always thought that one typically would lower the MTU/MSS of the VPNd connections, so that each originating IP packets translates into one outgoing packet.

so I don’t know the exact overhead here ... and didn't found the keyword either.

4) Final question, you really have a PTM using link with only 10/1 Mbps? The slowest PTM links I have heard of are 16/1Mbps VDSL@ fallbacks for users with non-vectoring capable modems on a vectoring enabled DSLAM/MSAN. Typically in that speed range users get ATM-based adsl links. Now, in theory it is possible to use PTM on an ATM link (after all PTM is described in an Annex to the ADSL2 standard by ITU) but I have never heard that being actually implemented in the real world, so I am really curious to learn more about your actual link. If you please could elaborate a bit I would be quite happy. This is actually a 16/1 Mbit/s VDSL

Okay so VDSL16 it is, a rare beast ;) but then PTM is the right encapsulation, please note that you need to reduce modem reported sync bandwidths by at least 100-100*64/65 = 1.538% to account for the PTM encapsulation (but 9.5 of 16 i sway below that threshold).

with a very low latency of 8 ms to the nearst peers in the internet. So it’s just a bit crappy You’ll get just 600 - 650 kbit/s up and 9.5 to 11.2 down,

How did you measure? At VDSL16 you should expect around 16 * ((1452/1526) * (64/65)) = 14.9898981752 Mbps TCP/IPv4 goodput. If you measure through the UDP tunnel it will be less, but 9.5 seems way too little (note I have no experience with openvpn, so it might be just as expected)

so I just selected 10 to get enough headroom here, but today I reduced it again to 9.5 because it was bad today.

This is not as it is supposed to be, is the DSLAM overbooked or are you having real stability issues on that line? (What do the FEC, CRC. ES, SES error counters report for say a 1 hour interval?)

Some days ago this was actually a adsl link with around 60 ms ping, but they (Telekom) just install fiber to the curb, 100 meteres away, and switched to vdsl.

Okay, at 100m you should not see any problems with signal quality at VDSL16… and with a new FTTC MSAN I would not expect over subscription issues, maybe you need to to issue a Stoerungsmeldung?

We expect to get in September vdsl with vectoring 100/40 Mbit at this location.

That is probably going to improve things a bit ;)

Best Regards Sebastian

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Ah, so its just remote desktop sessions over the VPN? What else is being send over ppp0? Software-Update via HTTP for the ThinClients and some other VPN-Sessions for the Free WiFi (Freifunk). But we tag all of this as background-service except DNS and SSH.

This is great, it also means you might want to try dual-scrhost and dual-dsthost to also flow fairness per internal IP on the VPN. Or maybe even triple-isolate which tries to be fair to both sides… This is just 1:N traffic, 1 Terminal-Server to N Clients

Wheres the difference between srchost and dual-srchost?

2) For fun, what happens if you only instantiate one of the shapers, and send test traffic over the according interface, do you still see the bandwidth reduction? Have to test it out, since I’m not at this customer at the moment this have to wait a bit, sorry.

Okay.

I thought about that, actually I just test the ppp0 Shaping via Speedtest and just looked at the tun0 traffic via nload to discover that it will nearly fully utilize the bandwidth of the ppp0.

Okay so VDSL16 it is, a rare beast ;) but then PTM is the right encapsulation, please note that you need to reduce modem reported sync bandwidths by at least 100-100*64/65 = 1.538% to account for the PTM encapsulation (but 9.5 of 16 i sway below that threshold).

I'm just testing it with traffic, sending bursts over the line and look at the ping, if it s increasing over 100ms my shaping is to low & reducing it a bit.

How did you measure? At VDSL16 you should expect around 16 * ((1452/1526) * (64/65)) = 14.9898981752 Mbps TCP/IPv4 goodput. If you measure through the UDP tunnel it will be less, but 9.5 seems way too little (note I have no experience with openvpn, so it might be just as expected)

The syncing of the modem is 14116 down and 1168 up. But we just get 9500 kbit down and 650 kbit up, so our shaping is currently 600 kbit up and 9500 kbit down for ppp0. I've tested this via iperf tcp - speedtest.net shows nearly the same values. The bandwidth for tun0 is not that imported, so I've reduced it a bit more than usually needed just to be sure that the tun0 is shaped and not the same packages in ppp0. :)

This is not as it is supposed to be, is the DSLAM overbooked or are you having real stability issues on that line? (What do the FEC, CRC. ES, SES error counters report for say a 1 hour interval?)

I don't know, because we use a modem via pppoe never looked at the webpage of this modem. Actually I just want to get rid of this connection, so we just ordered a dsl/lte-hybrid connection which should be fine until in September the VDSL 100/40 with vectoring is available.

Okay, at 100m you should not see any problems with signal quality at VDSL16… and with a new FTTC MSAN I would not expect over subscription issues, maybe you need to to issue a Stoerungsmeldung?

Currently at this place is only a patchfield, in september they switch over to a DSLAM at this location an we'll get VDSL100/40 Vectoring.

Best regards

Ruben

Hi Ruben,

On Jun 28, 2016, at 10:48 , @RubenKelevra notifications@github.com wrote:

Ah, so its just remote desktop sessions over the VPN? What else is being send over ppp0? Software-Update via HTTP for the ThinClients and some other VPN-Sessions for the Free WiFi (Freifunk). But we tag all of this as background-service except DNS and SSH.

Ah, I guess I begin to understand the remote sessions really are the meat of your traffic and the rest is just an add-on.

This is great, it also means you might want to try dual-scrhost and dual-dsthost to also flow fairness per internal IP on the VPN. Or maybe even triple-isolate which tries to be fair to both sides… This is just 1:N traffic, 1 Terminal-Server to N Clients

Okay, so where does the server live, at this specific client or somewhere else? As I understand there is a terminal server at a remote site and the installation in question is connecting several thin clients to that server. How well is the terminal server connected to the network?

Wheres the difference between srchost and dual-srchost?

As far as I understand both look at the source IP field in IP packages, srchost will create a single codel-like queue for all packets originating from a single src IP (on ingress the source IP is fro the remote host, on egress the source IP is from your internal machines). Cake will try to give each source IP an equal share of the bandwidth. dual-srchost is similar in that it will enforce per-source-IP fairness, but it will also still use a queue per flow of each of the source IPs, so will try to treat each flow fair as well. If your thin clients only ever use a single flow/ a few flows srchost will be almost indistinguishable from dual-srchost, but if each client uses multiple flows dual-srchost promises to perform better.

2) For fun, what happens if you only instantiate one of the shapers, and send test traffic over the according interface, do you still see the bandwidth reduction? Have to test it out, since I’m not at this customer at the moment this have to wait a bit, sorry.

Okay.

I thought about that, actually I just test the ppp0 Shaping via Speedtest and just looked at the tun0 traffic via nload to discover that it will nearly fully utilize the bandwidth of the ppp0.

Okay, so your symptom of 50% under-shaping does not occur for single cake instance then, so the bandwidth must be lost by the interplay from both cakes. Could you get captures from both tun0 and ppp0 simultaneously when you speedtest the VPN (try to measure against your terminal server). I wonder whether openvpn somehow drags in too much overhead in that situation.
    BTW, in your proposed solution of simply configuring cake for real_desired_shaper_bandwidth*2 did you need to apply this trick to both cake instances or only to the tun0 or ppp0 one?

Okay so VDSL16 it is, a rare beast ;) but then PTM is the right encapsulation, please note that you need to reduce modem reported sync bandwidths by at least 100-100*64/65 = 1.538% to account for the PTM encapsulation (but 9.5 of 16 i sway below that threshold).

I'm just testing it with traffic, sending bursts over the line and look at the ping, if it s increasing over 100ms my shaping is to low & reducing it a bit.

Good point, real data always beats theoretical bandwidth calculations.

How did you measure? At VDSL16 you should expect around 16 * ((1452/1526) * (64/65)) = 14.9898981752 Mbps TCP/IPv4 goodput. If you measure through the UDP tunnel it will be less, but 9.5 seems way too little (note I have no experience with openvpn, so it might be just as expected)

The syncing of the modem is 14116 down and 1168 up.

Okay, as I see below that pretty much means you are not 100m from the DSLAM/MSAN, at 14116 you can maximally expect 14.116 * ((1452/1526) * (64/65)) = 13.22 Mbps TCP/IPv4 goodput.

But we just get 9500 kbit down and 650 kbit up, so our shaping is currently 600 kbit up and 9500 kbit down for ppp0. I've tested this via iperf tcp - speedtest.net shows nearly the same values. The bandwidth for tun0 is not that imported, so I’ve reduced it a bit more than usually needed just to be sure that the tun0 is shaped and not the same packages in ppp0. :)

Fair enough if absolute bandwidth is not that important, sacrificing a bit more will make keeping the latency under load low easier.

This is not as it is supposed to be, is the DSLAM overbooked or are you having real stability issues on that line? (What do the FEC, CRC. ES, SES error counters report for say a 1 hour interval?) Actually I don’t know, because we use a modem via pppoe never looked at the webpage of this modem. Actually I just want to get rid of this connection, so we just ordered a dsl/lte-hybrid connection which should be fine until in September the VDSL 100/40 with vectoring is available.

Okay, at 100m you should not see any problems with signal quality at VDSL16… and with a new FTTC MSAN I would not expect over subscription issues, maybe you need to to issue a Stoerungsmeldung? Currently at this place is only a patchfield, in september they switch over to a DSLAM at this location an we’ll get VDSL100/40 Vectoring.

Ah, as noted above then the Stoerungsmeldung is moot, most likely you are a long way from the central office (Vermittlungsstelle) and hence only get low bandwidth. Typically DTAG will only allow VDSL16 if one books “entertain” iptv with it, but maybe this is different for business customers…

Best regards

Ruben

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Ah, I guess I begin to understand the remote sessions really are the meat of your traffic and the rest is just an add-on.

Basically yep, it's a complete cloud-based environment, so there are only thin clients, system phones and some printers locally.

As far as I understand both look at the source IP field in IP packages, srchost will create a single codel-like queue for all packets originating from a single src IP (on ingress the source IP is fro the remote host, on egress the source IP is from your internal machines). Cake will try to give each source IP an equal share of the bandwidth. dual-srchost is similar in that it will enforce per-source-IP fairness, but it will also still use a queue per flow of each of the source IPs, so will try to treat each flow fair as well. If your thin clients only ever use a single flow/ a few flows srchost will be almost indistinguishable from dual-srchost, but if each client uses multiple flows dual-srchost promises to perform better.

So srchost looks fairer to me in this environment, because everybody should get enouth thruput without any penalty by someone which might need some more connections. Currently we do some smb from some hosts, which might use more than one connection. This shouldn't decrease the fairness calculation of bandwidth of each participant.

Okay, so your symptom of 50% under-shaping does not occur for single cake instance then, so the bandwidth must be lost by the interplay from both cakes. Could you get captures from both tun0 and ppp0 simultaneously when you speedtest the VPN (try to measure against your terminal server). I wonder whether openvpn somehow drags in too much overhead in that situation. BTW, in your proposed solution of simply configuring cake for real_desired_shaper_bandwidth*2 did you need to apply this trick to both cake instances or only to the tun0 or ppp0 one?

Currently I've just multiply the overall bandwidth-input by 1.95 than 0.975 to fix this bug.

I think I gonna take a test-router with me at the weekend and do some testing-stuff with gigabit traffic-generators. This is also a nice test for cake as well, so if you like me to do some different tests - feel free. :)

I think the production-environment is not the right test bed for finding this bug.

Okay, as I see below that pretty much means you are not 100m from the DSLAM/MSAN, at 14116 you can maximally expect 14.116 * ((1452/1526) * (64/65)) = 13.22 Mbps TCP/IPv4 goodput.

Don't know where the 3 Mbit are gonna lost but the most time we didn't reach 11 Mbit... Overall the available bandwidth is pretty unstable and it's starting to buffer at DSLAM side if I go above 9.5 Mbit.

Fair enough if absolute bandwidth is not that important, sacrificing a bit more will make keeping the latency under load low easier.

Currently RDP seems pretty slow on loading larger screen-updates, I think we try to change the settings to remote-fx with video-compression, which might look bad - so the jpg approach than the gif/png one, but should be a bit faster.

The DTAG just deferred the LTE/DSL-Hybrid connection today, so we need to fix this with a different approach for now.

Ah, as noted above then the Stoerungsmeldung is moot, most likely you are a long way from the central office (Vermittlungsstelle) and hence only get low bandwidth. Typically DTAG will only allow VDSL16 if one books “entertain” iptv with it, but maybe this is different for business customers…

Yep this is a dual-line ISDN/DSL connection which seems to be Annex.b VDSL based. We use currently just one DSL-Line actively for production envoirment, the second one is currently unused. We plan to do load balancing on connection-level on this one.

Best regards

Hallo Ruben,

On Jun 29, 2016, at 01:10 , @RubenKelevra notifications@github.com wrote:

Ah, I guess I begin to understand the remote sessions really are the meat of your traffic and the rest is just an add-on. Basically yep, it’s a complete cloud-based environment, so there are only thin clients, system phones and some printers locally.

From a centralized control perspective a nice setup.

As far as I understand both look at the source IP field in IP packages, srchost will create a single codel-like queue for all packets originating from a single src IP (on ingress the source IP is fro the remote host, on egress the source IP is from your internal machines). Cake will try to give each source IP an equal share of the bandwidth. dual-srchost is similar in that it will enforce per-source-IP fairness, but it will also still use a queue per flow of each of the source IPs, so will try to treat each flow fair as well. If your thin clients only ever use a single flow/ a few flows srchost will be almost indistinguishable from dual-srchost, but if each client uses multiple flows dual-srchost promises to perform better.

So srchost looks fairer to me in this environment, because everybody should get enouth thruput without any penalty by someone which might need some more connections.

But dual-srchost basically guarantees the same fairness as srchost, but in addition will give per-flow fairness for each internal clients traffic.

Currently we do some smb from some hosts, which might use more than one connection.

And dual-srchost promises to treat these multiple flows per client fairly with each other…

This shouldn’t decrease the fairness calculation of bandwidth of each participant.

…while still maintaining overall per internal client IP fairness. In case you should give it a try, I would be delighted if you could post your observations to this list.

Okay, so your symptom of 50% under-shaping does not occur for single cake instance then, so the bandwidth must be lost by the interplay from both cakes. Could you get captures from both tun0 and ppp0 simultaneously when you speedtest the VPN (try to measure against your terminal server). I wonder whether openvpn somehow drags in too much overhead in that situation. BTW, in your proposed solution of simply configuring cake for real_desired_shaper_bandwidth*2 did you need to apply this trick to both cake instances or only to the tun0 or ppp0 one?

Currently I’ve just multiply the overall bandwidth-input by 1.95 than 0.975 to fix this bug.

But is it really a bug? I wonder what exactly drives this behavior.

I think I gonna take a test-router with me at the weekend and do some testing-stuff with gigabit traffic-generators. This is also a nice test for cake as well, so if you like me to do some different tests - feel free. :)

I think the production-environment is not the right test bed for finding this bug.

Oops, you are right ;)

Okay, as I see below that pretty much means you are not 100m from the DSLAM/MSAN, at 14116 you can maximally expect 14.116 * ((1452/1526) * (64/65)) = 13.22 Mbps TCP/IPv4 goodput.

Don’t know where the 3 Mbit are gonna lost but the most time we didn't reach 11 Mbit...

Where do you test against? DTAG is known/notorious for under-peering with transit-providers to encourage transit customers to buy direct access to the DTAG network; since your traffic most likely is active during the day, this under-peering should not be your issue though (this mostly seems to manifest around the evening hours when home users start their on-line activities).

Overall the available bandwidth is pretty unstable and it’s starting to buffer at DSLAM side if I go above 9.5 Mbit.

That is quite annoying, but there are two potential bottlenecks, one is your actual TAL-link to the DSLAM and then the DSLAM buffers, or worse the aggregation network upstream of the DSLAM if the DSLAM is overbooked and its uplink is the congested component. From your perspective they are pretty much identical in symptoms (just the bad line might be fixable by using a different wire pair from the DSLAM or by switching you to a different vdsl port on the dslam, while the dslam’s uplink will be handled eventually by DTAG’s VVDSL rollout)

Fair enough if absolute bandwidth is not that important, sacrificing a bit more will make keeping the latency under load low easier.

Currently RDP seems pretty slow on loading larger screen-updates, I think we try to change the settings to remote-fx with video-compression, which might look bad - so the jpg approach than the gif/png one, but should be a bit faster.

So from my personal experience, the only thing that worked well enough were windows remote desktop and especially NX server for me (linux server with macosx/windows clients) all other VNC style things were just abysmally laggy…

The DTAG just deferred the LTE/DSL-Hybrid connection today, so we need to fix this with a different approach for now.

Then I would start looking at the errors on the line and re-consider the Stoerungsmeldung if errors are excessive, if you have a business contract have a look at your SLA to figure out which level of bandwidth loss and errors are considered acceptable…

Ah, as noted above then the Stoerungsmeldung is moot, most likely you are a long way from the central office (Vermittlungsstelle) and hence only get low bandwidth. Typically DTAG will only allow VDSL16 if one books “entertain” iptv with it, but maybe this is different for business customers…

Yep this is a dual-line ISDN/DSL connection which seems to be Annex.b VDSL based.

Yes, but VDSL @ DTAG is always Annex B (but the annexes have different meanings for VDSL and ADSL links, since they refer to different documents so ADSL Annex B is not equal to VDSL2 Annex B, for VDSL the relevant part are the bandplans).

We use currently just one DSL-Line actively for production envoirment, the second one is currently unused. We plan to do load balancing on connection-level on this one.

Good idea, if you only have few remote sites you could also opt for bonding and terminate the bond at the cloud servers, but given your flaky link that will not be much fun..

Best Regards Sebastian

Best regards

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Is this issue still open?

I cannot confirm this issue anymore, I don't use sch_cake atm in a new production envoirment. The old installations work still fine.

we had api breakage for a few weeks. Let us know if it breaks when you try again?

dtaht / sch_cake

Limiter does not calc right on ingress devices #28