Re: [LARTC] new perflow rate control queue

[Wang Jian <lark@linux.net.cn>]

Hi Andy Furniss,


On Wed, 06 Apr 2005 13:29:56 +0100, Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> > 
> > I read back your post and I think the best solution for you is use HTB +
> > PRIO.
>
> I sort of have htb setup like prio but it's more flexable.

I am glad to hear that :)

> > 
> > Let interactive but low rate traffic have highest priority, and let bulk
> > transfer have lowest priority and constrain them using HTB.
> > 
> > TCP itself has some fairness: slower stream get faster, and faster
> > stream get slower. The sliding window is for this.
> 
> TCP can be very unfair in some cases - different window sizes/scale on 
> off and 56k vs broadband peer.
>

Yes. This unfairness is generally a good thing (but not always). It
is in favour of tcp connection in the fast/wide path, so bandwidth can
be used "efficiently" :)

> I am rebuilding stuff on my gateway at the moment and noticed the 
> iproute patch doesn't compile with gcc 2.95.3 it's fine with 3.3.
> 
> q_perflow.c: In function `perflow_print_opt':
> q_perflow.c:141: parse error before `char'
> q_perflow.c:142: `b1' undeclared (first use in this function)
> q_perflow.c:142: (Each undeclared identifier is reported only once
> q_perflow.c:142: for each function it appears in.)
> make[1]: *** [q_perflow.o] Error 1
> 

This is due to the included <linux/jhash.h>.


Regards
-- 
  lark

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc