[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