Re: [LARTC] HTB + speed a bit lower than what shaped to

2005-04-08 Thread Wang Jian
Hi Jandre Olivier, 1. although the rate is 32Kbit, the ceil is also 32Kbit; you will get very close 32Kbit, but no more that 32Kbit. 2. The kernel calculates rate based on the packet size, not payload length. But your client, calculates rate based on the payload length. If the traffic pattern is

Re: [LARTC] MARK vs CLASSIFY with tc

2005-04-06 Thread Wang Jian
Hi Adrian Turcu, On Wed, 6 Apr 2005 16:28:30 +0100, Adrian Turcu <[EMAIL PROTECTED]> wrote: > Hello list, > > I just wonder if someone did any performance tests (speed of processing the > packets) or maybe could advise about this two scenario: > > 1. packets are marked with iptables and proce

Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem

2005-04-06 Thread Wang Jian
Hi John E. Peterson, Yes. My stupid typo. On Wed, 6 Apr 2005 10:08:20 -0400, "John E. Peterson" <[EMAIL PROTECTED]> wrote: > Did you mean POSTROUTING to PREROUTING? That looked wierd. > > - Original Message - > From: "Wang Jian" <[EMAIL PR

Re: [LARTC] UDP port 1194 marking/routing problem

2005-04-06 Thread Wang Jian
194 has to be routed via eth0 to OpenVPN server IP, > everything else > to same Ip has to go via eth1. I see. So you need policy routing. Change your netfilter rule from POSTROUTING to POSTROUTING. > > > - Original Message - > From: "Wang Jian" <[EMAIL

Re: [LARTC] new perflow rate control queue

2005-04-06 Thread Wang Jian
Hi Andy Furniss, On Wed, 06 Apr 2005 13:29:56 +0100, Andy Furniss <[EMAIL PROTECTED]> 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 interac

Re: [Openvpn-users] Re: [LARTC] UDP port 1194 marking/routing problem

2005-04-06 Thread Wang Jian
on't think you need to use MARK to do policy routing. > It's a little overkill. > > Do you another suggestion than iptables/MARK? > > Regards > > Remus > > > - Original Message - > From: "Wang Jian" <[EMAIL PROTECTED]> >

Re: [LARTC] ppp+vpn+htb

2005-04-06 Thread Wang Jian
Hi hiphin, On Wed, 6 Apr 2005 13:39:40 +0200, "hiphin" <[EMAIL PROTECTED]> wrote: > Wang, hi, little of thinking and listen what I found logical > > Q1: Is ppp interface, as only one connection on my real eth0 ? > > If answare is YES, then simple SFQ on eth0 is good ? > ...and main difference

Re: [LARTC] UDP port 1194 marking/routing problem

2005-04-06 Thread Wang Jian
Hi Remus, It seems that iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 1194 -j MARK \ --set-mark 0x990 will not take effect. (didn't you typo -A as -D?) POSTROUTING is looked up after routing decision is made. Because the default route is dev eth1, the output device is eth1, -o e

Re: [LARTC] ppp+vpn+htb

2005-04-06 Thread Wang Jian
Hi hiphin, You can also look into ESFQ. Corey Hickey releases esfq for 2.6.12-rc1. On Wed, 06 Apr 2005 16:42:35 +0800, Wang Jian <[EMAIL PROTECTED]> wrote: > Hi hiphin, > > It seems that your network link is eth0. Then > > tc qdisc add dev eth0 root handle 1: htb defa

Re: [LARTC] ppp+vpn+htb

2005-04-06 Thread Wang Jian
Hi hiphin, It seems that your network link is eth0. Then tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 32kbit ceil 256kbit prio 1 Then you can use tc filter to classify all pp

Re: [LARTC] ppp+vpn+htb

2005-04-05 Thread Wang Jian
Hi mail.cat-net.co.yu, Because ppp traffic is over your real network link, you can control ppp traffic over that physic device. But I think it have limitation, because with this way you can't look into the ppp layer and differential TCP/IP applications encapsulated in ppp layer. On Wed, 6 Apr 200

Re: [LARTC] new perflow rate control queue

2005-04-05 Thread Wang Jian
Hi Andy Furniss, On Tue, 05 Apr 2005 23:40:54 +0100, Andy Furniss <[EMAIL PROTECTED]> wrote: > > > > Looking forward to your feedback :) > > It works OK for me - though I would really need it to be variable rate > to use really - but as you say it's designed for your needs. > > I noticed th

Re: [LARTC] new perflow rate control queue

2005-04-04 Thread Wang Jian
Hi Andy Furniss, On Mon, 04 Apr 2005 16:23:30 +0100, Andy Furniss <[EMAIL PROTECTED]> wrote: > > > > > Because this per-flow queue is new, you can add things useful to it. > > It does look good :-) I'll test when I get time. > The attached is the latest. The last one doesn't sync time: queu

Re: [LARTC] new perflow rate control queue

2005-04-04 Thread Wang Jian
peed vary from 3.4kbps to 28.7kbps. The test last about 10 minutes, and the speeds don't like to converge. Maybe the fairness is achived in long run, but it hurts applications that need bandwidth guarantee. On Mon, 04 Apr 2005 12:42:21 +0100, Andy Furniss <[EMAIL PROTECTED]> wrote: >

Re: [LARTC] new perflow rate control queue

2005-04-04 Thread Wang Jian
Hi Andy Furniss, On Mon, 04 Apr 2005 12:42:21 +0100, Andy Furniss <[EMAIL PROTECTED]> wrote: > > Wow - I wish I could write that in 2 days :-) > I think if you have a deadline, then you can do that :-) > > > > The test scenario is like this > > > > www server <- [ eth0 eth1 ] -> w

Re: [LARTC] new perflow rate control queue

2005-04-04 Thread Wang Jian
t the quality requirement. 2. We can't enforce bandwidth constraint when flow count is very low; this often means waste of bandwidth. On Mon, 04 Apr 2005 10:51:15 +0200, Patrick McHardy <[EMAIL PROTECTED]> wrote: > Wang Jian wrote: > > Hi, > > > > One of my custo

[LARTC] new perflow rate control queue

2005-04-04 Thread Wang Jian
Hi, One of my customer needs per flow rate control, so I write one. The code I post here is not finished, but it seems to work as expected. The kernel patch is agains kernel 2.6.11, the iproute2 patch is against iproute2-2.6.11-050314. I write the code in a hurry to meet deadline. There are ma