From: Andy Furniss <adf.lists@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: "lartc@vger.kernel.org" <lartc@vger.kernel.org>,
Alan Goodman <notifications@yescomputersolutions.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections
Date: Tue, 23 Sep 2014 20:05:52 +0100 [thread overview]
Message-ID: <5421C490.3020104@gmail.com> (raw)
In-Reply-To: <C282AF7E-39FD-4AB6-B079-6DD66AA7EC8C@gmx.de>
Sebastian Moeller wrote:
> Hi Andy,
>
> On Sep 23, 2014, at 17:10 , Andy Furniss <adf.lists@gmail.com>
> 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
next prev parent reply other threads:[~2014-09-23 19:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <541C9527.1070105@yescomputersolutions.com>
[not found] ` <541DA8B5.70701@gmail.com>
2014-09-20 17:55 ` Dave Taht
2014-09-20 22:29 ` Andy Furniss
2014-09-21 18:35 ` Sebastian Moeller
[not found] ` <CAK1m8mPBWyg-sR-ekZGUhsOG-0HoZd3eJ-Q6HJpSLyN-J90kHg@mail.gmail.com>
2014-09-21 21:40 ` Alan Goodman
2014-09-22 9:05 ` Sebastian Moeller
2014-09-22 10:01 ` Andy Furniss
2014-09-22 10:20 ` Sebastian Moeller
2014-09-22 13:09 ` Alan Goodman
2014-09-22 19:52 ` Sebastian Moeller
2014-09-22 23:02 ` Alan Goodman
2014-09-23 9:32 ` Sebastian Moeller
2014-09-23 15:10 ` Andy Furniss
2014-09-23 17:47 ` Sebastian Moeller
2014-09-23 19:05 ` Andy Furniss [this message]
2014-09-23 22:16 ` Sebastian Moeller
2014-09-24 9:17 ` Andy Furniss
2014-09-24 16:23 ` Sebastian Moeller
2014-09-24 22:48 ` Andy Furniss
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5421C490.3020104@gmail.com \
--to=adf.lists@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=lartc@vger.kernel.org \
--cc=moeller0@gmx.de \
--cc=notifications@yescomputersolutions.com \
/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