From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 720C03B2A0 for ; Fri, 10 Jun 2016 10:05:15 -0400 (EDT) Received: by mail-wm0-x229.google.com with SMTP id k204so103731424wmk.0 for ; Fri, 10 Jun 2016 07:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1Cne2ZgU6XtQSb9BU8w5IC08QAysH3Z11qW7BgsEM9k=; b=MIFGvoI6BCkGDnhtPi4DN+vNcw3jJBpKXrx1EdRQshYKZNiHGW45r040wedlbeSxGT SMQBq6YIYowc9x5XJgS0qw8vvhKZPsFrm/cvjzS05z8KyhZIMEaCyhnohZCAv5uaKPTK f9cN19WqVbfn6n1iO5sEAHMNOdYO+tFx6VXMQLpRcZ5cRTwvQFWWxUsVEJaMzKIUgGHM tjw52qRoyl5wS73ub8pY9Q+Nlp5JuoLEV2cQNDzXR+Lngm/lxYgHMQ1XxnHjy+W1diIj B1Ft6rbIjlVeV1pxnj26AbxSCfTu3nfO0e27BVxpodpP1/Eup0o9LzpyUZitLEk4nx1r Hs8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1Cne2ZgU6XtQSb9BU8w5IC08QAysH3Z11qW7BgsEM9k=; b=XB9QNc8FY921e1tjpuvA9CSGZVXVTYq9jjA3GkJkSFghftloO9Jzv4kleEJTQPrpLk F9a8AOYLdF3RF3DFjI4VYYrfHvolMN0cFpAytE5YSry8F1D6DO1GAtHVRBtigvSLY0/+ p4tm4nzXzxUY4Sxw7EqwsPsPmt+B5fZNbiCAevn68rYHO+dTB/eKmQybZg4PJs+nKuUo ht24pEMIJ6QGmkLwBDXMF74/3u0Kb4eY5azV3FCvGTy9w6Yu+dDlArREn4w5clvvzTCX yL4vkbxtltM1KZLhW98Yqk5KUBDqm5CrgwoBE4qnoc6hpcetiXHTAODeaceYitY7JJ2b 40rA== X-Gm-Message-State: ALyK8tKHlG8hidT4NBWNV2YA/SM9aEeQn3DPWuHSYecQl2YF6SwvafXTqdQ49044+1tOLw== X-Received: by 10.28.152.130 with SMTP id a124mr18821010wme.98.1465567513213; Fri, 10 Jun 2016 07:05:13 -0700 (PDT) Received: from [192.168.0.1] ([5.147.92.78]) by smtp.gmail.com with ESMTPSA id l4sm27851019wml.21.2016.06.10.07.05.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 07:05:12 -0700 (PDT) References: <7409a52d-8c81-25f0-e070-c7638fdf9d83@gmail.com> <0B4652E3-F061-479D-8BB3-EA0193333A51@gmx.de> <3d4cdbf4-42dd-a371-2d44-f1bad6505684@gmail.com> <735b7505-584f-6c94-2047-110254e73ee8@gmail.com> To: moeller0 Cc: cake@lists.bufferbloat.net From: Dennis Fedtke Message-ID: Date: Fri, 10 Jun 2016 16:05:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] New to cake. Some questions X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:05:15 -0000 Hi Sebastian, yes this is wired connection. As i stated my ping times always vary=20 independently of target. My ISP is overloaded in certain regions. So i assume they do some=20 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=20 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=3D1 ttl=3D253 time=3D11.6 ms --- 109.90.28.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev =3D 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 wro= te: >> >> Hi Sebastian, >> >> i used the default setting of 1000. > Okay, that should work i assume unless you have a very fast link=E2=80= =A6 What link at what ISP do you actually have? > >> But it seems that my isp is dropping icmp packets if there are exceedi= ng some sending threshold. > I would be amazed if they did, a sympotom of that would be rsate reduc= tion to all ICMP probe flows independent of target host. If however you o= nly see this with specific hosts it is very likely that that host rate li= mits its ICMP responses. In either case try another host further upstream= =2E II think I has reasonable decent results with targeting 8.8.8.8, goog= les dns servers. > >> So there is a lot of none usable ping data. > Again, try another host=E2=80=A6 > >> I increased the send delay to 50ms. 25 ms already shows dropped reques= ts. > 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 independe= ntly 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 actua= lly appear to be random to me. > Well, we expect variability of the individual =E2=80=9Ctrials=E2=80=9D= to exist, that is why we collect so many and try to select the best meas= ure 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 diff= erent aggregation measures might be helpful in diagnosing the issues deep= er. > >> 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=3D0 ttl=3D55 > > --- 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=3D0 ttl=3D55 time=3D19.446 ms > > --- gstatic.com ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 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=3D0 ttl=3D55 time=3D21.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 =3D 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=3D0 ttl=3D55 time=3D6.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 =3D 6.878/6.878/6.878/0.000 ms > > Once I try to send 65 Bytes of ICMP payload the response is cut short t= o 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 v= ariance in the RTTs=E2=80=A6 > > >> Im in central europe too :D > Ah, then you just have a different work/sleep cycle than I do ;). Wher= e in central Europe, if I might as Ii am, as you might have guessed based= in Germany=E2=80=A6 > > Best Regards > Sebastian > >> Thanks :) >> >> >> Am 10.06.2016 um 07:20 schrieb moeller0: >>> Hi Dennis, >>> >>> >>>> On Jun 10, 2016, at 02:49 , Dennis Fedtke w= rote: >>>> >>>> Hi Sebastian, >>>> >>>> Sorry this is positive or? >>> I would say that is unclear=E2=80=A6 >>> >>>> 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 sm= aller, 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 differen= tial signal. >>> BTW I am in central europe so at times of the day my responses can b= e 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 = 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 th= e plot. >>>>>> I mean what info should i read from it? maximum packet size? >>>>> The relevant number is reported as =E2=80=9CEstimated overhead pre= ceding the IP header=E2=80=9D in the top part of the second figure create= d 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/m= oeller0/ATM_overhead_detector/wiki as positive and the fourth figure as n= egative example. >>>>> >>>>>> If yes do i set the overhead in cake? Or do i set iptables to clam= p 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: =E2=80=9Catm ov= erhead NN=E2=80=9D >>>>> >>>>> Please note that if you use cake on an ethernet interface the kerne= l will already account for 14 byte of ethernet overhead, so if the script= told you 44 as actual overhead, you use =E2=80=9Doverhead 30=E2=80=9D to= address that. If you use a pppoe interface the kernel will most likely n= ot add the 14 bytes for you, so then you would use =E2=80=9Coverhead 44=E2= =80=9D (I excluded the atm option in the last examples for clarity=E2=80=A6= ) >>>>> >>>>>> Regarding UDP paket dropping problem: >>>>>> I just read some forums and users stated that under heavy load cak= e starts to drop udp packets which causes lag ingame. >>>>>> My idea was to set ingress/egress to diffserv4 and apply the EF ds= cp mark on those packets. >>>>> Ell, not a bad idea, but often the problem are in the incoming tra= ffic, 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 scri= pt) >>>>> This will affect outgoing packets and might be a good idea in your= specific case. >>>>> >>>>> BUT why don=E2=80=99t you try the default behaviour with specific r= ules and tricks and report success or failure back to us, after all the f= astest/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 (bestef= fort). (layer cake script) >>>>>> So then it makes no sense to manually set dscp fields/marks or? (O= r 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 i= ngress cake to besteffort (basically cake ignores the dscp field which fu= nctionally is identical to all packets having the same value). The squash= ing by iptables just clears the dscp marls so that internal networking el= ements like potentially wifi liknks are not confuzed by the dscp informat= ion. >>>>> >>>>>> Did i understand this correctly. Per rfc isps should not provide d= scp fields/marks? >>>>> Not exactly, per RFC DSCPs are only ever valid/defined inside a DS= CP 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 tha= t each DSCP domain re-mapps the code points at its entry point, which in = your case is your router=E2=80=A6 >>>>> >>>>> 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 sou= rce for cake on this mailing list, but I assume the others will chime in = if I say something questionable=E2=80=A6 >>>>>>> >>>>>>>> On Jun 9, 2016, at 22:58 , Dennis Fedtke wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Currently im running lede + cake + sqm_scripts and i have some q= uestions: >>>>>>>> >>>>>>>> 1. What is considered the =E2=80=9Coptimal" setup atm for cake? >>>>>>> The same as without cake; really, proper per-packet-overhead acc= ounting is important for bandwidth shaping, especially for ATM -based lin= ks. I would recommend to follow the method on https://github.com/moeller0= /ATM_overhead_detector to m\empirically measure whether your link uses AT= M 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 cu= rrently 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 gree= k 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 sh= ould i set that the dcsp marks are kept? >>>>>>> This really is an implementation detail that has no immediate ef= fect if you choose piece_of_cake as typically only the bottleneck is sens= itive to DSCP based priority banding. (Typically in that if you are unluc= ky your WLAN will use the DSCP marks to move packets into 4 different pri= ority classes, which is fine if you want that, but bad for not sanity che= cked packets coming in from the wider internet (one is not supposed to as= sume 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-i= solate + diffserv8 ? >>>>>>> If you understand what these options do and believe that this is= the best for your network go ahead, otherwise=E2=80=A6 The triple-isolat= e 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 lik= ely want this requires that cake sees internal IP addresses of your end-h= osts. 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 m= uch be equal to per flow fairness (not exactly, but in essence). So if yo= u want to try tiple-isolate or its better defined brothers dual-srchost a= nd dual-dsthost you would need to instantiate SQM on an internal interfac= e like LAN. But then the direction of ingress and egress from the routers= perspective changes with regards to the internet download and upload dir= ection and you will need to put the internet upload bandwidth into the do= wnload field of the sqm GUI and vice versa. Also SQM on an internal inter= face will also shape internal traffic over the same interface, and that o= ften affects traffic to and from the wifi/wlan radios to the lan switch=E2= =80=A6 (I guess you would have preferred a shorter less vague response, b= ut such are the constraints=E2=80=A6) >>>>>>> >>>>>>>> 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 o= n 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 th= at are using udp. >>>>>>>> If yes does it make sense to apply diffserv classes manually? Ho= w to do this? >>>>>>> I am not sure what you mean, but if you test this and have some = findings please report here=E2=80=A6 >>>>>>> >>>>>>>> 6. is the autorate_ingress still under development? >>>>>>>> This very interesting feature. especially for docsis networks. W= ill it be possible to set target ping time? >>>>>>> The last tests did indicate that this feature is not ready for p= rimetime at least not on typically fixed bandwidth links and I assume doc= sis 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 marki= ng or packet drop) if you select this way to small you will sacrifice ban= dwidth, if you set this too high you will accumulate more latency under l= oad. The good thing seems to be that this does not need to be terribly pr= ecise, order of magnitude correctness seems to be sufficient (at least in= base2) >>>>>>> >>>>>>> >>>>>>>> Thank you! >>>>>>> I am sure the real experts will also chime in=E2=80=A6 >>>>>>> >>>>>>> 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 >>