[Bloat] [PATCH] net_sched: htb: do not mix 1ns and 64ns time units

Dave Taht dave.taht at gmail.com
Tue Jun 4 16:26:09 EDT 2013


On Tue, Jun 4, 2013 at 1:21 PM, Jesper Dangaard Brouer
<jbrouer at redhat.com>wrote:

> On Tue, 04 Jun 2013 10:11:48 -0700
> Eric Dumazet <eric.dumazet at gmail.com> wrote:
>
> > From: Eric Dumazet <edumazet at 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).
>

I'm not worried about it but will find out shortly in cerowrt.

I take it this does not fix the DSL/ATM issue however?


>
> Tested-by: Jesper Dangaard Brouer <brouer at 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
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130604/692ae81e/attachment-0003.html>


More information about the Bloat mailing list