Re: [LARTC] HTB: ¿how do burst/cburst work exactly?

2005-07-13 Thread VideoIP

Ok, that´s great. I have a much better idea now.

However I have a doubt on [1]. When packets arrive to an HTB filter, it 
first checks to see if there are ctokens available. How come if there are, 
it then checks for tokens instead of just dequeuing at full speed. And if 
there are none: shouldn´t it THEN check for tokens instead of discarding 
right away?


Also, could you give me an advice or reference on the following?
I need a child class to allow passage to a video stream that I KNOW has mean 
X kbps and seldom peaks of Y kbps and T seconds. Would the best way be to 
just configure mean=X, ceil=Y? Or should I configure mean=ceil=X and 
calculate a cburst that´ll allow passage of the peaks? Or maybe a third 
option.



- Original Message - 
From: Martin A. Brown [EMAIL PROTECTED]

To: VideoIP [EMAIL PROTECTED]
Cc: lartc lartc@mailman.ds9a.nl
Sent: Wednesday, July 13, 2005 2:14 AM
Subject: Re: [LARTC] HTB: ¿how do burst/cburst work exactly?



Hello,

: I´ve read all the definitions of burst and cburst and I´ve tried
: playing with the parameters and graphing the output of the filter
: to see its effects, but STILL I can´t figure out how the
: parameters work exactly.
:
: Could anyone give a better explanation than the manpage?

Have you tried Stef's site?  He has a good page [0] that talks about
the various tests he did while experimenting with HTB burst and
cburst parameters?

Some time ago, I took a stab at creating a visual representation [1]
of a hypothetical HTB configuration [2].  In order to understand
when cburst is used, look for the diamond-shaped boxes in the
diagram which talk about tokens and ctokens.

Every HTB class has two buckets.

 rate bucket is of burst size, traffic uses tokens
 ceil bucket is of cburst size, traffic uses ctokens

My diagram may give you the framework to understand exactly how they
are used if it's still unclear to you, but Stef's site will give you
much better detail on the results of using burst and cburst.  Of the
scenarios he describes, I like the results of Test 7 the best.  The
only guideline that struck me after reading his results was to
prefer burst and cburst usage on parent classes.

Good luck,

-Martin

[0] http://www.docum.org/docum.org/tests/htb/burst/
[1] http://linux-ip.net/traffic-control/htb-class.png
[2] http://linux-ip.net/traffic-control/diagram.html

--
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED] 


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


Re: [LARTC] Re: RFC - bandwidth optimization idea

2005-07-13 Thread Ed W



Assuming you can send both ways simultaneously, or at least guarantee
some traffic time outbound no matter how busy the inbound traffic,
you would surely have to pipeline your commands in order to get any
kind of efficient use out of a high-latency link like a satellite link.
Otherwise you lose 2x round-trip-time of incoming data stream while
you request the next item.

In this situation, you would want the OS buffers to be as full as
possible so the minimal time possible is spent receiving, but using
a traffic-shaping solution so that the most important stuff (acks
and commands) goes out in preference to whatever else you're sending.
 



Yes you do want to pipeline, but you still don't want the OS buffers 
full as possible.  Consider that you might want to know a message was 
sent successfully before sending the next message, but at the same time 
you have the pipe full with downloading new messages.  The OK which says 
the message was sent OK can be behind 15-20 seconds worth of downloads - 
hence you have to wait a long time before you can start sending the next 
message!


Also you can't use any kind of QOS here because the hypothetical 15-20 
second buffer is at the remote ISP end. (Who are not cooperative)


It's a tricky situation all you can do is figure out how to keep 
changing your protocol so that you don't ever need to hear a reply 
before you continue sending.


Anyone wants to buy it then drop me a line! 


:-)

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


Re: [LARTC] Re: RFC - bandwidth optimization idea

2005-07-13 Thread Ed W



I'm not sure I follow the problem, but if you're saying that one
stream should have priority over the other, it seems you could do
that with two different queues, one with priority over the other.
Or something like sfq could at least prevent one connection from
waiting for the other to send a lot of data.
 



You could if you have control over the queues.  But they are on the 
remote ISP end...  So the problem is similar to the one you describe - 
once the data is inflight you lose control but you want to limit how 
much data is inflight so that you have as much control as possible...


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


RE: [LARTC] HTB Rate and Prio (continued)

2005-07-13 Thread Gael Mauleon
Ok I tested the shaping on the SDSL line with netperf and
an host outside.

Same script than before, I classify the packets into qdisc based on the
source address in netfilter and here are the result, that's with sfq.
I'm positive on the right traffic going to the right class.


TCP STREAM TEST to 81.57.243.113 (NORMAL)
Recv   SendSend
Socket Socket  Message  Elapsed
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^3bits/sec

 87380   8192   819260.00 282.90



TCP STREAM TEST to 81.57.243.113 (LOWPRIO)
Recv   SendSend
Socket Socket  Message  Elapsed
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^3bits/sec

 87380   8192   819261.00 390.00


In fact the rate are just share sometimes it's the LOWPRIO that has more
Sometimes it's the NORMAL traffic...

As a note, there were other traffic on the line at the same moment I didn't
classify but I was expecting the ratio to be kept (LOWPRIO is prio 5,
50kbits, NORMAL is prio 1 200kbits)

Well I need to investigate more, I don't understand why it don't work on the
SDSL line...

My installation is quite simple :

Cisco Router - Linux Box (QOS) - LAN

And I was testing egress traffic from LAN to internet, but it's the same for
ingress.


Do this can appear if the ratio I put are bigger than the actual line ??
And again what is a good ratio/ceil for a so sold 2mbits SDSL line ??


Gaël.


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


[LARTC] HTB traffic control over VLAN interface.

2005-07-13 Thread Supratim Mitra
Hi All, This is my first mail to the LARTC mailing list.I am having
some problems with the download bandwidth over VLAN.The setup i am
having at my place is somewhat below..  +---+
  
  |  
  |
 | FTP Server |
  
  |
  
| 
 +---+
  
 
  |
  +---+  |
  | 
|
 |
  |   eth1=|---+
  | My Box |
  | eth0=|+  
  |

|   |
  +---+  |
  
 

|
+--+--+---+
  
 |   
|   
|
  |
vlans - eth0.1 eth0.2 
eth0.3 eth0.1001I
am doing some traffic control with my box.It has got the phsical
interfaces eth0 and eth1.eth1 is connected the FTP server and on eth0
VLANs are created.It has the usual tc(HTB) and iptables rules added for
traffic control. when i am
downloading anything over physical interface eth0 without using any
VLAN i am getting the desired download bandwidth with TCP,UDP and
ICMP.The upload bandwidth using the VLAN is desired one.Even the
download bandwidth using the VLAN interfaces with UDP and ICMP is
correct. But the problem arises when i am downloading anything
using the VLAN interfaces with TCP.Its is showing around 180kbps for
the alloted 256kbps and around 350kbps for 512kbps.Thanking in Advance!regards,Supratim
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


RE: [LARTC] HTB Rate and Prio (continued)

2005-07-13 Thread Gael Mauleon
Just tested with 1800kbits as the rate/ceil of the line, with adjustment to
all the rate to match the total rate, but I have the same result, bandwith
seems to be shared just like if there were no qos in place...

I'll do a full round trip of tests today, it must be hidden somewhere :)

 -Message d'origine-
 De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 De la part de Gael Mauleon
 Envoyé : mercredi 13 juillet 2005 12:26
 À : lartc@mailman.ds9a.nl
 Objet : RE: [LARTC] HTB Rate and Prio (continued)
 
 Ok I tested the shaping on the SDSL line with netperf and
 an host outside.
 
 Same script than before, I classify the packets into qdisc based on the
 source address in netfilter and here are the result, that's with sfq.
 I'm positive on the right traffic going to the right class.
 
 
 TCP STREAM TEST to 81.57.243.113 (NORMAL)
 Recv   SendSend
 Socket Socket  Message  Elapsed
 Size   SizeSize Time Throughput
 bytes  bytes   bytessecs.10^3bits/sec
 
  87380   8192   819260.00 282.90
 
 
 
 TCP STREAM TEST to 81.57.243.113 (LOWPRIO)
 Recv   SendSend
 Socket Socket  Message  Elapsed
 Size   SizeSize Time Throughput
 bytes  bytes   bytessecs.10^3bits/sec
 
  87380   8192   819261.00 390.00
 
 
 In fact the rate are just share sometimes it's the LOWPRIO that has more
 Sometimes it's the NORMAL traffic...
 
 As a note, there were other traffic on the line at the same moment I
 didn't
 classify but I was expecting the ratio to be kept (LOWPRIO is prio 5,
 50kbits, NORMAL is prio 1 200kbits)
 
 Well I need to investigate more, I don't understand why it don't work on
 the
 SDSL line...
 
 My installation is quite simple :
 
 Cisco Router - Linux Box (QOS) - LAN
 
 And I was testing egress traffic from LAN to internet, but it's the same
 for
 ingress.
 
 
 Do this can appear if the ratio I put are bigger than the actual line ??
 And again what is a good ratio/ceil for a so sold 2mbits SDSL line ??
 
 
 Gaël.
 
 
 ___
 LARTC mailing list
 LARTC@mailman.ds9a.nl
 http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


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


Re: [LARTC] QOS HELP PLEASE

2005-07-13 Thread Andreas Klauer
On Tuesday 12 July 2005 19:47, Dariusz Dwornikowski wrote:
 ok i did the calculations and here it is : www.tdi.pozman.pl/fir3

Is this URL valid? I get a 404.

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


Re: [LARTC] HTB: ¿how do burst/cburst work exactly?

2005-07-13 Thread Martin A. Brown

 : However I have a doubt on [1]. When packets arrive to an HTB 
 : filter, it first checks to see if there are ctokens available. 
 : How come if there are, it then checks for tokens instead of just 
 : dequeuing at full speed. And if there are none: shouldn´t it THEN 
 : check for tokens instead of discarding right away?

I would like to quibble about terminology here.  A filter selects a 
destination class (which contains a qdisc).  Filters have absolutely 
nothing to do with tokens.  Once a packet has been filtered, it 
enters its destination class.

Roughly speaking, the class does the following:

  1. check to see if there are tokens availabledequeue
  2. check to see if there are ctokens available   dequeue
  3. wait until tokens become availablegoto 2 (1?)

Once a packet is in an HTB class, the packet will not get discarded 
by the class until the class itself has a tremendous backlog and 
needs to drop the packet.  An HTB class will delay the transmission 
of the packet until tokens are available.  This is the core feature 
which provides the shaping capability.

 : Also, could you give me an advice or reference on the following? 
 : I need a child class to allow passage to a video stream that I 
 : KNOW has mean X kbps and seldom peaks of Y kbps and T seconds. 
 : Would the best way be to just configure mean=X, ceil=Y? Or should 
 : I configure mean=ceil=X and calculate a cburst that´ll allow 
 : passage of the peaks? Or maybe a third option.

I cannot recommend an optimal calculation method, though I would 
start with X kbps as the rate and Y kbps * T as the burst.  After 
that, I'd increase rate and decrease burst until there was no 
choppiness in the transmitted video stream.

Good luck,

-Martin

 : - Original Message - From: Martin A. Brown
 : [EMAIL PROTECTED]
 : To: VideoIP [EMAIL PROTECTED]
 : Cc: lartc lartc@mailman.ds9a.nl
 : Sent: Wednesday, July 13, 2005 2:14 AM
 : Subject: Re: [LARTC] HTB: ¿how do burst/cburst work exactly?
 : 
 : 
 : 
 : Hello,
 : 
 : : I´ve read all the definitions of burst and cburst and I´ve tried
 : : playing with the parameters and graphing the output of the filter
 : : to see its effects, but STILL I can´t figure out how the
 : : parameters work exactly.
 : : 
 : : Could anyone give a better explanation than the manpage?
 : 
 : Have you tried Stef's site?  He has a good page [0] that talks about
 : the various tests he did while experimenting with HTB burst and
 : cburst parameters?
 : 
 : Some time ago, I took a stab at creating a visual representation [1]
 : of a hypothetical HTB configuration [2].  In order to understand
 : when cburst is used, look for the diamond-shaped boxes in the
 : diagram which talk about tokens and ctokens.
 : 
 : Every HTB class has two buckets.
 : 
 : rate bucket is of burst size, traffic uses tokens
 : ceil bucket is of cburst size, traffic uses ctokens
 : 
 : My diagram may give you the framework to understand exactly how they
 : are used if it's still unclear to you, but Stef's site will give you
 : much better detail on the results of using burst and cburst.  Of the
 : scenarios he describes, I like the results of Test 7 the best.  The
 : only guideline that struck me after reading his results was to
 : prefer burst and cburst usage on parent classes.
 : 
 : Good luck,
 : 
 : -Martin
 : 
 : [0] http://www.docum.org/docum.org/tests/htb/burst/
 : [1] http://linux-ip.net/traffic-control/htb-class.png
 : [2] http://linux-ip.net/traffic-control/diagram.html
 : 
 : 

-- 
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[LARTC] routing problems with two SDSL-connections

2005-07-13 Thread Jonathan Schmieg

Hello List,


in our office we have two independant SDSL-connections.
One of them is a flatrate, the other is a dedicated line to our webfarm.
The goal is to route all the traffic to the webfarm through the
dedicated line and all other traffic through the flatrate.
The maschine has three nics:
eth0: internal network
eth1: webfarm
eth2: flatrate
Each connection uses its own router. It is possible to access the
internet through both connections, for example with ping -I interface
address.
I wrote an script for the issue mentioned above:
please take a look at the attachment
The whole thing works great under Knoppix, but neither with gentoo, nor
with debian sarge (I want to use debian sarge for the router).
Just for testing I took another maschine with gentoo and there it also
works. (same kernel-, same iptables-, same iproute2-versions and also
the same nics)
With tcpdump I can see that packets sent by a client from the internal
network leave the gateway, the answer comes back but is not passed on
the the client.
I hope somebody has an idea how I could solve the problem,

greetings,
Jonathan Schmieg



#!/bin/sh

## Variablen
GATEWAY_DEF=X.X.X.25
GATEWAY_T2=Y.Y.Y.177
IP_T2=Y.Y.Y.180
IFACE_INT=eth0

## Kernelparameter
echo 1  /proc/sys/net/ipv4/conf/all/forwarding


## Status ##

if [ $1 = status ]
then
echo Default Route\n
ip route show
echo Spacenet Route\n
ip route show table 2
echo Rules\n
ip rule show
echo Markierungen\n
iptables -t mangle -L ROUTING -v -x 2 /dev/null
exit
fi

##
## Stop ##
##
iptables -t mangle -D PREROUTING -j ROUTING 2 /dev/null  /dev/null
iptables -t mangle -D FORWARD -j ROUTING 2 /dev/null  /dev/null
iptables -t mangle -F ROUTING 2 /dev/null  /dev/null
iptables -t mangle -X ROUTING 2 /dev/null  /dev/null

ip route del table 2
ip route del default via $GATEWAY_DEF
ip rule del from $IP_T2 table 2
ip rule del fwmark 66 table 2
ip route flush cache

if [ $1 = stop ]
then
echo Routing removed
exit
fi

###
## Start ##
###

## 2. Tabelle anlegen
ip route show table main | grep -Ev ^default | while read ROUTE ; do ip route 
add table 2 $ROUTE; done
ip route add default via $GATEWAY_T2 table 2

## Defaultgw setzen
ip route add default via $GATEWAY_DEF

##Routing regeln setzen
ip rule add from $IP_T2 table 2

ip route flush cache
ip rule add fwmark 66 table 2

##Iptables Tabelle anlegen
iptables -t mangle -N ROUTING
iptables -t mangle -I PREROUTING -j ROUTING
iptables -t mangle -I FORWARD -j ROUTING

## Markieren Kleinwebs
iptables -t mangle -A ROUTING  -i $IFACE_INT -p all -d Y.Y.A.0/24 -j MARK 
--set-mark 66

## Markieren KUNDE
iptables -t mangle -A ROUTING  -i $IFACE_INT -p all -d Y.Y.B.0/24 -j MARK 
--set-mark 66

## Markieren Maintanace
iptables -t mangle -A ROUTING  -i $IFACE_INT -p all -d 192.168.100.0/24 -j MARK 
--set-mark 66

## NAT setzen / passiert aber normal in der Firewall  :) 
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.0/24 -j SNAT  --to-source 
Y.Y.Y.180
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.10.0/24 -j SNAT --to-source 
X.X.X.30

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


Re: [LARTC] HTB: ¿how do burst/cburst work exactly?

2005-07-13 Thread VideoIP

: : Also, could you give me an advice or reference on the following?
: : I need a child class to allow passage to a video stream that I
: : KNOW has mean X kbps and seldom peaks of Y kbps and T seconds.
: : Would the best way be to just configure mean=X, ceil=Y? Or should
: : I configure mean=ceil=X and calculate a cburst that´ll allow
: : passage of the peaks? Or maybe a third option.
:
: I cannot recommend an optimal calculation method, though I would
: start with X kbps as the rate and Y kbps * T as the burst.  After
: that, I'd increase rate and decrease burst until there was no
: choppiness in the transmitted video stream.

Would in that scenario ceil=rate or ceil=Y kbps? It seems to me that if 
ceil=rate, then there´s no use in having a burst bucket, or is there?

Thanks again,
   Florencio 


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


[LARTC] Bandwidth shaping and ISP's network peerings

2005-07-13 Thread panca sorin
Hello all! I have a small LAN at home and when someone
starts to download (only one), interractive traffic
(www, chat and online games) is impossible with
standard kernel queues setup... So I started to shape.
My ISP gives me a 512 kbits link to the Internet and a
100 Mbits link to some of the other big ISPs in my
country. If I set the rate of the parent htb qdisc at
512 kbits, I will never use the MAN bandwidth from my
network. If I set the rate of the parent htb qdisc at
100 Mbits, i cannot shape interractive traffic.
Further, I would like to allocate for every station in
the LAN a quantum of my Internet speed with ceiling
but in MAN I want to have the full hardware speed if
only one machine is connected, with any ceil.
Any ideas would be VERY appreciated! I can't imagine
any good setup to meet these constraints.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] HTB Rate and Prio (continued)

2005-07-13 Thread Andy Furniss

Gael Mauleon wrote:

Ok I tested the shaping on the SDSL line with netperf and
an host outside.

Same script than before, I classify the packets into qdisc based on the
source address in netfilter and here are the result, that's with sfq.
I'm positive on the right traffic going to the right class.



 TCP STREAM TEST to 81.57.243.113 (NORMAL)
 Recv   SendSend
 Socket Socket  Message  Elapsed
 Size   SizeSize Time Throughput
 bytes  bytes   bytessecs.10^3bits/sec

  87380   8192   819260.00 282.90



 TCP STREAM TEST to 81.57.243.113 (LOWPRIO)
 Recv   SendSend
 Socket Socket  Message  Elapsed
 Size   SizeSize Time Throughput
 bytes  bytes   bytessecs.10^3bits/sec

  87380   8192   819261.00 390.00

Hmm I can't really think why this is happening, is it the same box that 
you did the lan test from?


I think what I would do as the next test is turn off window scaling -

echo 0  /proc/sys/net/ipv4/tcp_window_scaling

add 70k bfifos to the classes - you shouldn't drop any packets then.
Repeat the test and tcpdump it. If you see packet loss then this could 
be the explanation.


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


Re: [LARTC] HTB Rate and Prio (continued)

2005-07-13 Thread Andy Furniss

Andy Furniss wrote:


add 70k bfifos to the classes - you shouldn't drop any packets then.


Maybe 100k just to be safe 70k may be a bit close once you take into 
account the headers.


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


[LARTC] Losing Packets after a DNAT in prerouting

2005-07-13 Thread Jefferson Cowart
I'm trying to setup some DNAT and the packets seem to be disappearing after
the PREROUTING step. The packets are coming in eth2 (both LOG targets in
iptables and tcpdump confirm this). They are then DNATed to an IP that
should cause them to go out eth3. However I never see them go out that
interface. I have tried putting LOG rules into the FORWARD chain with no
success. I'm pretty sure the packet isn't hitting a DROP rule as all my DROP
rules have a LOG rule directly in front of them. Any idea how to track down
the missing packets?


Thanks
Jefferson Cowart
[EMAIL PROTECTED]  

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