From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 0BB7C3B2A4 for ; Tue, 5 Sep 2017 02:49:27 -0400 (EDT) Received: by mail-pf0-x22f.google.com with SMTP id m1so5897265pfk.1 for ; Mon, 04 Sep 2017 23:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KBcXqMJcwVhEPLsSllU6BbevlKz0W5FLQCJB27ttzFs=; b=as3j+grW8Q8D3P+XteXhwYq4UIiuBaZKrToOlOLpG/WMqUN7XV4zuStxY7EU9FPpfM ETTFu4qf6/hgMPvkURtmDxa1D0AJzjeFX0qpTbG0fN2EMX9k5K9ExtrYzoEUlt7zskCg uXEDFgfATcFzkrvQnbbcQiCg3YMWCHag4mKxLEzEz3lT9v2CRX8/iw7ptWiXyVelXm6w tawWu1yTeH53xOwMxEnh6jYDJzcwZPwxgfXC8h/aAVBnDh6HnkOdfHa9InYaZhxz9IIW qBVD83147Gc0F/AFmQcMFlIc1T4e9lsD/bSOEHkVZp0+dAevsmjhdhHKcL04QONflmlK iLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KBcXqMJcwVhEPLsSllU6BbevlKz0W5FLQCJB27ttzFs=; b=c0WxHDBU2iEY1xBhF+8nAAkKeNKXaPx4wote1YsjC0SZlAXq/D5aAL+Guj2Geaipmc Dz0zMkSrKs+ReFrN7yDD/QDzqfFFebVC54e5Hl9CVrU/TEzuj9gpPs98f9SJyvtN7kJ6 rxeA3LSz0ncrE6Om0mKqZMu6SnHkSjMZ4HKrQyEUsW2kyFGL5rl2njcM4nmWRDxN6qHR HD8C2N0bPzN1t9SD58GKvHvFbc38jik3XdY9LAxbyeOLvuAlb9QchXKTeKiekuKyvKHN bQQmK45y3WMaBBLlz5tI3zCu5aoiAMH/PJZ4VctWD12StsdCMVtMPUsUYvMvRlnSYvui aQPg== X-Gm-Message-State: AHPjjUjb3zExZInb3PjbJARqOZh/95j9Lx60LDC6XIgBmqAX14ur7KZ0 jth7n2SAoCOddhD23B/VcvdeRjWVcyz8W7YnJA== X-Google-Smtp-Source: ADKCNb65HhoyegKvBh/7g7XbzUz+gt8K3vSWMAIZ3Qi9Fadi3VC3rV6foR+hPTO+sLD+3nPdxQVmSKm5/FMarRr8/gg= X-Received: by 10.84.178.129 with SMTP id z1mr3372587plb.100.1504594167100; Mon, 04 Sep 2017 23:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.189.72 with HTTP; Mon, 4 Sep 2017 23:49:11 -0700 (PDT) X-Originating-IP: [101.166.225.7] In-Reply-To: References: From: Ryan Mounce Date: Tue, 5 Sep 2017 16:19:11 +0930 Message-ID: To: Dennis Fedtke Cc: cake@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" 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: Tue, 05 Sep 2017 06:49:28 -0000 Hi Dennis, Firstly to nitpick, DOCSIS doesn't 'sync' in the traditional xDSL sense and more or less operates at a fixed speed at the physical layer (DOCSIS 3.1 changes this a bit but it is irrelevant to what you're trying to achieve here). The modem and CMTS are typically capable of high speeds however the coax is a shared medium. The actual speed you see as an end user is typically defined by a shaper in the CM / CMTS in order to present the illusion of a reliable fixed speed pipe and to create an artificial model to charge more for higher speeds. So, it depends where and how that "50Mbps" is defined. It is typical for a MSO / cable ISP to actually under-sell and over-deliver on the headline speed, e.g. in my ISP's case advertising "100/2Mbps" on paper, configuring the shapers at 120/2.5Mbps (which is inclusive of 18 bytes overhead and padding for frames smaller than 64 bytes), which then results in real world application layer throughput somewhere between those two values (~114/2.4Mbps on something like speedtest.net in ideal conditions). As far as cake is concerned, 120/2.5 is the important figure here. You want to configure cake with the 'docsis' keyword (equivalent to overhead of 18 bytes on top of IP, and 64 byte MPU inclusive of Ethernet header), and 'bandwidth' that is about 99% of whatever your ISP configures the modem for your plan. The only problem is that you normally can't view what the modem is actually configured for, so you need to do some testing which comes down to trial and error. My technique to configure the upstream rate was to configure cake for a speed slightly above that of my actual connection, continuously ping a nearby server on the internet, and then start a large file upload. The modem's buffer quickly fills up and latency increases until the buffer is full and packets are being dropped. From this point I kept re-configuring cake and slightly reducing the bandwidth until the buffer started to clear and pings slowly returned to baseline. In my case I observed this at 2499Kbps (suggesting that my modem's shaper is configured for precisely 2500Kbps), however I use 2496Kbps as the final value so that the buffer clears slightly faster in case is a 'burp' for whatever reason that fills it. Why is the MPU 64? Good question, that is an Ethernet thing defined in the 70's and inherited by DOCSIS many years later. But yes, this results in a minimum Ethernet payload of 46 bytes. Re: hard_header_len, it's been months since I have dug into the source and I have since forgotten the internal details. I understood it once upon a time, my advise is to not concern yourself with this. What I do remember for sure is that from the user configuration perspective everything is relative to IP packets. It doesn't matter what layer cake 'sees' internally, this is abstracted away from the user in order to present a consistent interface. TL;DR just use the 'docsis' keyword and forget everything you know about overhead and mpu. That's why it's there, so that nobody else ever has to go through the pain I did when fine-tuning cake for my DOCSIS connection. Regards, Ryan Mounce On 5 September 2017 at 15:30, Dennis Fedtke wrote: > Hi Ryan, > > Thanks for you answers. > Lets assume again ethernet over docsis connection at 50 Mbit/s. > So to get 50 Mbit/s ethernet perfomance, the docsis link speed needs to be > set at a higher link speed to compensate for the 18 header ethernet > overhead, or? > or > Assuming: > The docsis link syncs at exactly 50Mbit/s. When cake is set to exactly > 50Mbit/s, it is actually set at a higher speed then the link actually is. > > For mpu why 64? > I assume minimum 46bytes ethernet payload + 18bytes header? > > But why does cake use hard_header_len for the header size which is 14 bytes? > > I don't know how packet sheduler system works, but maybe it is not needed to > include the ethernet header. > > cake does work on ip pakets or? so this is layer3 i think. > the hole thing with ethernet headers is happening in layer2. > This would change the minimum packet size to 46 or? > > Thanks. > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake