* net_sched: precision problem of TBF/HTB @ 2013-07-16 4:12 Yang Yingliang 2013-07-16 4:50 ` Eric Dumazet 0 siblings, 1 reply; 4+ messages in thread From: Yang Yingliang @ 2013-07-16 4:12 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev, David S. Miller Hi, Eric Commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) makes more precise transfer bytes by taking account of headers in qdisc_skb_cb(skb)->pkt_len, but this introduces a problem with calculating bandwidth in userland. When calculating bandwidth in userland, it's not include headers' bytes. From the user's perspective, it's not a correct bandwidth. Shall we need take account of headers in qdisc_skb_cb(skb)->pkt_len or just skb->len? Example: tc qdisc add dev $DEV root handle 1: tbf latency 50ms burst 500kB rate 500mbit mtu 64k iperf -c host -t 30 -i 10 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 571 MBytes 479 Mbits/sec [ 3] 10.0-20.0 sec 570 MBytes 478 Mbits/sec [ 3] 20.0-30.0 sec 570 MBytes 478 Mbits/sec [ 3] 0.0-30.0 sec 1.67 GBytes 478 Mbits/sec ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: net_sched: precision problem of TBF/HTB 2013-07-16 4:12 net_sched: precision problem of TBF/HTB Yang Yingliang @ 2013-07-16 4:50 ` Eric Dumazet 2013-07-17 1:41 ` Ding Tianhong 0 siblings, 1 reply; 4+ messages in thread From: Eric Dumazet @ 2013-07-16 4:50 UTC (permalink / raw) To: Yang Yingliang; +Cc: Eric Dumazet, netdev, David S. Miller On Tue, 2013-07-16 at 12:12 +0800, Yang Yingliang wrote: > Hi, Eric > Commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) > makes more precise transfer bytes by taking account of headers in > qdisc_skb_cb(skb)->pkt_len, but this introduces a problem with > calculating bandwidth in userland. > This changed nothing to userland. > When calculating bandwidth in userland, it's not include headers' > bytes. From the user's perspective, it's not a correct bandwidth. > > Shall we need take account of headers in qdisc_skb_cb(skb)->pkt_len or > just skb->len? > These values are not accessible from userland, unless you capture packets with a sniffer (tcpdump or something like that) > Example: > tc qdisc add dev $DEV root handle 1: tbf latency 50ms burst 500kB rate > 500mbit mtu 64k > > iperf -c host -t 30 -i 10 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 571 MBytes 479 Mbits/sec > [ 3] 10.0-20.0 sec 570 MBytes 478 Mbits/sec > [ 3] 20.0-30.0 sec 570 MBytes 478 Mbits/sec > [ 3] 0.0-30.0 sec 1.67 GBytes 478 Mbits/sec iperf only measures the amount of payload, and probably do not care of headers. You cannot accurately measure bandwidth from userland, unless making assumptions (or getting them from the stack) on header sizes (IP + TCP), MSS value, and retransmits. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: net_sched: precision problem of TBF/HTB 2013-07-16 4:50 ` Eric Dumazet @ 2013-07-17 1:41 ` Ding Tianhong 2013-07-17 3:18 ` John Fastabend 0 siblings, 1 reply; 4+ messages in thread From: Ding Tianhong @ 2013-07-17 1:41 UTC (permalink / raw) To: Eric Dumazet; +Cc: Yang Yingliang, Eric Dumazet, netdev, David S. Miller On 2013/7/16 12:50, Eric Dumazet wrote: > On Tue, 2013-07-16 at 12:12 +0800, Yang Yingliang wrote: >> Hi, Eric >> Commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) >> makes more precise transfer bytes by taking account of headers in >> qdisc_skb_cb(skb)->pkt_len, but this introduces a problem with >> calculating bandwidth in userland. >> > This changed nothing to userland. > >> When calculating bandwidth in userland, it's not include headers' >> bytes. From the user's perspective, it's not a correct bandwidth. >> > > >> Shall we need take account of headers in qdisc_skb_cb(skb)->pkt_len or >> just skb->len? >> > These values are not accessible from userland, unless you capture > packets with a sniffer (tcpdump or something like that) > >> Example: >> tc qdisc add dev $DEV root handle 1: tbf latency 50ms burst 500kB rate >> 500mbit mtu 64k >> >> iperf -c host -t 30 -i 10 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 571 MBytes 479 Mbits/sec >> [ 3] 10.0-20.0 sec 570 MBytes 478 Mbits/sec >> [ 3] 20.0-30.0 sec 570 MBytes 478 Mbits/sec >> [ 3] 0.0-30.0 sec 1.67 GBytes 478 Mbits/sec > > > iperf only measures the amount of payload, and probably do not care of > headers. > > You cannot accurately measure bandwidth from userland, unless making > assumptions (or getting them from the stack) on header sizes (IP + TCP), > MSS value, and retransmits. > > ok, for the further, can you give me some advise for how calculate the bandwidth for net link. for example,what kind of tools is better. > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: net_sched: precision problem of TBF/HTB 2013-07-17 1:41 ` Ding Tianhong @ 2013-07-17 3:18 ` John Fastabend 0 siblings, 0 replies; 4+ messages in thread From: John Fastabend @ 2013-07-17 3:18 UTC (permalink / raw) To: Ding Tianhong Cc: Eric Dumazet, Yang Yingliang, Eric Dumazet, netdev, David S. Miller On 07/16/2013 06:41 PM, Ding Tianhong wrote: > On 2013/7/16 12:50, Eric Dumazet wrote: >> On Tue, 2013-07-16 at 12:12 +0800, Yang Yingliang wrote: >>> Hi, Eric >>> Commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) >>> makes more precise transfer bytes by taking account of headers in >>> qdisc_skb_cb(skb)->pkt_len, but this introduces a problem with >>> calculating bandwidth in userland. >>> >> This changed nothing to userland. >> >>> When calculating bandwidth in userland, it's not include headers' >>> bytes. From the user's perspective, it's not a correct bandwidth. >>> >> >> >>> Shall we need take account of headers in qdisc_skb_cb(skb)->pkt_len or >>> just skb->len? >>> >> These values are not accessible from userland, unless you capture >> packets with a sniffer (tcpdump or something like that) >> >>> Example: >>> tc qdisc add dev $DEV root handle 1: tbf latency 50ms burst 500kB rate >>> 500mbit mtu 64k >>> >>> iperf -c host -t 30 -i 10 >>> [ ID] Interval Transfer Bandwidth >>> [ 3] 0.0-10.0 sec 571 MBytes 479 Mbits/sec >>> [ 3] 10.0-20.0 sec 570 MBytes 478 Mbits/sec >>> [ 3] 20.0-30.0 sec 570 MBytes 478 Mbits/sec >>> [ 3] 0.0-30.0 sec 1.67 GBytes 478 Mbits/sec >> >> >> iperf only measures the amount of payload, and probably do not care of >> headers. >> >> You cannot accurately measure bandwidth from userland, unless making >> assumptions (or getting them from the stack) on header sizes (IP + TCP), >> MSS value, and retransmits. >> >> > > ok, for the further, can you give me some advise for how calculate the bandwidth for net link. > for example,what kind of tools is better. > >> Vendor specific but it looks reasonably common to count tx and rx bytes in ethtool stats. Take a few samples with 'ethtool -S' and do the math. This will give you what the driver/hardware actually xmits and receives. .John -- John Fastabend Intel Corporation ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-07-17 3:19 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-16 4:12 net_sched: precision problem of TBF/HTB Yang Yingliang 2013-07-16 4:50 ` Eric Dumazet 2013-07-17 1:41 ` Ding Tianhong 2013-07-17 3:18 ` John Fastabend
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).