From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 E24FD3B29E for ; Wed, 6 Sep 2017 03:26:07 -0400 (EDT) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0McR00-1e7A8D2sAC-00HbTG; Wed, 06 Sep 2017 09:26:05 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 6 Sep 2017 09:26:04 +0200 Cc: Dennis Fedtke , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <0D998858-A2FD-4CE3-8B9B-07C6448C8F3B@gmx.de> References: <915b0913-0ac5-c6b6-3771-752a9e41dff2@gmail.com> To: Ryan Mounce X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:svTNFubSnOEcbofArFNFPAWpxxwOs7/qyzZfXr71leYZn65wXll velLy+fYf0jLdrESoeL990YTb9nM58XDZj+2+IKqGM/JtpsTHJNYbu8xuSW7blKGCRxNP+4 LLVGX6BCPKavTJOpDTXILqp4N+sQZsrh1JWrBB1YozH+YBt8mTviwFb9eGJO9ciIrXzKDIA 815JzUtrom2qq1TaPDR8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:ToZssO3HpBw=:gEfF+n/jU9i7SOsyR/ci+c pvk6eik4nLMyy6PlOnKk/YvGFJXP3Y+eTLra2FDswqzwdLbJ6IdQoOR/k8fv+ZWnJ1iVwe6+A zfRDvkixjIsMb7SuYOBfxk1abHgiGgnEsJjH94ig5q0PgCtTmW+BeBFBEoNQUjB3dZAXmLwPu SWoMXb47DiAGUUhdNNcZGWZY5o0ocrDZ/420DcEnXkeixU3qpgUYKPajABBjI6Fa2wkmJw6Wh KFuHCMRyNkGQzEo9TiIJORjtsLWI2dp29/hrpyTMQ1UP3dmtviPZv1bo4Zk1tfHVHt/8V0O7x SUnPHABUQUrF3bUElXagqdFye6LKtZJDVq0YHJRJ/zUauQSI9xdzCZbuccZ+O4n5aqVaDqyem 7O4QhC13tQU9qT2CDzZTOVPXAH91zmqs/ZFdpf/xI6ghgMptdx4QdRwM5946S6YaxljCBWUqq X1dldX/NEe6xp9o0/MkOEQJuSBoC5GaoUBf9T8q2PvOvXOeKbCrB7F57W1W6wWhqHY1IZ8iKz B8faJJjJ/60RzDwOQE7QOzUPyZZGbUiBDkHMe0nk3RmSc8VD6Ds3rX4rgTP3pBZmhIVmlbYHy p6Xfb5pVpqe9xXcwI14jflDKKHJdSJzvlnb660rYCacaQPuH1YCsCSozOBROeEW642q5CVK0x gjsU5oTJYGJzkSftKgurxmBEO0olh2V7Y1C2Dg97wRBlqVW/TxLIae+wIqdKVwKYCh1LZEARy X0hPxDZAZicYSzCLHsb62kU8DCQiUgO3vshf8To+nK4F9jVA4B9E7oIJbjuWnF6orihyzCGGX pjDdT+eMHKerZeN2jLKCGRQ11fAgqfCs0MIZHzZiZVCzK/xCrc= Subject: Re: [Cake] overhead and mpu 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: Wed, 06 Sep 2017 07:26:08 -0000 Hi Ryan, I fully concur ;) > On Sep 6, 2017, at 03:45, Ryan Mounce wrote: >=20 > On 6 September 2017 at 05:49, Dennis Fedtke = wrote: >> Hi! >>=20 >> Thank you for all answers. >> But for me this still makes no sense. >> Assuming we have an ethnernet connection running over a docsis line. >> docsis is able to transmit full 1500byte ethernet packets. >> Lets say it is an 50 Mbit/s Line. (I dont know now how exactly docsis = works) >> So to reach the 50Mbit/s ethernet speed the docsis link rate needs to = be >> higher 50,6 Mbit/s (50*1518/1500 ??) >> But when running a speedtest it will still not show the full speed. = because >> of other overhead from underlying protocols (tcp/ip for example) >> So the ISP will set the sync rate even higher to compensate for that. >>=20 >> But does this matter for the end user? >=20 > There is only one speed that matters for an end user configuring cake. > You need to know the rate of the shaper defined in the CM config file > for your plan, or otherwise determine this rate. As I have said CMs > don't 'sync' in the way you are used to with xDSL so this terminology > isn't really correct, however in terms of being the significant > bottleneck immediately 'upstream' of cake the configured rate of this > shaper is equivalent to the 'sync' speed for xDSL. >=20 > Simply ignore the speed that your ISP advertises, this is a bogus > number for just about every DOCSIS ISP. Also ignore the speed reported > by speedtest.net unless you are confident that there is no other > activity on your link and that you know what TCP options are in use by > your operating system. >=20 > If you get a very consistent result on speedtest.net, it is possible > to estimate the rate of the CMTS's shaper. This is a relationship > between the TCP payload size and full Ethernet frame size. For > example, on an OS that uses TCP timestamps and you get a result of > 100Mbps on speedtest.net the L2 rate may be 100 * (1518 / 1448) ~=3D > 104.8Mbps. > By now you can see where 1518 comes from (1500 bytes Ethernet payload > (IP packet) + 14 bytes Ethernet header + 4 bytes Ethernet FCS). 1448 > is (1500 bytes IP packet (Ethernet payload) - 20 bytes IPv4 header - > 20 bytes TCP header - 12 bytes TCP timestamps option). >=20 > You should use Wireshark to confirm which TCP options and MTU your > system is using with the speedtest.net server and use these values > instead of my above example. Another quick and dirty method to measure the MTU is to use = https://www.speedguide.net/analyzer.php. > Once you have your estimate, round it down a couple of percent. If > your estimate is too high then it will be as if you don't have cake at > all. Too low and cake will still be effective, you will just sacrifice > a small amount of speed. >=20 >> In case of docsis does it make sense to account for 18 overhead? >=20 > Whatever the speed may be, you must always configure 'overhead 18 mpu > 64' or the equivalent 'docsis' keyword to correctly compensate for the > Ethernet framing seen by the shaper in the CM/CMTS, otherwise cake may > underestimate the link utilisation when smaller packets are being sent > and its benefits will be defeated. >=20 >> The user will enter 50mbit and it will work. If the isp has provided = a >> sligher higher syncrate. >=20 > This 50Mbps figure is suspiciously round, where is it actually from? > This is the advertised speed of your plan by the ISP? >=20 >> and the mpu setting. i don't know how cake handles this in detail. >> How the overhead gets added. >> lets i enter mpu 46. >> And cake we set 18 as overhead. >> Will this result in mpu 46 or 64? >> Can someone debug the code maybe please? :> >=20 > This has already been answered and the relevant snippet of code has > been posted. Overhead is first added (relative to IP), and packets > that are still below the MPU *after* the overhead is added will be > rounded up to the MPU of 64. >=20 >> I have the feeling with mpu 46 my pages lot a bit snappier. but could = be >> placebo. >=20 > Correct, this is a placebo. You need to configure 'overhead 18 mpu 64' > or equivalently 'docsis', no ifs no buts. Focus your attention on > estimating the rate of your shaper. The framing compensation for > DOCSIS is a solved problem whereas the rate of a given link varies > from ISP to ISP, and from plan to plan. >=20 >>=20 >> Thank you. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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