Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Ryan Mounce <ryan@mounce.com.au>
Cc: Dennis Fedtke <dennisfedtke@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] overhead and mpu
Date: Wed, 6 Sep 2017 09:26:04 +0200	[thread overview]
Message-ID: <0D998858-A2FD-4CE3-8B9B-07C6448C8F3B@gmx.de> (raw)
In-Reply-To: <CAN+fvRb4yzYNhC_U10eyRX21N5qRwtWAyi9mDVH5-si+uTTTvQ@mail.gmail.com>

Hi Ryan,

I fully concur ;)


> On Sep 6, 2017, at 03:45, Ryan Mounce <ryan@mounce.com.au> wrote:
> 
> On 6 September 2017 at 05:49, Dennis Fedtke <dennisfedtke@gmail.com> wrote:
>> Hi!
>> 
>> 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) ~=
> 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).
> 
> 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
>> placebo.
> 
> 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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


  reply	other threads:[~2017-09-06  7:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05  2:46 Dennis Fedtke
2017-09-05  3:26 ` Ryan Mounce
2017-09-05  3:37   ` Ryan Mounce
2017-09-05  6:00 ` Dennis Fedtke
2017-09-05  6:49   ` Ryan Mounce
2017-09-05  6:58   ` Jonathan Morton
2017-09-05 20:19     ` Dennis Fedtke
2017-09-06  1:45       ` Ryan Mounce
2017-09-06  7:26         ` Sebastian Moeller [this message]
2017-09-07  4:11           ` Dennis Fedtke
2017-09-07  4:18             ` Dennis Fedtke
2017-09-07  4:25               ` Jonathan Morton
2017-09-07  7:41                 ` Dennis Fedtke
2017-09-07  7:58                 ` Sebastian Moeller
2017-09-07  7:47             ` Sebastian Moeller
2017-09-07  7:58               ` Dennis Fedtke
2017-09-07  8:07                 ` Sebastian Moeller
2017-09-06  7:22       ` Sebastian Moeller
2017-09-05  8:01   ` Sebastian Moeller
2017-09-05  8:35     ` Kevin Darbyshire-Bryant
2017-09-05  8:58       ` Sebastian Moeller
2017-09-05 14:37         ` Ryan Mounce
2017-09-05 15:06           ` Sebastian Moeller
2017-09-05 15:33           ` Kevin Darbyshire-Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0D998858-A2FD-4CE3-8B9B-07C6448C8F3B@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=dennisfedtke@gmail.com \
    --cc=ryan@mounce.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox