[Cake] New to cake. Some questions
Benjamin Cronce
bcronce at gmail.com
Fri Jun 10 18:01:46 EDT 2016
At least you ISP's trunk seems decent
ping -t 109.90.28.1
Packets: sent=150, rcvd=150, error=0, lost=0 (0.0% loss) in 74.660177 sec
RTTs in ms: min/avg/max/dev: 158.255 / 159.140 / 161.922 / 0.528
Bandwidth in kbytes/sec: sent=0.120, rcvd=0.120
On Fri, Jun 10, 2016 at 9:05 AM, Dennis Fedtke <dennisfedtke at gmail.com>
wrote:
> Hi Sebastian,
>
> yes this is wired connection. As i stated my ping times always vary
> independently of target.
> My ISP is overloaded in certain regions. So i assume they do some
> shaping/limiting on certain protocols (icmp for example)
> Connection speed is 200/20 Mbit.
> ISP is unitymedia which doesn't allow you to use your own hardware.
> So actually i have to run my router behind theirs with exposed host
> enabled :<
>
> Ping response:
>
> ping -s 1400 -c 1 109.90.x.x
> PING 109.90.28.1 (109.90.28.1) 1400(1428) bytes of data.
> 1408 bytes from 109.90.28.1: icmp_seq=1 ttl=253 time=11.6 ms
>
> --- 109.90.28.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 11.677/11.677/11.677/0.000 ms
>
> This looks good or?
>
> Yes i am from germany. So you are from germany too?
>
> Thanks for your time and help :)
>
>
> Best regards
> Dennis
>
>
> Am 10.06.2016 um 15:02 schrieb moeller0:
>
>> Hi Dennis,
>>
>> On Jun 10, 2016, at 14:43 , Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>>>
>>> Hi Sebastian,
>>>
>>> i used the default setting of 1000.
>>>
>> Okay, that should work i assume unless you have a very fast link…
>> What link at what ISP do you actually have?
>>
>> But it seems that my isp is dropping icmp packets if there are exceeding
>>> some sending threshold.
>>>
>> I would be amazed if they did, a sympotom of that would be rsate
>> reduction to all ICMP probe flows independent of target host. If however
>> you only see this with specific hosts it is very likely that that host rate
>> limits its ICMP responses. In either case try another host further
>> upstream. II think I has reasonable decent results with targeting 8.8.8.8,
>> googles dns servers.
>>
>> So there is a lot of none usable ping data.
>>>
>> Again, try another host…
>>
>> I increased the send delay to 50ms. 25 ms already shows dropped requests.
>>>
>> That might also help, as long as you stay below their throttling
>> rate the chosen host might still work okay.
>>
>> This is the third run now. Waiting for completion.
>>>
>> Well, sorry that the method is not as slick and streamlined, but
>> there are no guarded good ICMP reflectors available on the net.
>>
>> The ping target is my first hop.
>>>
>> Try the next hop then ;)
>>
>> Actually my ping always varies around +-5ms even at idle and
>>> independently of ping target.
>>>
>> This is via wifi/wlan? If so try from a wired connection instead.
>>
>> When i look through the ping file the increase in ping times are actually
>>> appear to be random to me.
>>>
>> Well, we expect variability of the individual “trials” to exist,
>> that is why we collect so many and try to select the best measure in the
>> matlab code to remove the unwanted variance. Could you post a link to both
>> of the generated plots please, the first one showing te different
>> aggregation measures might be helpful in diagnosing the issues deeper.
>>
>> So how to test if my isp responses with fixed icmp packet size?
>>>
>> You could try manually. In the folloewing example I pinged
>> gstatic.com (which belongs to googles CDN as far as I know):
>>
>> bash-3.2$ ping -s 1 -c 1 gstatic.com
>> PING gstatic.com (216.58.213.195): 1 data bytes
>> 9 bytes from 216.58.213.195: icmp_seq=0 ttl=55
>>
>> --- gstatic.com ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>>
>>
>> bash-3.2$ ping -s 64 -c 1 gstatic.com
>> PING gstatic.com (216.58.213.195): 64 data bytes
>> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=19.446 ms
>>
>> --- gstatic.com ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 19.446/19.446/19.446/0.000 ms
>>
>>
>> bash-3.2$ ping -s 65 -c 1 gstatic.com
>> PING gstatic.com (216.58.213.195): 65 data bytes
>> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=21.138 ms
>> wrong total length 92 instead of 93
>>
>> --- gstatic.com ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 21.138/21.138/21.138/0.000 ms
>> bash-3.2$
>>
>>
>> bash-3.2$ ping -s 1400 -c 1 gstatic.com
>> PING gstatic.com (216.58.213.195): 1400 data bytes
>> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=6.878 ms
>> wrong total length 92 instead of 1428
>>
>> --- gstatic.com ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 6.878/6.878/6.878/0.000 ms
>>
>> Once I try to send 65 Bytes of ICMP payload the response is cut short to
>> 92 bytes, the same might happen with your isp. But also if all your ISP
>> does is rate limiting the ICMP packests that still can lead to to much
>> variance in the RTTs…
>>
>>
>> Im in central europe too :D
>>>
>> Ah, then you just have a different work/sleep cycle than I do ;).
>> Where in central Europe, if I might as Ii am, as you might have guessed
>> based in Germany…
>>
>> Best Regards
>> Sebastian
>>
>> Thanks :)
>>>
>>>
>>> Am 10.06.2016 um 07:20 schrieb moeller0:
>>>
>>>> Hi Dennis,
>>>>
>>>>
>>>> On Jun 10, 2016, at 02:49 , Dennis Fedtke <dennisfedtke at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Sebastian,
>>>>>
>>>>> Sorry this is positive or?
>>>>>
>>>> I would say that is unclear…
>>>>
>>>> But i need more samples ?
>>>>>
>>>> I would try with more samples, after checking that the ping
>>>> times in the recorded data file actually are larger for larger probes than
>>>> for smaller, some hosts will reply with a fixed maximum ICMP packet instead
>>>> of returning the received packet, thereby reducing the signal range (as
>>>> only the upload leg of the link is meaning fully contributing useful
>>>> differential signal.
>>>> BTW I am in central europe so at times of the day my responses
>>>> can be very sporadic, as I either am at work or sleeping ;)
>>>>
>>>> Best Regards
>>>> Sebastian
>>>>
>>>> Thanks :)
>>>>>
>>>>>
>>>>> Am 10.06.2016 um 01:11 schrieb moeller0:
>>>>>
>>>>>> Hi Dennis,
>>>>>>
>>>>>> On Jun 10, 2016, at 00:45 , Dennis Fedtke <dennisfedtke at 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
>>>>>> Sebastian
>>>>>>
>>>>>> Thank 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 <dennisfedtke at 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 at lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/cake
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> Cake mailing list
>>>>>>> Cake at lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/cake
>>>>>>>
>>>>>>
>>>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20160610/22d51e36/attachment-0001.html>
More information about the Cake
mailing list