From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 28B1421F298 for ; Tue, 23 Sep 2014 12:05:52 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id fb4so5219918wid.3 for ; Tue, 23 Sep 2014 12:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TWhaX1ApphYs6ata6Od+SRRhTT3z/8wMccFvOgc/9Jk=; b=MiPdml0kuOqNBtrUIYK48Xdn62o4G2sgEAogFUHDXFw9atXg7vmHX2vOPFf/tN5kMJ LrgESPsaBmxLUhQcTvv3i57DnvBUAY5SR3qDb6ENIhdlnGk5LuR5TPKn8SShRkTklODu 14EyVv5dDxC3DTAcjZnoNv9q9xohvbFTeQRzNKuxGi1LfgaOdhGRKBlPzw/KTWku2axp iGBLu8GcibI694liLmFoFk49SqGzbG1hUIQQNoHP1opQskogqah13HN7eAbNwR7Nf9TA zDzABJd2YjNJ0p4NAXkIDnknCHWqJBvcOjBI1U3JvFk9YjiJlRWMlTQAQ+U1pD5aZxc4 wVfQ== X-Received: by 10.194.232.232 with SMTP id tr8mr1887081wjc.21.1411499150744; Tue, 23 Sep 2014 12:05:50 -0700 (PDT) Received: from [192.168.0.3] (27.24.189.80.dyn.plus.net. [80.189.24.27]) by mx.google.com with ESMTPSA id ll20sm3278350wic.14.2014.09.23.12.05.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Sep 2014 12:05:49 -0700 (PDT) Message-ID: <5421C490.3020104@gmail.com> Date: Tue, 23 Sep 2014 20:05:52 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Sebastian Moeller References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> <54201F8B.70408@yescomputersolutions.com> <3136C05A-8069-4F04-B352-69A2BF3578FC@gmx.de> <5420AAA1.70203@yescomputersolutions.com> <54218D48.1020906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "lartc@vger.kernel.org" , Alan Goodman , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 19:06:22 -0000 Sebastian Moeller wrote: > Hi Andy, > > On Sep 23, 2014, at 17:10 , Andy Furniss > wrote: > BUT if you look at the kernel code, stab does not automatically > include the ethernet overhead, so the subtract 14 in the above is > actually wrong. See > http://lxr.free-electrons.com/source/net/sched/sch_api.c#L538 where > “pkt_len = skb->len + stab->szopts.overhead; is used instead of using > “qdisc_skb_cb(skb)->pkt_len” that as filled properly in > http://lxr.free-electrons.com/source/net/core/dev.c#L2705 . At least > to me this clearly looks like the ethernet overhead is not pre-added > when using stab, but I could be wrong. And on an ADSL link you can > see this quite well, with the proper overhead values sqm-scripts > still controls the latency under netperf-wrapper’s RRUL test nicely > even if the shaping rate equals the line rate, with the overhead to > small latency goes down the drain ;) I guess skb->len varies depending on the interface. Anyway here's a quick test on my desktop PC running a git kernel and tc. I used to shape remotely pppoa/vc mux dsl so know that for me ping -s 10 .... = one cell and -s 11 = 2 cells - overhead on IP was 10. Paste time - ph4[/mnt/sda8/Qos/stab-tests]# cat stab-hfsc #set -x TC=/sbin/tc $TC qdisc del dev eth0 root &>/dev/null if [ "$1" = "stop" ] then exit fi $TC qdisc add dev eth0 root handle 1: stab overhead -4 linklayer atm hfsc default ffff $TC class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1kbit ul rate 1kbit $TC qdisc add dev eth0 parent 1:1 pfifo limit 200 $TC class add dev eth0 parent 1:0 classid 1:ffff hfsc sc rate 80mbit ul rate 80mbit $TC filter add dev eth0 parent 1: protocol ip prio 1 \ u32 match ip protocol 1 0xff classid 1:1 ph4[/mnt/sda8/Qos/stab-tests]# ./stab-hfsc ph4[/mnt/sda8/Qos/stab-tests]# ping -s 10 -c 1 noki PING noki.andys.lan (192.168.0.1) 10(38) bytes of data. 18 bytes from noki.andys.lan (192.168.0.1): icmp_req=1 ttl=64 --- noki.andys.lan ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms ph4[/mnt/sda8/Qos/stab-tests]# tc -s qdisc ls dev eth0 qdisc hfsc 1: root refcnt 2 default ffff Sent 106 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc pfifo 8005: parent 1:1 limit 200p Sent 53 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 ph4[/mnt/sda8/Qos/stab-tests]# ./stab-hfsc ph4[/mnt/sda8/Qos/stab-tests]# ping -s 11 -c 1 noki PING noki.andys.lan (192.168.0.1) 11(39) bytes of data. 19 bytes from noki.andys.lan (192.168.0.1): icmp_req=1 ttl=64 --- noki.andys.lan ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms ph4[/mnt/sda8/Qos/stab-tests]# tc -s qdisc ls dev eth0 qdisc hfsc 1: root refcnt 2 default ffff Sent 106 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc pfifo 8006: parent 1:1 limit 200p Sent 106 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 ph4[/mnt/sda8/Qos/stab-tests]# So it seems that overhead -4 is the correct thing to do. I also tested backlogged (-i 0.2) with -s 10 and 11 and tcpdump showed the correct deltas - ph4[/mnt/sda8/Qos/stab-tests]# tcpdump -nnttti eth0 icmp and dst host noki snip 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 92, length 18 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 93, length 18 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 94, length 18 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 95, length 18 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 96, length 18 00:00:00.424001 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 97, length 18 00:00:00.423999 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1345, seq 98, length 18 00:00:00.424000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 1, length 19 00:00:00.848000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 2, length 19 00:00:00.848001 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 3, length 19 00:00:00.847999 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 4, length 19 00:00:00.848000 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 5, length 19 00:00:00.847999 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 6, length 19 00:00:00.848002 IP 192.168.0.3 > 192.168.0.1: ICMP echo request, id 1347, seq 7, length 19