All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Cc: "Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Jiri Benc" <jbenc@redhat.com>, "David Miller" <davem@redhat.com>,
	j.vimal@gmail.com, "Michal Soltys" <soltys@ziu.info>,
	"Mike Frysinger" <vapier@gentoo.org>,
	"Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>,
	"Patrick McHardy" <kaber@trash.net>,
	"Jiri Pirko" <jpirko@redhat.com>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Dave Taht" <dave.taht@gmail.com>,
	bloat@lists.bufferbloat.net, "Dan Siemon" <dan@coverfire.com>,
	"Jim Gettys" <jg@freedesktop.org>,
	"Steven Barth" <cyrus@openwrt.org>,
	"Felix Fietkau" <nbd@nbd.name>
Subject: Re: [PATCH] net_sched: htb: do not mix 1ns and 64ns time units
Date: Tue, 4 Jun 2013 22:21:35 +0200	[thread overview]
Message-ID: <20130604222135.67eedab8@redhat.com> (raw)
In-Reply-To: <1370365908.24311.222.camel@edumazet-glaptop>

On Tue, 04 Jun 2013 10:11:48 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> From: Eric Dumazet <edumazet@google.com>
> 
> commit 56b765b79 ("htb: improved accuracy at high rates") added
> another regression for low rates, because it mixes 1ns and 64ns time
> units.
> 
> So the maximum delay (mbuffer) was not 60 second, but 937 ms.
> 
> Lets convert all time fields to 1ns as 64bit arches are becoming the
> norm.

I'm of-cause happy as I need this fixed for big-HW machines at Red Hat.

But how is this 64-bit usage going to affect performance for smaller
ARM/MIPS based home routers, where shaping at these low rates is more
relevant?  (I'm just asking because I don't know, and just test this
on a 24-CPU machine).

Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>

I have tested you patch, and it works for me.
Tested shaping at 100Kbit/s:
 - max "rate 100656bit" on dev lo
 - max "rate 102016bit" on a real  1 Gbit/s NIC (dev eth63).
 - max "rate 103256bit" on a real 10 Gbit/s NIC (dev eth31).

The traffic "of-cause" spikes due to the GSO frames, if measuring the
traffic at a higher resolution (I've seen upto 3 sec without traffic).

Thanks for the quick fix! :-)))
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

Reproducer commands:
 tc qdisc add dev lo root handle 1: htb default 1
 tc class add dev lo parent 1: classid 1:1 htb rate 100kbit
 netserver
 netperf -t TCP_STREAM -l 60 -H 127.0.0.1 -- -m 1024

Measuring the qdisc "rate" via:
 tc -s -d class show dev lo classid 1:1

Data:
=====
>From dev "lo":
--------------
class htb 1:1 root prio 0 quantum 1250 rate 100000bit ceil 100000bit burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0 
 Sent 597719 bytes 64 pkt (dropped 942, overlimits 0 requeues 0) 
 rate 100656bit 1pps backlog 0b 1p requeues 0 
 lended: 64 borrowed: 0 giants: 0
 tokens: -27387576 ctokens: -27387576

>From 1Gbit/s dev eth63:
-----------------------
class htb 1:1 root prio 0 quantum 1250 rate 100000bit ceil 100000bit burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0 
 Sent 1801152 bytes 3224 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 102016bit 9pps backlog 0b 12p requeues 0 
 lended: 2284 borrowed: 0 giants: 0
 tokens: -18923820 ctokens: -18923820


>From 10Gbit/s dev eth31:
------------------------
class htb 1:1 root prio 0 quantum 1250 rate 100000bit ceil 100000bit burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0 
 Sent 855814 bytes 581 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 103256bit 9pps backlog 0b 9p requeues 0 
 lended: 81 borrowed: 0 giants: 0
 tokens: -45419150 ctokens: -45419150

  reply	other threads:[~2013-06-04 20:22 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 13:13 tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved accuracy at high rates) Jesper Dangaard Brouer
2013-05-29 15:52 ` Eric Dumazet
2013-05-29 22:50   ` Stephen Hemminger
2013-05-29 23:18     ` Eric Dumazet
2013-05-30  9:15       ` Jesper Dangaard Brouer
2013-05-30  9:52         ` [Bloat] " Steinar H. Gunderson
     [not found]     ` <20130529155034.334092c5-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org>
2013-05-30  0:34       ` Dave Taht
2013-05-30  8:09     ` Jesper Dangaard Brouer
2013-05-30  7:51   ` Jesper Dangaard Brouer
2013-05-30 14:39     ` Eric Dumazet
2013-05-30 15:55       ` Jesper Dangaard Brouer
2013-05-30 16:29         ` Jussi Kivilinna
2013-06-02 21:15 ` Eric Dumazet
2013-06-02 21:33   ` [PATCH iproute2] htb: report overhead attribute Eric Dumazet
2013-06-03 15:45     ` Rick Jones
2013-06-03 15:56       ` Eric Dumazet
2013-06-04 11:11         ` Jesper Dangaard Brouer
2013-06-04 13:58           ` Eric Dumazet
2013-06-04 15:08             ` Jesper Dangaard Brouer
2013-06-03 19:50       ` Jussi Kivilinna
2013-06-07 15:56     ` Stephen Hemminger
2013-06-07 16:00       ` Eric Dumazet
2013-06-04 12:13 ` Bad shaping at low rates, after commit 56b765b79 (htb: improved accuracy at high rates) Jesper Dangaard Brouer
2013-06-04 15:18   ` Eric Dumazet
2013-06-04 15:55     ` Eric Dumazet
2013-06-04 16:02       ` Eric Dumazet
2013-06-04 17:11         ` [PATCH] net_sched: htb: do not mix 1ns and 64ns time units Eric Dumazet
2013-06-04 20:21           ` Jesper Dangaard Brouer [this message]
     [not found]             ` <20130604222135.67eedab8-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-06-04 20:26               ` Dave Taht
2013-06-04 21:02                 ` Eric Dumazet
2013-06-04 20:50             ` Eric Dumazet
2013-06-05  0:44           ` David Miller
2013-06-06 13:55 ` RFC: Proposed fix for tc linklayer calc broken after commit 56b765b79 (htb: improved accuracy at high rates) Jesper Dangaard Brouer
2013-06-06 14:28   ` Eric Dumazet

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130604222135.67eedab8@redhat.com \
    --to=jbrouer@redhat.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=brouer@redhat.com \
    --cc=cyrus@openwrt.org \
    --cc=dan@coverfire.com \
    --cc=dave.taht@gmail.com \
    --cc=davem@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=j.vimal@gmail.com \
    --cc=jbenc@redhat.com \
    --cc=jg@freedesktop.org \
    --cc=jpirko@redhat.com \
    --cc=jussi.kivilinna@mbnet.fi \
    --cc=kaber@trash.net \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=soltys@ziu.info \
    --cc=stephen@networkplumber.org \
    --cc=toke@toke.dk \
    --cc=vapier@gentoo.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.