Re: new perflow rate control queue

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andy Furniss,


On Wed, 06 Apr 2005 13:29:56 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux