[LARTC] new perflow rate control queue
Wang Jian
lark at linux.net.cn
Wed Apr 6 14:48:30 CEST 2005
Hi Andy Furniss,
On Wed, 06 Apr 2005 13:29:56 +0100, Andy Furniss <andy.furniss at 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
More information about the LARTC
mailing list