netdev - Re: HTB accuracy for high speed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090519201027.GA4751@ami.dom.local>
Date:	Tue, 19 May 2009 22:10:27 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Vladimir Ivashchenko <hazard@...ncoudi.com>
Cc:	netdev@...r.kernel.org, kaber@...sh.net, davem@...emloft.net,
	devik@....cz, Antonio Almeida <vexwek@...il.com>
Subject: Re: HTB accuracy for high speed

On Tue, May 19, 2009 at 05:04:16PM +0300, Vladimir Ivashchenko wrote:
> > > Please disregard my comment about HFSC. It still overspills heavily.
> > > 
> > > On a 400 mbps limit, I'm getting 520 mbps actual throughput.
> > 
> > I guess you should send some logs. Your previous report seem to show
> 
> Can you give some hints on which logs you would like to see?

Similarly to Antonio's: ifconfigs and tc -s for qdiscs and classes at
the beginning and at the end of testing.

> > the sum of sc rates of of children could be too high. You seem to
> > expect the parent's sc and ul should limit this, but actually children
> > rates decide and parent's rates are mainly for lending/borrowing (at
> 
> The children's ceil rate is 70% of the parent 1:2 class rate.

How about children's main rates?

> > least in HTB). So, it would be nice to try with one leaf class first,
> > (similarly to Antonio) how high rates are respected.
> 
> Unfortunately its difficult for me to play with classes as its real traffic. 
> I'll try to get a traffic generator.

Let it be the real traffic, but please re-check these rates sums.

> > High drop should be OK if the flow is much faster than scheduling/
> > hardware send rate. It could be a bit higher than in older kernels
> > because of limited requeuing, but this could be corrected with
> > longer queue lenghts (sfq has a very short queue: max 127).
> 
> I don't think its sfq, since I have the same sfq qdiscs with HSFC.
> 
> Also I'm comparing this to my production HTB box has 2.6.21.5 with esfq 
> and no bond (just eth), esfq also has 127p limit.
> 
> I tried to get rid of bond on the outbound traffic, I balanced traffic
> via eth0 and eth2 manually by splitting routes going through them.
> 
> I still had the same issue with HTB not reaching the full speed.
> 
> I'm going to try testing exactly the same configuration on 2.6.29 as I have
> on 2.6.21.5 tonight. The only difference would be that I use sfq(dst) instead of
> esfq(dst) which is not available on 2.6.29.

I'm a bit lost about your configs/results and not reaching vs.
overspilled, so please send some new data to compare (gzipped?).

Jarek P. 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html