From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from web.heavenlysanctuary.com (web.heavenlysanctuary.com [74.80.207.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BC6363B2A4 for ; Sun, 22 Sep 2019 23:36:59 -0400 (EDT) Received: from [192.168.10.101] (unknown [47.145.169.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by web.heavenlysanctuary.com (Postfix) with ESMTPSA id C0C6121E00A2 for ; Sun, 22 Sep 2019 20:36:58 -0700 (PDT) To: cake@lists.bufferbloat.net Reply-To: marco@heavenlysanctuary.com From: Marco Belmonte Message-ID: Date: Sun, 22 Sep 2019 20:37:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Thunderbird/70.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED, NO_DNS_FOR_FROM, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on web.heavenlysanctuary.com Subject: [Cake] Frontier FIOS Framing 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: Mon, 23 Sep 2019 03:36:59 -0000 Esteemed Colleagues, Researchers and Noobs (the category I fall under), I have searched every nook and cranny of the bloated internet looking for any information I can find on whether Frontier/Verizon FIOS (assuming the only difference between the service offered by both Frontier and Verizon is in name only) requires any special framing parameters passed on to sch_cake's overhead settings. Most mentions of cake/fq/scm/etc and FIOS are ether very dated and inconclusive or I find messages and forum posts asking questions a lot like this one. Currently this is what I have and am also curious if I should be using the "nat" keyword for both ingress and egress? I'm not entirely sure - see below: --- CUT HERE --- # BufferBarf.sh cpupower frequency-set -g performance cpupower idle-set -D 0 sysctl -w net.core.default_qdisc=fq sysctl -w net.ipv4.tcp_congestion_control=bbr sysctl -w net.ipv4.tcp_ecn=1 sysctl -w net.ipv4.tcp_sack = 1 sysctl -w net.ipv4.tcp_dsack = 1ethtool -A eth1 autoneg off rx off tx off ethtool -A eth2 autoneg off rx off tx off ethtool -K eth1 tso off gso off gro off rx off tx off sg off rxvlan off txvlan off \                 rx-vlan-filter off rxhash off tx-esp-segmentation off tx-gso-partial off \                 esp-hw-offload off esp-tx-csum-hw-offload on rx-udp_tunnel-port-offload off ntuple off ethtool -K eth2 rx off tx off sg off tso off gso off gro off rxvlan off txvlan off rxhash off \                 hw-tc-offload off tx-gre-segmentation off tx-gre-csum-segmentation off \                 tx-ipxip4-segmentation off tx-ipxip6-segmentation off tx-udp_tnl-segmentation off \                 tx-udp_tnl-csum-segmentation off tx-gso-partial off ntuple off ethtool -L eth1 combined 4 ethtool -L eth2 combined 4 ethtool -C eth1 rx-usecs 0 tx-usecs 0 ethtool -C eth2 rx-usecs 0 tx-usecs 0 /usr/sbin/network-irq-affinity  # custom script that pins four RSS queues from eth1 to there own IRQs and four RSS queues from eth2 to their own with no overlapping of cores. ### egress tc qdisc add dev eth2 root cake bandwidth 450mbit nat ### ingress ip link add name ifb4eth2 type ifb tc qdisc add dev eth2 handle ffff: ingress tc qdisc add dev ifb4eth2 root cake bandwidth 450mbit nat ip link set ifb4eth2 up tc filter add dev eth2 parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4eth2 --- CUT HERE --- eth1 is 1 Gbit LAN, eth2 is 500/500 mbit fiber In absence of framing compensation I figured I should just go extreme by reserving more bandwidth than the qdisc needs because I also read somewhere I think that mentioned that if you don't compensate and are incorrect everything stops working as opposed to if you over compensate you might lose out on bandwidth but you'll still win in the latency department. But now that I type this out I just realized I think the compensation was referring to using the "mpu " option... This would also substantiate my initial greeting announcing my noob status. Any help would be appreciated and thanks in advance! Marco