From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 5C2563B25E for ; Fri, 10 Jun 2016 18:01:48 -0400 (EDT) Received: by mail-oi0-x233.google.com with SMTP id d132so28748755oig.1 for ; Fri, 10 Jun 2016 15:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rbRXkE4RMqwocwWdLmkqbE4n3rzS1NfTmStfcO0bLr4=; b=dQE9Z0ej34yBhHF4suFPqoBEMmGZqEUPB+LDd4PPJmgdji/XNjIr1qXQZmPyx5tOg4 +4ndW9bUBy0cGWrnGSoFoirNa3RZUGWVSDoiu8UX31+DS4L+OMmASswSi3wUgVazYfnR wtDHH2R7s2Arlj8+WlhMEOqvaGE7vHEDjvHMgECTWHR84nG2fBYfoNZaK/XtSu8F20u5 y13T9dobHnHHlzpqEH4N8YHhGawhBusnP6vPBBCspwftM6OeYCnHoycha61DBSyDhzPj 5+bIFMDs0iDpvyPKspvtDOksk5jV0wX4JgVHSYi7ym+07ErgLlOwsem+Cd88Hes9B2W4 lhag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rbRXkE4RMqwocwWdLmkqbE4n3rzS1NfTmStfcO0bLr4=; b=m+ExB/zXz6HzNsj3WhxbKmlRXYVt5kK4g/AvCM+My1mg2MlSoT0cz8MjlO7yiaLZbM jSBYGaNMM48Oy5sARocuwaUHQNHvPTZaUoSENvKg+Vueu4+tgSe1rWwSe90WbczGXII5 0/KIdZTehGDmPezdwgXX+4juDXNTMMZbM7XoWgu+6KOhrHOsto8oN6UggL+RGVThOm2T wvjOi0hhggSONuOpSG+rrY1BsS4wW0xN/ONIs7Bmj/a5igQ3jPrwnKIi2QceB3K6wlXK CylO5CdWHCSAKK7ygNCehzPCErqls34pcPaMVtnRXNxjT1S4PqZQ59rB0OJVORq0f6Nh EShA== X-Gm-Message-State: ALyK8tI+ZxHfoAgaUVzdx4EnHkU79zziRSO9sauTEsF5WOdxEWzdZ7YlAFzTwH3npDSHMmcLpVUDuf0LFlbwtg== X-Received: by 10.202.65.133 with SMTP id o127mr2430546oia.43.1465596107702; Fri, 10 Jun 2016 15:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.16.115 with HTTP; Fri, 10 Jun 2016 15:01:46 -0700 (PDT) In-Reply-To: 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> From: Benjamin Cronce Date: Fri, 10 Jun 2016 17:01:46 -0500 Message-ID: To: Dennis Fedtke Cc: moeller0 , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113dc862624a500534f3af91 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 22:01:48 -0000 --001a113dc862624a500534f3af91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At least you ISP's trunk seems decent ping -t 109.90.28.1 Packets: sent=3D150, rcvd=3D150, error=3D0, lost=3D0 (0.0% loss) in 74.6601= 77 sec RTTs in ms: min/avg/max/dev: 158.255 / 159.140 / 161.922 / 0.528 Bandwidth in kbytes/sec: sent=3D0.120, rcvd=3D0.120 On Fri, Jun 10, 2016 at 9:05 AM, Dennis Fedtke 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=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 wrote= : >>> >>> 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 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 r= ate >> 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=E2=80=A6 >> >> 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 actuall= y >>> 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 measure in the >> matlab code to remove the unwanted variance. Could you post a link to bo= th >> 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=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 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=E2=80=A6 >> >> >> 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=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 >>>>> wrote: >>>>> >>>>> 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 smaller, some hosts will reply with a fixed maximum ICMP packet in= stead >>>> of returning the received packet, thereby reducing the signal range (a= s >>>> 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 >>>>>>> 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 =E2=80=9CEstimated overhe= ad >>>>>> preceding the IP header=E2=80=9D in the top part of the second figur= e 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: = =E2=80=9Catm >>>>>> overhead NN=E2=80=9D >>>>>> >>>>>> 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 scr= ipt >>>>>> 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 not add the 14= bytes >>>>>> for you, so then you would use =E2=80=9Coverhead 44=E2=80=9D (I excl= uded 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 cake >>>>>>> starts to drop udp packets which causes lag ingame. >>>>>>> My idea was to set ingress/egress to diffserv4 and apply the EF dsc= p >>>>>>> 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 u= se >>>>>> 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 scrip= t) >>>>>>> >>>>>> This will affect outgoing packets and might be a good idea i= n >>>>>> your specific case. >>>>>> >>>>>> BUT why don=E2=80=99t you try the default behaviour with specific ru= les and >>>>>> tricks and report success or failure back to us, after all the >>>>>> fastest/easiest classification is one one does not need to perform a= t 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 ca= ke is >>>>>> to set ingress cake to besteffort (basically cake ignores the dscp f= ield >>>>>> 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 dsc= p >>>>>>> fields/marks? >>>>>>> >>>>>> Not exactly, per RFC DSCPs are only ever valid/defined insid= e >>>>>> 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 n= ot like >>>>>> you want them to be (Dave That reported that his ISP re-mapped almos= t 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=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 >>>>>>>> source 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 >>>>>>>>> questions: >>>>>>>>> >>>>>>>>> 1. What is considered the =E2=80=9Coptimal" 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 m= ethod on >>>>>>>> https://github.com/moeller0/ATM_overhead_detector to m\empirically >>>>>>>> measure whether your link uses ATM encapsulation and what exact ov= erhead 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 heade= r; if >>>>>>>> this is greek to you, I guess piece_of_cake most likely is what yo= u 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 packe= ts into 4 >>>>>>>> different priority classes, which is fine if you want that, but ba= d for not >>>>>>>> sanity checked packets coming in from the wider internet (one is n= ot >>>>>>>> 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, indepe= ndent 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=E2=80=A6 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 mo= st likely >>>>>>>> want this requires that cake sees internal IP addresses of your en= d-hosts. >>>>>>>> In the typical configuration with SQM on the WAN interface of a NA= T router >>>>>>>> all internal addresses are replaced with the external IP address o= f 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 and >>>>>>>> dual-dsthost you would need to instantiate SQM on an internal inte= rface >>>>>>>> like LAN. But then the direction of ingress and egress from the ro= uters >>>>>>>> perspective changes with regards to the internet download and uplo= ad >>>>>>>> direction and you will need to put the internet upload bandwidth i= nto the >>>>>>>> download field of the sqm GUI and vice versa. Also SQM on an inter= nal >>>>>>>> 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=E2=80=A6 (I guess you would have preferred a shorter less v= ague response, >>>>>>>> but 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 enabl= e >>>>>>>> diffserv on ingress. But the default assumption should be that you= r >>>>>>>> upstream used a dscp mapping that only makes sense for them and no= t 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=E2=80=A6 >>>>>>>> >>>>>>>> 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 tim= e >>>>>>>> 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 s= acrifice >>>>>>>> bandwidth, if you set this too high you will accumulate more laten= cy under >>>>>>>> load. The good thing seems to be that this does not need to be ter= ribly >>>>>>>> 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=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 >>>>>>> >>>>>> >>> > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --001a113dc862624a500534f3af91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At least you ISP's trunk seems decent

pin= g -t 109.90.28.1

Packets: sent=3D150, rcv= d=3D150, error=3D0, lost=3D0 (0.0% loss) in 74.660177 sec
RTTs in= ms: min/avg/max/dev: 158.255 / 159.140 / 161.922 / 0.528
Bandwid= th in kbytes/sec: sent=3D0.120, rcvd=3D0.120

On Fri, Jun 10, 2016 at = 9:05 AM, Dennis Fedtke <dennisfedtke@gmail.com> wrote:<= br>
Hi Sebastian,

yes this is wired connection. As i stated my ping times always vary indepen= dently of target.
My ISP is overloaded in certain regions. So i assume they do some shaping/l= imiting 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=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 <dennisfedtke@gmail.com> wrote:

Hi Sebastian,

i used the default setting of 1000.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 exceeding so= me sending threshold.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would be amazed if they did, a sympotom of th= at would be rsate reduction to all ICMP probe flows independent of target h= ost. If however you only see this with specific hosts it is very likely tha= t 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.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Again, try another host=E2=80=A6

I increased the send delay to 50ms. 25 ms already shows dropped requests.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Well, sorry that the method is not as slick and= streamlined, but there are no guarded good ICMP reflectors available on th= e net.

The ping target is my first hop.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Try the next hop then ;)

Actually my ping always varies around +-5ms even at idle and independently = of ping target.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is via wifi/wlan? If so try from a wired c= onnection instead.

When i look through the ping file the increase in ping times are actually a= ppear to be random to me.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Well, we expect variability of the individual = =E2=80=9Ctrials=E2=80=9D to exist, that is why we collect so many and try t= o select the best measure in the matlab code to remove the unwanted varianc= e. Could you post a link to both of the generated plots please, the first o= ne 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?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 You could try manually. In the folloewing examp= le 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 gs= tatic.com (216.58.213.195): 1 data bytes
9 bytes from 216.58.213.195: icmp_seq=3D0 ttl=3D55

--- gst= atic.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss


bash-3.2$ ping -s 64 -c 1 gstatic.com
PING gs= tatic.com (216.58.213.195): 64 data bytes
72 bytes from 216.58.213.195: icmp_seq=3D0 ttl=3D55 time=3D19.446 ms

--- gst= atic.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 gs= tatic.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

--- gst= atic.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 gs= tatic.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

--- gst= atic.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 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=E2=80=A6


Im in central europe too :D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ah, then you just have a different work/sleep c= ycle than I do ;). Where in central Europe, if I might as Ii am, as you mig= ht have guessed based in Germany=E2=80=A6

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

Thanks :)


Am 10.06.2016 um 07:20 schrieb moeller0:
Hi Dennis,


On Jun 10, 2016, at 02:49 , Dennis Fedtke <dennisfedtke@gmail.com> wrote:

Hi Sebastian,

Sorry this is positive or?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would say that is unclear=E2=80=A6

But i need more samples ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would try with more samples, after checking t= hat 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 p= acket instead of returning the received packet, thereby reducing the signal= range (as only the upload leg of the link is meaning fully contributing us= eful differential signal.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW I am in central europe so at times of the d= ay my responses can be very sporadic, as I either am at work or sleeping ;)=

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

Thanks :)


Am 10.06.2016 um 01:11 schrieb moeller0:
Hi Dennis,

On Jun 10, 2016, at 00:45 , Dennis Fedtke <dennisfedtke@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?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The relevant number is reported as =E2=80=9CEst= imated overhead preceding the IP header=E2=80=9D in the top part of the sec= ond figure created by the script. But that is only relevant.useful if you s= ee a nice step like plot in figure 2 as well ( the second figure in https://github.com/moeller0/ATM_overhead_detector/wik= i 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?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you use plain cake and you know the numerica= l overhead (NN) the easiest is to add the following to your cake invocation= : =E2=80=9Catm overhead NN=E2=80=9D

Please note that if you use cake on an ethernet interface the kernel will a= lready 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 tha= t. If you use a pppoe interface the kernel will most likely not add the 14 = bytes for you, so then you would use =E2=80=9Coverhead 44=E2=80=9D (I exclu= ded 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 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 o= n those packets.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ell, not a bad idea, but often the problem are = in the incoming traffic, and unfortunately with the ifb we use we can not u= se iptables, but only tc, and remarking with tc is unpleasant.

Will this even work? if yes how to do this? iptables?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 rules and= tricks and report success or failure back to us, after all the fastest/eas= iest 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 scri= pts.
The dscp fields/marks will be overwritten by iptables to 0 (besteffort). (l= ayer cake script)
So then it makes no sense to manually set dscp fields/marks or? (Or even se= tting diffserv)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 No unfortunately on ingress cake sees the packe= ts 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 ne= tworking elements like potentially wifi liknks are not confuzed by the dscp= information.

Did i understand this correctly. Per rfc isps should not provide dscp field= s/marks?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Not exactly, per RFC DSCPs are only ever valid/= defined inside a DSCP domain and your ISPs domain ends before it reaches yo= ur 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-mapp= ed almost 1/3 or so of packets into the CS1 background class). So it is rec= omended that each DSCP domain re-mapps the code points at its entry point, = which in your case is your router=E2=80=A6

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 ca= ke on this mailing list, but I assume the others will chime in if I say som= ething questionable=E2=80=A6

On Jun 9, 2016, at 22:58 , Dennis Fedtke <dennisfedtke@gmail.com> wrote:

Hi

Currently im running lede + cake + sqm_scripts and i have some questions:
1. What is considered the =E2=80=9Coptimal" setup atm for cake?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The same as without cake; really, proper per-pa= cket-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\empi= rically measure whether your link uses ATM encapsulation and what exact ove= rhead is in use.

e.g. which cake script should i use piece or layer cake?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 piece_of_cake has only one tier of priority, wh= ile layer_cake currently offers 4. Packets are put into the different prior= ity 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 lo= oking 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?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This really is an implementation detail that ha= s no immediate effect if you choose piece_of_cake as typically only the bot= tleneck 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 di= fferent priority classes, which is fine if you want that, but bad for not s= anity checked packets coming in from the wider internet (one is not suppose= d to assume incoming packets have sensible dscp markings as per RFC) that i= s why the wash/squash option is missed by some of us, independent of the fa= ct that it was a layering violation).

3. Should i use advanced options in sqm scripts and set triple-isolate + di= ffserv8 ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you understand what these options do and bel= ieve that this is the best for your network go ahead, otherwise=E2=80=A6 Th= e 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 wi= ll most likely want this requires that cake sees internal IP addresses of y= our end-hosts. In the typical configuration with SQM on the WAN interface o= f a NAT router all internal addresses are replaced with the external IP add= ress of the router it self and triple-isolates per host fairness will prett= y much be equal to per flow fairness (not exactly, but in essence). So if y= ou want to try tiple-isolate or its better defined brothers dual-srchost an= d dual-dsthost you would need to instantiate SQM on an internal interface l= ike LAN. But then the direction of ingress and egress from the routers pers= pective changes with regards to the internet download and upload direction = and you will need to put the internet upload bandwidth into the download fi= eld of the sqm GUI and vice versa. Also SQM on an internal interface will a= lso shape internal traffic over the same interface, and that often affects = traffic to and from the wifi/wlan radios to the lan switch=E2=80=A6 (I gues= s you would have preferred a shorter less vague response, but such are the = constraints=E2=80=A6)

4. Is it recommend to enable diffserv on ingress?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you trust/konw/have confirmed that your upst= ream (ISP?) sends you sensible and reasonable DSCP markings by all means en= able diffserv on ingress. But the default assumption should be that your up= stream used a dscp mapping that only makes sense for them and not for you.<= br>
5. Is there still the udp packet dropping problem? e.g. games that are usin= g udp.
If yes does it make sense to apply diffserv classes manually? How to do thi= s?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am not sure what you mean, but if you test th= is 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. Will it be p= ossible to set target ping time?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The last tests did indicate that this feature i= s not ready for primetime at least not on typically fixed bandwidth links a= nd 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 bett= er ping times (because of lower downloadrate uh)?
What happens if rtt is set way higher?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 With the RTT parameter you in essence specify h= ow much time you give the endpoints of a flow to respond to a congestion si= gnal (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 late= ncy under load. The good thing seems to be that this does not need to be te= rribly precise, order of magnitude correctness seems to be sufficient (at l= east in base2)


Thank you!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am sure the real experts will also chime in= =E2=80=A6

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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

--001a113dc862624a500534f3af91--