Hi Sebastian, thanks again :)
the first 2 pictures arent loading for me in the browser i had to save to hard disk.
here is my results: http://i67.tinypic.com/5cklcg.png I think it is a negativ one? The script gave me following log: Found 45400 ping packets in ping_sweep__20160610_001950.txt Elapsed time is 767.967 seconds. Minimum size of ping payload used: 16 bytes. warning: division by zero warning: legend: ignoring extra labels Unknown or ambiguous terminal name 'wxt' Unknown or ambiguous terminal name 'wxt' Saved figure (5) to: ping_sweep__20160610_001950_data.pnglower bound estimate for one ATM cell RTT based of specified up and downlink is 0.064431 ms. estimate for one ATM cell RTT based on linear fit of the ping sweep data is 0.064431 ms.
Starting brute-force search for optimal stair fit, might take a while... Unknown or ambiguous terminal name 'wxt' Unknown or ambiguous terminal name 'wxt' Best staircase fit cumulative difference is: 25.28 Best linear fit cumulative difference is: 25.787Quantized ATM carrier LIKELY (cummulative residual: stair fit 25.28 linear fit 25.787
remaining ATM cell length after ICMP header is 11 bytes. ICMP RTT of a single ATM cell is 0.059921 ms. Estimated overhead preceding the IP header: 42 bytes Can the errors be ignored ? Best Regards Dennis Am 10.06.2016 um 01:11 schrieb moeller0:
Hi Dennis,On Jun 10, 2016, at 00:45 , Dennis Fedtke <dennisfed...@gmail.com> wrote: Hi Sebastian, thank you for your answers :) The ATM overhead detector script is currently running. I read the wiki about it but im not quite sure how to interpret the plot. I mean what info should i read from it? maximum packet size?The relevant number is reported as “Estimated overhead preceding the IP header” in the top part of the second figure created by the script. But that is only relevant.useful if you see a nice step like plot in figure 2 as well ( the second figure in https://github.com/moeller0/ATM_overhead_detector/wiki as positive and the fourth figure as negative example.If yes do i set the overhead in cake? Or do i set iptables to clamp to new mtu/mss?If you use plain cake and you know the numerical overhead (NN) the easiest is to add the following to your cake invocation: “atm overhead NN” Please note that if you use cake on an ethernet interface the kernel will already account for 14 byte of ethernet overhead, so if the script told you 44 as actual overhead, you use ”overhead 30” to address that. If you use a pppoe interface the kernel will most likely not add the 14 bytes for you, so then you would use “overhead 44” (I excluded the atm option in the last examples for clarity…)Regarding UDP paket dropping problem: I just read some forums and users stated that under heavy load cake starts to drop udp packets which causes lag ingame. My idea was to set ingress/egress to diffserv4 and apply the EF dscp mark on those packets.Ell, not a bad idea, but often the problem are in the incoming traffic, and unfortunately with the ifb we use we can not use iptables, but only tc, and remarking with tc is unpleasant.Will this even work? if yes how to do this? iptables?No, you wuld need tp use tc.ipt -t mangle -A PREROUTING -p udp -m multiport --ports 5000:5500 -j DSCP --set-dscp-class EF Like thia? Is prerouting correct here? (Taken from layer cake script)This will affect outgoing packets and might be a good idea in your specific case. BUT why don’t you try the default behaviour with specific rules and tricks and report success or failure back to us, after all the fastest/easiest classification is one one does not need to perform at all.For the squash and wash feature. Im asking because if i choose to squash in the advanced options of sqm scripts. The dscp fields/marks will be overwritten by iptables to 0 (besteffort). (layer cake script) So then it makes no sense to manually set dscp fields/marks or? (Or even setting diffserv)No unfortunately on ingress cake sees the packets before iptables, so the effective behavioral emulation of wash/squash by cake is to set ingress cake to besteffort (basically cake ignores the dscp field which functionally is identical to all packets having the same value). The squashing by iptables just clears the dscp marls so that internal networking elements like potentially wifi liknks are not confuzed by the dscp information.Did i understand this correctly. Per rfc isps should not provide dscp fields/marks?Not exactly, per RFC DSCPs are only ever valid/defined inside a DSCP domain and your ISPs domain ends before it reaches your CPE. Since you have no control over your ISPs markings, they can be very much not like you want them to be (Dave That reported that his ISP re-mapped almost 1/3 or so of packets into the CS1 background class). So it is recomended that each DSCP domain re-mapps the code points at its entry point, which in your case is your router… Best Regards SebastianThank you. Am 09.06.2016 um 23:30 schrieb moeller0:Hi Dennis, let me start with a disclaimer, I am not the best information source for cake on this mailing list, but I assume the others will chime in if I say something questionable…On Jun 9, 2016, at 22:58 , Dennis Fedtke <dennisfed...@gmail.com> wrote: Hi Currently im running lede + cake + sqm_scripts and i have some questions: 1. What is considered the “optimal" setup atm for cake?The same as without cake; really, proper per-packet-overhead accounting is important for bandwidth shaping, especially for ATM -based links. I would recommend to follow the method on https://github.com/moeller0/ATM_overhead_detector to m\empirically measure whether your link uses ATM encapsulation and what exact overhead is in use.e.g. which cake script should i use piece or layer cake?piece_of_cake has only one tier of priority, while layer_cake currently offers 4. Packets are put into the different priority bands based on the content of their TOS/DSCP filed in the IP header; if this is greek to you, I guess piece_of_cake most likely is what you are looking for..2. Recently squash and wash was removed. But the sqm scripts were not updated. In the advanced options should i set that the dcsp marks are kept?This really is an implementation detail that has no immediate effect if you choose piece_of_cake as typically only the bottleneck is sensitive to DSCP based priority banding. (Typically in that if you are unlucky your WLAN will use the DSCP marks to move packets into 4 different priority classes, which is fine if you want that, but bad for not sanity checked packets coming in from the wider internet (one is not supposed to assume incoming packets have sensible dscp markings as per RFC) that is why the wash/squash option is missed by some of us, independent of the fact that it was a layering violation).3. Should i use advanced options in sqm scripts and set triple-isolate + diffserv8 ?If you understand what these options do and believe that this is the best for your network go ahead, otherwise… The triple-isolate option will try to be fair to host_IP addresses first and then for each hostIP fair to each flow, but for that to do something you will most likely want this requires that cake sees internal IP addresses of your end-hosts. In the typical configuration with SQM on the WAN interface of a NAT router all internal addresses are replaced with the external IP address of the router it self and triple-isolates per host fairness will pretty much be equal to per flow fairness (not exactly, but in essence). So if you want to try tiple-isolate or its better defined brothers dual-srchost and dual-dsthost you would need to instantiate SQM on an internal interface like LAN. But then the direction of ingress and egress from the routers perspective changes with regards to the internet download and upload direction and you will need to put the internet upload bandwidth into the download field of the sqm GUI and vice versa. Also SQM on an internal interface will also shape internal traffic over the same interface, and that often affects traffic to and from the wifi/wlan radios to the lan switch… (I guess you would have preferred a shorter less vague response, but such are the constraints…)4. Is it recommend to enable diffserv on ingress?If you trust/konw/have confirmed that your upstream (ISP?) sends you sensible and reasonable DSCP markings by all means enable diffserv on ingress. But the default assumption should be that your upstream used a dscp mapping that only makes sense for them and not for you.5. Is there still the udp packet dropping problem? e.g. games that are using udp. If yes does it make sense to apply diffserv classes manually? How to do this?I am not sure what you mean, but if you test this and have some findings please report here…6. is the autorate_ingress still under development? This very interesting feature. especially for docsis networks. Will it be possible to set target ping time?The last tests did indicate that this feature is not ready for primetime at least not on typically fixed bandwidth links and I assume docsis links are fixed enough.6. What difference does it make to set a different rtt? Setting lower rtt will reduce download speed i guess but will it allow better ping times (because of lower downloadrate uh)? What happens if rtt is set way higher?With the RTT parameter you in essence specify how much time you give the endpoints of a flow to respond to a congestion signal (ECN marking or packet drop) if you select this way to small you will sacrifice bandwidth, if you set this too high you will accumulate more latency under load. The good thing seems to be that this does not need to be terribly precise, order of magnitude correctness seems to be sufficient (at least in base2)Thank you!I am sure the real experts will also chime in… Best Regards Sebastian_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
