[Cake] overhead and mpu
moeller0 at gmx.de
Wed Sep 6 03:26:04 EDT 2017
I fully concur ;)
> On Sep 6, 2017, at 03:45, Ryan Mounce <ryan at mounce.com.au> wrote:
> On 6 September 2017 at 05:49, Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>> 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.
>> But does this matter for the end user?
> 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.
> 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.
> 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) ~=
> 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).
> 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.
>> In case of docsis does it make sense to account for 18 overhead?
> 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.
>> The user will enter 50mbit and it will work. If the isp has provided a
>> sligher higher syncrate.
> This 50Mbps figure is suspiciously round, where is it actually from?
> This is the advertised speed of your plan by the ISP?
>> 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? :>
> 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.
>> I have the feeling with mpu 46 my pages lot a bit snappier. but could be
> 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.
>> Thank you.
>> Cake mailing list
>> Cake at lists.bufferbloat.net
> Cake mailing list
> Cake at lists.bufferbloat.net
More information about the Cake