[LARTC] yet another real time ip and qdisc bandwidth monitor
Hi, I made a prototype for a real-time qdisc and ip bandwidth monitor, it still is not mature, but can be of some use even as it is. To try it : http://clowncode.net Clowncoder ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QoS book
I can recommend this one: http://www.policyrouting.org/PolicyRoutingBook/ Hello all, Can anyone recommend a good book which thoroughly explains QoS from a Linux perspective? Something with TC examples & the like. I've looked at the following: http://www.amazon.com/gp/product/1580533418/qid=1148368189/sr=1-2/ref=sr_1_2/102-2819973-6353768?s=books&v=glance&n=283155 Engineering Internet QoS. Thanks. ___ 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] slackware 10.2 compilation
Hello, I am not an expert myself, but I can suggest that you use 3 lines to limit the overall upload limit for your adsl ;-) MAXOUT=9 tc qdisc add dev eth1 root handle 1: htb default 13 tc class add dev eth1 parent 1: classid 1:1 htb rate $MAXOUT ceil $MAXOUT where eth1 will be the interface that is connected to the ADSL ;-) Hope that helps. Regards, -Nikolay Kichukov - Original Message - From: "tasos" <[EMAIL PROTECTED]> To: Sent: Friday, June 16, 2006 1:41 PM Subject: [LARTC] slackware 10.2 compilation hello people and nice to meet you. [EMAIL PROTECTED]:~/tcng$ ./configure Reading configuration defaults from ./config building tcsim: yes Kernel source:/home/tasoss/linux-2.6.16.20 Kernel version: 2.6.16 iproute2 source: /home/tasoss/iproute2-2.6.16-060323 iproute2 version: 060323 Host byte order: little endian tcng command: /home/tasoss/tcng/bin/tcng YACC is: yacc $ is not identifier: -$ tc supports "action": yes building the manual: NO install directory:/usr/local [EMAIL PROTECTED]:~/tcng$ - make[2]: Entering directory `/home/tasoss/tcng/tcsim' ./setup.klib ./setup.klib: line 119: /home/tasoss/linux-2.6.16.20/net/sched/police.c: No such file or directory make[2]: *** [klib/.ready] Error 1 make[2]: Leaving directory `/home/tasoss/tcng/tcsim' make[1]: *** [tcsim] Error 2 make[1]: Leaving directory `/home/tasoss/tcng/tcsim' make: *** [all] Error 1 -- tcng is compiled fine,but what can i do with tcsim? Moreover i would like to suggest me some good documentation about tc/tcng(traffic control generally?) except for what tldp has already. And finally,my first step it to limit my adsl upload bandwidth from 128Kbps to 90kbps for example.Is it a one-line command? Thank you in advance :-) ___ 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
[LARTC] slackware 10.2 compilation
hello people and nice to meet you.[EMAIL PROTECTED]:~/tcng$ ./configureReading configuration defaults from ./configbuilding tcsim: yesKernel source: /home/tasoss/linux- 2.6.16.20 Kernel version: 2.6.16iproute2 source: /home/tasoss/iproute2-2.6.16-060323iproute2 version: 060323Host byte order: little endiantcng command: /home/tasoss/tcng/bin/tcng YACC is: yacc$ is not identifier: -$tc supports "action": yesbuilding the manual: NOinstall directory: /usr/local[EMAIL PROTECTED]:~/tcng$ -- --- make[2]: Entering directory `/home/tasoss/tcng/tcsim'./setup.klib./setup.klib: line 119: /home/tasoss/linux- 2.6.16.20/net/sched/police.c: No such file or directory make[2]: *** [klib/.ready] Error 1make[2]: Leaving directory `/home/tasoss/tcng/tcsim'make[1]: *** [tcsim] Error 2make[1]: Leaving directory `/home/tasoss/tcng/tcsim'make: *** [all] Error 1-- tcng is compiled fine,but what can i do with tcsim?Moreover i would like to suggest me some good documentation about tc/tcng(traffic control generally?) except for what tldp has already.And finally,my first step it to limit my adsl upload bandwidth from 128Kbps to 90kbps for example.Is it a one-line command?Thank you in advance :-) ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tc ingress policing with multiple subnets
Hello everybody on the list, I have the following situation where I want to police the speed of incoming packets from specific subnets to 1024kbps and then police all the rest to 256kbps, which is the speed my ISP grants for the rest of the internet. So, eth1 is the one connected to the cable modem and then to the internet. I do: tc qdisc add dev eth1 ingress handle : then: tc filter add dev eth1 parent : protocol ip prio 1 u32 match ip src xx.yy.zz.0/24 police rate 1024kbit burst 10kb drop flowid : tc filter add dev eth1 parent : protocol ip prio 1 u32 match ip src pp.dd.df.0/23 police rate 1024kbit burst 10kb drop flowid : ... ... and finally: tc filter add dev eth1 parent : protocol ip prio 2 u32 match ip src 0.0.0.0/0 police rate 256kbit burst 10kb drop flowid : My question is, is there a way I can limit the overall speed of incoming packets from all of those defined subnets to 1024kbps, as it seems in the above scenario that if packets from xx.yy.zz.0/24 subnet arrive at the speed of 1024kbps, and at the same time packets are arriving from pp.dd.df.0/23 at 1024kbps the overall would be 2048kbps, which I do not want. Any comments or suggestions on this topic are welcomed. Another question I have is, what is the difference of the burst/buffer being 10kb or 90kb for example? What difference would that make? Regards, -Nikolay Kichukov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
(Resend message bounced to LARTC)
The Linux traffic's control engine inaccurately calculates
transmission times for packets sent over ADSL links. For
some packet sizes the error rises to over 50%. This occurs
because ADSL uses ATM as its link layer transport, and ATM
transmits packets in fixed sized 53 byte cells.
This changes the userspace tool iproute2/tc by adding an
option to calculate traffic transmission times (rate table)
over all ATM links, including ADSL, with perfect accuracy.
A longer presentation of the patch, its rational, what it
does and how to use it can be found here:
http://www.stuart.id.au/russell/files/tc/tc-atm/
A earlier version of the patch, and a _detailed_ empirical
investigation of its effects can be found here:
http://www.adsl-optimizer.dk/
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
---
diff -Nurp iproute2.orig/include/linux/pkt_sched.h
iproute2/include/linux/pkt_sched.h
--- iproute2.orig/include/linux/pkt_sched.h 2005-12-10 09:27:44.0
+1000
+++ iproute2/include/linux/pkt_sched.h 2006-06-13 11:53:27.0 +1000
@@ -77,8 +77,9 @@ struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
- unsigned short feature;
- short addend;
+ unsigned short feature;/* Always 0 in pre-atm patch kernels */
+ charcell_align; /* Always 0 in pre-atm patch kernels */
+ unsigned char __unused;
unsigned short mpu;
__u32 rate;
};
diff -Nurp iproute2.orig/tc/m_police.c iproute2/tc/m_police.c
--- iproute2.orig/tc/m_police.c 2005-01-19 08:11:58.0 +1000
+++ iproute2/tc/m_police.c 2006-06-13 11:53:27.0 +1000
@@ -35,7 +35,7 @@ struct action_util police_action_util =
static void explain(void)
{
fprintf(stderr, "Usage: ... police rate BPS burst BYTES[/BYTES] [ mtu
BYTES[/BYTES] ]\n");
- fprintf(stderr, "[ peakrate BPS ] [ avrate BPS ]\n");
+ fprintf(stderr, "[ peakrate BPS ] [ avrate BPS ] [ overhead
OVERHEAD ] [ atm ]\n");
fprintf(stderr, "[ ACTIONTERM ]\n");
fprintf(stderr, "Old Syntax ACTIONTERM := action [/NOTEXCEEDACT]
\n");
fprintf(stderr, "New Syntax ACTIONTERM := conform-exceed
[/NOTEXCEEDACT] \n");
@@ -134,7 +134,10 @@ int act_parse_police(struct action_util
__u32 ptab[256];
__u32 avrate = 0;
int presult = 0;
- unsigned buffer=0, mtu=0, mpu=0;
+ unsigned buffer=0, mtu=0;
+ __u8 mpu=0;
+ __s8 overhead=0;
+ int atm=0;
int Rcell_log=-1, Pcell_log = -1;
struct rtattr *tail;
@@ -184,7 +187,7 @@ int act_parse_police(struct action_util
fprintf(stderr, "Double \"mpu\" spec\n");
return -1;
}
- if (get_size(&mpu, *argv)) {
+ if (get_u8(&mpu, *argv, 10)) {
explain1("mpu");
return -1;
}
@@ -198,6 +201,18 @@ int act_parse_police(struct action_util
explain1("rate");
return -1;
}
+ } else if (strcmp(*argv, "overhead") == 0) {
+ NEXT_ARG();
+ if (p.rate.rate) {
+ fprintf(stderr, "Double \"overhead\" spec\n");
+ return -1;
+ }
+ if (get_s8(&overhead, *argv, 10)) {
+ explain1("overhead");
+ return -1;
+ }
+ } else if (strcmp(*argv, "atm") == 0) {
+ atm = 1;
} else if (strcmp(*argv, "avrate") == 0) {
NEXT_ARG();
if (avrate) {
@@ -264,22 +279,12 @@ int act_parse_police(struct action_util
}
if (p.rate.rate) {
- if ((Rcell_log = tc_calc_rtable(p.rate.rate, rtab, Rcell_log, mtu,
mpu)) < 0) {
- fprintf(stderr, "TBF: failed to calculate rate
table.\n");
- return -1;
- }
+ tc_calc_ratespec(&p.rate, rtab, p.rate.rate, Rcell_log, mtu,
mpu, atm, overhead);
p.burst = tc_calc_xmittime(p.rate.rate, buffer);
- p.rate.cell_log = Rcell_log;
- p.rate.mpu = mpu;
}
p.mtu = mtu;
if (p.peakrate.rate) {
- if ((Pcell_log = tc_calc_rtable(p.peakrate.rate, ptab, Pcell_log,
mtu, mpu)) < 0) {
- fprintf(stderr, "POLICE: failed to calculate peak rate
table.\n");
- return -1;
- }
- p.peakrate.cell_log = Pcell_log;
- p.peakrate.m
[LARTC] [PATCH 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
(Resend message bounced to LARTC)
The Linux traffic's control engine inaccurately calculates
transmission times for packets sent over ADSL links. For
some packet sizes the error rises to over 50%. This occurs
because ADSL uses ATM as its link layer transport, and ATM
transmits packets in fixed sized 53 byte cells.
This changes the kernel rate table lookup, to be able to lookup
packet transmission times over all ATM links, including ADSL,
with perfect accuracy. The accuracy is dependent on the rate
table that is calculated in userspace by iproute2 command tc.
A longer presentation of the patch, its rational, what it
does and how to use it can be found here:
http://www.stuart.id.au/russell/files/tc/tc-atm/
A earlier version of the patch, and a _detailed_ empirical
investigation of its effects can be found here:
http://www.adsl-optimizer.dk/
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
---
diff -Nurp kernel-source-2.6.16.orig/include/linux/pkt_sched.h
kernel-source-2.6.16/include/linux/pkt_sched.h
--- kernel-source-2.6.16.orig/include/linux/pkt_sched.h 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/include/linux/pkt_sched.h 2006-06-13
11:42:12.0 +1000
@@ -77,8 +77,9 @@ struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
- unsigned short feature;
- short addend;
+ unsigned short feature;/* Always 0 in pre-atm patch kernels */
+ charcell_align; /* Always 0 in pre-atm patch kernels */
+ unsigned char __unused;
unsigned short mpu;
__u32 rate;
};
diff -Nurp kernel-source-2.6.16.orig/include/net/sch_generic.h
kernel-source-2.6.16/include/net/sch_generic.h
--- kernel-source-2.6.16.orig/include/net/sch_generic.h 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/include/net/sch_generic.h 2006-06-13
11:42:12.0 +1000
@@ -307,4 +307,18 @@ drop:
return NET_XMIT_DROP;
}
+/* Lookup a qdisc_rate_table to determine how long it will take to send a
+ packet given its size.
+ */
+static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, int pktlen)
+{
+ int slot = pktlen + rtab->rate.cell_align;
+ if (slot < 0)
+ slot = 0;
+ slot >>= rtab->rate.cell_log;
+ if (slot > 255)
+ return rtab->data[255] + 1;
+ return rtab->data[slot];
+}
+
#endif
diff -Nurp kernel-source-2.6.16.orig/net/sched/act_police.c
kernel-source-2.6.16/net/sched/act_police.c
--- kernel-source-2.6.16.orig/net/sched/act_police.c2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/net/sched/act_police.c 2006-06-13 11:42:12.0
+1000
@@ -33,8 +33,8 @@
#include
#include
-#define L2T(p,L) ((p)->R_tab->data[(L)>>(p)->R_tab->rate.cell_log])
-#define L2T_P(p,L) ((p)->P_tab->data[(L)>>(p)->P_tab->rate.cell_log])
+#define L2T(p,L) qdisc_l2t((p)->R_tab,L)
+#define L2T_P(p,L) qdisc_l2t((p)->P_tab,L)
#define PRIV(a) ((struct tcf_police *) (a)->priv)
/* use generic hash table */
diff -Nurp kernel-source-2.6.16.orig/net/sched/sch_cbq.c
kernel-source-2.6.16/net/sched/sch_cbq.c
--- kernel-source-2.6.16.orig/net/sched/sch_cbq.c 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/net/sched/sch_cbq.c2006-06-13 11:42:12.0
+1000
@@ -193,7 +193,7 @@ struct cbq_sched_data
};
-#define L2T(cl,len)((cl)->R_tab->data[(len)>>(cl)->R_tab->rate.cell_log])
+#define L2T(cl,len)qdisc_l2t((cl)->R_tab,len)
static __inline__ unsigned cbq_hash(u32 h)
diff -Nurp kernel-source-2.6.16.orig/net/sched/sch_htb.c
kernel-source-2.6.16/net/sched/sch_htb.c
--- kernel-source-2.6.16.orig/net/sched/sch_htb.c 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/net/sched/sch_htb.c2006-06-13 11:42:12.0
+1000
@@ -206,12 +206,10 @@ struct htb_class
static __inline__ long L2T(struct htb_class *cl,struct qdisc_rate_table *rate,
int size)
{
-int slot = size >> rate->rate.cell_log;
-if (slot > 255) {
+long result = qdisc_l2t(rate, size);
+if (result > rate->data[255])
cl->xstats.giants++;
- slot = 255;
-}
-return rate->data[slot];
+return result;
}
struct htb_sched
diff -Nurp kernel-source-2.6.16.orig/net/sched/sch_tbf.c
kernel-source-2.6.16/net/sched/sch_tbf.c
--- kernel-source-2.6.16.orig/net/sched/sch_tbf.c 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/net/sched/sch_tbf.c2006-06-13 11:42:12.0
+1000
@@ -132,8 +132,8 @@ struct tbf_sched_data
struct Qdisc*qdisc; /* Inner qdisc, default - bfifo queue */
};
-#define L2T(q,L) ((q)->R_tab->data[(L)>>(q)->R_tab->rate.cell_log])
-#define L2T_P(q,L) ((q)->P_tab->data[(L)>>(q)->P_tab->rate.cell_log])
+#define L2T(q,L) qdisc_l2t((q)->R_tab,L)
+#define L2T_P(q,L) qdisc_l2t((q)->P_tab,L)
static int tbf_enqueue(struct sk_buff
[LARTC] [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
(Resend message bounced to LARTC) The Linux traffic's control engine inaccurately calculates transmission times for packets sent over ADSL links. For some packet sizes the error rises to over 50%. This occurs because ADSL uses ATM as its link layer transport, and ATM transmits packets in fixed sized 53 byte cells. The following patches to iproute2 and the kernel add an option to calculate traffic transmission times over all ATM links, including ADSL, with perfect accuracy. A longer presentation of the patch, its rational, what it does and how to use it can be found here: http://www.stuart.id.au/russell/files/tc/tc-atm/ A earlier version of the patch, and a _detailed_ empirical investigation of its effects can be found here: http://www.adsl-optimizer.dk/ The patches are both backwards and forwards compatible. This means unpatched kernels will work with a patched version of iproute2, and an unpatched iproute2 will work on patches kernels. This is a combined effort of Jesper Brouer and Russell Stuart, to get these patches into the upstream kernel. Let the discussion start about what we need to change to get this upstream? We see this as a feature enhancement, as thus hope that it can be queued in davem's net-2.6.18.git tree. --- Regards, Jesper Brouer & Russell Stuart. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux router performance (fwd)
I think that Robert Olssons post never made it through the filters... -- Forwarded message -- Date: Fri, 2 Jun 2006 12:32:53 +0200 From: Robert Olsson <[EMAIL PROTECTED]> To: Jesper Dangaard Brouer <[EMAIL PROTECTED]> Cc: Andreas John <[EMAIL PROTECTED]>, Robert Olsson <[EMAIL PROTECTED]>, lartc@mailman.ds9a.nl Subject: Re: [LARTC] Linux router performance Jesper Dangaard Brouer writes: > > Hi > > I'm sure that Robert can provide us with some interesting numbers. > > I have just tested routing performance on a AMD opteron 270 (dual core), > here I can route 400 kpps (tg3 netcards on PCI-X). I use the kernel > module "pktgen" to generate the packets (64 bytes in size). 400 kpps is decent but it all depends on your setup what you're testing. Single flow? Number of packets in environment with hi-number of flows. ( Forces lookup of dst cache, route lookup and garbage collection) is the most challenging Also how to handle filters eventually stateful information. For single flow tests most things end up in L2-cache and we most limited to latency. Bus latency, Memory latency etc. Large packets bus and memory bandwidth. We've seen 500 kpps in some of our production routers for BGP and about 500 filters. Dual Opteron 2.6 GHz. But you need to have a "setup" routing so it can make best use of your HW. Cheers. --ro ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux router performance
Fermín Galán Márquez skrev: Hi, I wonder about the performance of a Linux box used as router (I guest I'm not the first :). Althought I know it mainly depends on the hardware, I'm trying to find some references on the topic or comparations with other routing solutions (FreeBSD box used as router, Cisco, etc). For example, http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf (althought is related with Linux-briding more than with Linux-routing) shows in Figure 14 that with an AMD Duron 1.3GHz 512M RAM a throughput of 90 Mbps can be achieved. Anybody knows any other similar analysis, please? Best regards, Fermín Galán Márquez CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia, Av. del Canal Olímpic s/n, 08860 Castelldefels, Spain Room 1.02 Tel : +34 93 645 29 12 Fax : +34 93 645 29 01 Email address: [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc This was seen on the mailing list a couple of years ago, doesnt say much but it shows what could be done. On Mon, 02 Dec 2002 22:30:10 +0100 Anton Tinchev <[EMAIL PROTECTED]> wrote: > Hi, > first i wonna thank you for the great work. > I have few slack boxes with several 3com cards that acts as routers. > Some of them has 50+ vlans, 100 000+ routing entries, full BGP (zebra) with 10+ peers > and routes 50-70 mb/s traffic. Everithing is rock solid, few months uptimes. Sounds pretty impressive, really. I admire such setups. > I wona to upgrade some of my cards and need advice what to use. > On 100+mb/s interrups killing my boxes - 20 000+/s (yes, coalescing, i know:)) > What to use? tigon2 or tigon3 for gigabit? (3c985 or 3c996) None of them! Or at least not tigon3! I've tried to use one (3c996-T), and I experienced strange system lockups. The board is a dual Tyan Tiger MP with couple of Athlon MP 1600+. It was just hanging from time to time with completely no output of any kind. Just rock solid lockup. :/ Anyway, I changed to a good old 3c905C and now I don't have any problems. Well, I'm serving at half of your rate, but anyway. So, I would suggest using HP equipment. At least I've heard that it works quote well. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] [PATCH 1/2] Runtime configuration of HTB's HYSTERESIS option (kernel)
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
---
diff -Nurp kernel-source-2.6.11.orig/include/linux/pkt_sched.h
kernel-source-2.6.11/include/linux/pkt_sched.h
--- kernel-source-2.6.11.orig/include/linux/pkt_sched.h 2005-03-02
17:38:13.0 +1000
+++ kernel-source-2.6.11/include/linux/pkt_sched.h 2006-06-13
11:34:25.0 +1000
@@ -231,6 +231,10 @@ struct tc_gred_sopt
#define TC_HTB_MAXDEPTH8
#define TC_HTB_PROTOVER3 /* the same as HTB and TC's major */
+struct tc_htb_hopt
+{
+ __u32 nohyst;
+};
struct tc_htb_opt
{
struct tc_ratespec rate;
@@ -258,6 +262,7 @@ enum
TCA_HTB_INIT,
TCA_HTB_CTAB,
TCA_HTB_RTAB,
+ TCA_HTB_NOHYST,
__TCA_HTB_MAX,
};
diff -Nurp kernel-source-2.6.11.orig/net/sched/sch_htb.c
kernel-source-2.6.11/net/sched/sch_htb.c
--- kernel-source-2.6.11.orig/net/sched/sch_htb.c 2005-03-02
17:38:12.0 +1000
+++ kernel-source-2.6.11/net/sched/sch_htb.c2006-06-13 11:34:25.0
+1000
@@ -73,7 +73,6 @@
#define HTB_EWMAC 2/* rate average over HTB_EWMAC*HTB_HSIZE sec */
#undef HTB_DEBUG /* compile debugging support (activated by tc tool) */
#define HTB_RATECM 1/* whether to use rate computer */
-#define HTB_HYSTERESIS 1/* whether to use mode hysteresis for speedup */
#define HTB_QLOCK(S) spin_lock_bh(&(S)->dev->queue_lock)
#define HTB_QUNLOCK(S) spin_unlock_bh(&(S)->dev->queue_lock)
#define HTB_VER 0x30011/* major must be matched with number suplied by
TC as version */
@@ -190,6 +189,7 @@ struct htb_class
/* class attached filters */
struct tcf_proto *filter_list;
int filter_cnt;
+int nohyst;/* Don't use hysteresis htb_class_mode */
int warned;/* only one warning about non work conserving
.. */
@@ -622,20 +622,14 @@ static __inline__ enum htb_cmode
htb_class_mode(struct htb_class *cl,long *diff)
{
long toks;
+long hysteresis =
+ (cl->nohyst || cl->cmode == HTB_CANT_SEND) ? 0 : -cl->cbuffer;
-if ((toks = (cl->ctokens + *diff)) < (
-#if HTB_HYSTERESIS
- cl->cmode != HTB_CANT_SEND ? -cl->cbuffer :
-#endif
- 0)) {
+if ((toks = (cl->ctokens + *diff)) < hysteresis) {
*diff = -toks;
return HTB_CANT_SEND;
}
-if ((toks = (cl->tokens + *diff)) >= (
-#if HTB_HYSTERESIS
- cl->cmode == HTB_CAN_SEND ? -cl->buffer :
-#endif
- 0))
+if ((toks = (cl->tokens + *diff)) >= hysteresis)
return HTB_CAN_SEND;
*diff = -toks;
@@ -1323,6 +1317,7 @@ static int htb_dump_class(struct Qdisc *
unsigned char*b = skb->tail;
struct rtattr *rta;
struct tc_htb_opt opt;
+ struct tc_htb_hopt hopt;
HTB_DBG(0,1,"htb_dump_class handle=%X
clid=%X\n",sch->handle,cl->classid);
@@ -1342,6 +1337,8 @@ static int htb_dump_class(struct Qdisc *
opt.quantum = cl->un.leaf.quantum; opt.prio = cl->un.leaf.prio;
opt.level = cl->level;
RTA_PUT(skb, TCA_HTB_PARMS, sizeof(opt), &opt);
+ hopt.nohyst = cl->nohyst;
+ RTA_PUT(skb, TCA_HTB_NOHYST, sizeof(hopt), &hopt);
rta->rta_len = skb->tail - b;
HTB_QUNLOCK(sch);
return skb->len;
@@ -1527,11 +1524,12 @@ static int htb_change_class(struct Qdisc
struct htb_class *cl = (struct htb_class*)*arg,*parent;
struct rtattr *opt = tca[TCA_OPTIONS-1];
struct qdisc_rate_table *rtab = NULL, *ctab = NULL;
- struct rtattr *tb[TCA_HTB_RTAB];
+ struct rtattr *tb[TCA_HTB_MAX];
struct tc_htb_opt *hopt;
+ struct tc_htb_hopt *uhopt;
/* extract all subattrs from opt attr */
- if (!opt || rtattr_parse_nested(tb, TCA_HTB_RTAB, opt) ||
+ if (!opt || rtattr_parse_nested(tb, TCA_HTB_MAX, opt) ||
tb[TCA_HTB_PARMS-1] == NULL ||
RTA_PAYLOAD(tb[TCA_HTB_PARMS-1]) < sizeof(*hopt))
goto failure;
@@ -1544,6 +1542,10 @@ static int htb_change_class(struct Qdisc
ctab = qdisc_get_rtab(&hopt->ceil, tb[TCA_HTB_CTAB-1]);
if (!rtab || !ctab) goto failur
[LARTC] [PATCH 2/2] Runtime configuration of HTB's HYSTERESIS option (userspace)
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
---
diff -Nurp iproute2.orig/include/linux/pkt_sched.h
iproute2/include/linux/pkt_sched.h
--- iproute2.orig/include/linux/pkt_sched.h 2006-06-13 11:53:27.0
+1000
+++ iproute2/include/linux/pkt_sched.h 2006-06-13 11:54:50.0 +1000
@@ -232,6 +232,10 @@ struct tc_gred_sopt
#define TC_HTB_MAXDEPTH8
#define TC_HTB_PROTOVER3 /* the same as HTB and TC's major */
+struct tc_htb_hopt
+{
+ __u32 nohyst;
+};
struct tc_htb_opt
{
struct tc_ratespec rate;
@@ -259,6 +263,7 @@ enum
TCA_HTB_INIT,
TCA_HTB_CTAB,
TCA_HTB_RTAB,
+ TCA_HTB_NOHYST,
__TCA_HTB_MAX,
};
diff -Nurp iproute2.orig/tc/q_htb.c iproute2/tc/q_htb.c
--- iproute2.orig/tc/q_htb.c2006-06-13 11:53:27.0 +1000
+++ iproute2/tc/q_htb.c 2006-06-13 11:54:50.0 +1000
@@ -35,7 +35,7 @@ static void explain(void)
" r2q DRR quantums are computed as rate in Bps/r2q {10}\n"
" debugstring of 16 numbers each 0-3 {0}\n\n"
"... class add ... htb rate R1 [burst B1] [mpu B] [overhead O]
[atm]\n"
- " [prio P] [slot S] [pslot PS]\n"
+ " [prio P] [slot S] [pslot PS] [nohyst]\n"
" [ceil R2] [cburst B2] [mtu MTU] [quantum
Q]\n"
" rate rate allocated to this class (class can still
borrow)\n"
" burstmax bytes burst which can be accumulated during idle
period {computed}\n"
@@ -46,6 +46,7 @@ static void explain(void)
" cburst burst but for ceil {computed}\n"
" mtu max packet size we create rate map for {1600}\n"
" prio priority of leaf; lower are served first {0}\n"
+ " nohyst disable hysteresis (heavier on CPU but more
accurate)\n"
" quantum how much bytes to serve from leaf at once {use
r2q}\n"
"\nTC HTB version %d.%d\n",HTB_TC_VER>>16,HTB_TC_VER&0x
);
@@ -104,6 +105,7 @@ static int htb_parse_class_opt(struct qd
{
int ok=0;
struct tc_htb_opt opt;
+ struct tc_htb_hopt hopt;
__u32 rtab[256],ctab[256];
unsigned buffer=0,cbuffer=0;
int cell_log=-1,ccell_log = -1;
@@ -114,6 +116,7 @@ static int htb_parse_class_opt(struct qd
struct rtattr *tail;
memset(&opt, 0, sizeof(opt)); mtu = 1600; /* eth packet len */
+ memset(&hopt, 0, sizeof(hopt));
while (argc > 0) {
if (matches(*argv, "prio") == 0) {
@@ -132,6 +135,8 @@ static int htb_parse_class_opt(struct qd
if (get_u8(&mpu8, *argv, 10)) {
explain1("mpu"); return -1;
}
+ } else if (matches(*argv, "nohyst") == 0) {
+ hopt.nohyst = 1;
} else if (matches(*argv, "overhead") == 0) {
NEXT_ARG();
if (get_s8(&overhead, *argv, 10)) {
@@ -221,14 +226,16 @@ static int htb_parse_class_opt(struct qd
addattr_l(n, 2024, TCA_HTB_PARMS, &opt, sizeof(opt));
addattr_l(n, 3024, TCA_HTB_RTAB, rtab, 1024);
addattr_l(n, 4024, TCA_HTB_CTAB, ctab, 1024);
+ addattr_l(n, 5024, TCA_HTB_NOHYST, &hopt, sizeof(hopt));
tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
}
static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
{
- struct rtattr *tb[TCA_HTB_RTAB+1];
+ struct rtattr *tb[TCA_HTB_MAX+1];
struct tc_htb_opt *hopt;
+ struct tc_htb_hopt *uhopt;
struct tc_htb_glob *gopt;
double buffer,cbuffer;
SPRINT_BUF(b1);
@@ -238,7 +245,7 @@ static int htb_print_opt(struct qdisc_ut
if (opt == NULL)
return 0;
- parse_rtattr_nested(tb, TCA_HTB_RTAB, opt);
+ parse_rtattr_nested(tb, TCA_HTB_MAX, opt);
if (tb[TCA_HTB_PARMS]) {
@@ -278,6 +285,13 @@ static int htb_print_opt(struct qdisc_ut
fprintf(f, "buffer [%08x]
[LARTC] [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
The HTB qdisc has a compile time option, HTB_HYSTERESIS, that trades accuracy of traffic classification for CPU time. These patches change hysteresis to be a runtime option under the control of "tc". The effects of HYSTERESIS on HTB's accuracy are significant (see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas HTB's CPU usage on modern machines using broadband links is minimal. Currently HYSTERESIS is on by default, and requires a kernel re-compile to change. Altering it to be a runtime option will make life easier for the bulk of its users. Further documentation on the patch and its usage can be found here: http://www.stuart.id.au/russell/files/tc/tc-atm This is a combined effort of Jesper Brouer and Russell Stuart, to get these patches into the upstream kernel. Let the discussion start about what we need to change to get this upstream? We see this as a feature enhancement, as such hope that it can be queued in davem's net-2.6.18.git tree. -- Regards Russell Stuart and Jesper Brouer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] compilation on slackware 10.2
hello people and nice to meet you.[EMAIL PROTECTED]:~/tcng$ ./configureReading configuration defaults from ./configbuilding tcsim: yesKernel source: /home/tasoss/linux-2.6.16.20 Kernel version: 2.6.16iproute2 source: /home/tasoss/iproute2-2.6.16-060323iproute2 version: 060323Host byte order: little endiantcng command: /home/tasoss/tcng/bin/tcng YACC is: yacc$ is not identifier: -$tc supports "action": yesbuilding the manual: NOinstall directory: /usr/local[EMAIL PROTECTED]:~/tcng$ - make[2]: Entering directory `/home/tasoss/tcng/tcsim'./setup.klib./setup.klib: line 119: /home/tasoss/linux-2.6.16.20/net/sched/police.c: No such file or directory make[2]: *** [klib/.ready] Error 1make[2]: Leaving directory `/home/tasoss/tcng/tcsim'make[1]: *** [tcsim] Error 2make[1]: Leaving directory `/home/tasoss/tcng/tcsim'make: *** [all] Error 1-- tcng is compiled fine,but what can i do with tcsim?Moreover i would like to suggest me some good documentation about tc/tcng(traffic control generally?) except for what tldp has already.And finally,my first step it to limit my adsl upload bandwidth from 128Kbps to 90kbps for example.Is it a one-line command?Thank you in advance :-) ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] problem with multi gatway routing
hi, i wann to make multigateway routing and i read ur how to on http://lartc.org/howto/lartc.rpdb.multiple-links.html and create some rules which i am sending u, but with this rules i am not able to do multigateway routing on my linux router so plz help me out. thanks the rules are given below IF0=eth0 IF1=eth1 IF2=eth2 IP1=192.168.1.2 IP2=61.246.243.86 P1=192.168.1.1 P2=61.246.243.81 P1_NET=192.168.1.0/24 P2_NET=61.246.243.0/28 P0_NET=10.10.0.0/16 ip route add 192.168.1.0/24 dev eth1 src 192.168.1.2 table T1 ip route add default via 192.168.1.1 table T1 ip route add 61.246.243.0/28 dev eth2 src 61.246.243.86 table T2 ip route add default via 61.246.243.81 table T2 ip route add 192.168.1.0/24 dev eth1 src 192.168.1.2 ip route add 61.246.243.0/28 dev eth2 src 61.246.243.86 ip route add default via 192.168.1.1 ip rule add from 192.168.1.2 table T1 ip rule add from 61.246.243.86 table T2 ip route add 10.10.0.0/16 dev eth0 table T1 ip route add 61.246.243.0/28 dev eth2 table T1 ip route add 127.0.0.0/8 dev lo table T1 ip route add 10.10.0.0/16 dev eth0 table T2 ip route add 192.168.1.0/24 dev eth1 table T2 ip route add 127.0.0.0/8 dev lo table T2 ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1 echo 1 > /proc/sys/net/ipv4/ip_forward IT=/usr/local/sbin/iptables FO=FORWARD IN=INPUT OT=OUTPUT PRE=PREROUTING POST=POSTROUTING MQ=MASQUERADE Flust all chains ## /sbin/iptables -F FORWARD /sbin/iptables -F OUTPUT /sbin/iptables -F INPUT /sbin/iptables -F -t nat /sbin/iptables -F -t mangle ### Set the default policy # /sbin/iptables -P INPUT ACCEPT /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -P FORWARD ACCEPT/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Static routing with multiple interfaces
Hi, I am facing some strange problem with multipath routing. I have set up a rule stating that any packets coming from a certain ip address <192.168.52.66> should use an interface < eth1> For this, I used the following commands /ip rule add from 192.168.52.66 table 200 ip route add default table 200 via 192.168.19.76 dev eth1/ Here 192.168.19.76 is eth1's gateway. This is how my rule structure looks /0: from all lookup local 49: from 192.168.52.66 lookup 200 50: from all lookup main 222:from all lookup 222 32766: from all lookup main 32767: from all lookup 253/ However this is not working, I have packets still going out through the other interface when sent from 192.168.51.66. This is how my default table (222) looks /default proto static nexthop via 192.168.19.76 dev eth1 weight 1 nexthop via 192.168.20.25 dev eth2 weight 1 / I dont have a default route in the main or local table. Is there something that I am missing to get the static rule working? Thanks and Regards, Vinod C ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
Russell Stuart wrote: The HTB qdisc has a compile time option, HTB_HYSTERESIS, that trades accuracy of traffic classification for CPU time. These patches change hysteresis to be a runtime option under the control of "tc". The effects of HYSTERESIS on HTB's accuracy are significant (see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas HTB's CPU usage on modern machines using broadband links is minimal. Currently HYSTERESIS is on by default, and requires a kernel re-compile to change. Altering it to be a runtime option will make life easier for the bulk of its users. At time of HTB implementation I needed to reach 100MBit speed on relatively slow box. The hysteresis was a way. On other side I used hand-made TSC based measure tool to compute exact (15%) performance gain. Today I'd measure it using oprofile. When rethinking it again I'd suggest to re-measure real performance impact for both flat and deep class hierarchy and consider switching the hysteresis off by default (or even to remove the code if the gain is negligible). If it is the case then it is the cleanest solution IMHO. On other side I see no problem with attached patches. Have you tested patched kernel with old "tc" tool ? thanks for your effort, Martin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
jamal wrote: I have taken linux-kernel off the list. Russell's site is inaccessible to me (I actually think this is related to some DNS issues i may be having) and your masters is too long to spend 2 minutes and glean it; so heres a question or two for you: - Have you tried to do a long-lived session such as a large FTP and seen how far off the deviation was? That would provide some interesting data point. - To be a devil's advocate (and not claim there is no issue), where do you draw the line with "overhead"? Me and many others have run a smilar hack for years, there is also a userspace project still alive which does the same. The difference is that without it I would need to sacrifice almost half my 288kbit atm/dsl showtime bandwidth to be sure of control. With the modification I can run at 286kbit / 288 and know I will never have jitter worse than the bitrate latency of a mtu packet. The 286 figure was choses to allow a full buffer to drain/ allow for timer innaccuracy etc. On a p200 with tsc, 2.6.12 it's never gone over for me - though talking of timers I notice on my desktop 2.6.16 I gain 2 minutes a day now. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] fwmark filter doesn't work as expected
Hello! Currently I am marking packets with IPMARK, and then using following rules: 1: class add dev eth0 parent 1:4 classid 1:100a htb rate $rate ceil $ceil quantum 1600 2: qdisc add dev eth0 parent 1:100a handle 100a:0 sfq perturb 10 3: filter add dev eth0 protocol ip parent 1:0 pref 30 handle4106 fw classid 1:100a 4: class add dev eth1 parent 1:2 classid 1:100a htb rate $rate ceil $ceil quantum 1600 5: qdisc add dev eth1 parent 1:100a handle 100a:0 sfq perturb 10 6: filter add dev eth1 protocol ip parent 1:0 pref 30 u32 match ip dst 10.100.0.10 flowid 1:100a Tried to remove line 3 and just putting one line instead: filter add dev eth0 parent 1:0 protocol ip pref 30 fw But it does not work. Any ideas? -- Michał Margula, [EMAIL PROTECTED], http://alchemyx.uznam.net.pl/ "W życiu piękne są tylko chwile" [Ryszard Riedel] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Optimization on Bandwidth Management-L7 filtering?
Hi, Recently i just set up a machine for bandwidth management based on layer 7 filtering, i have followed the instruction from http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter . Since all the incoming packets was checked one by one-(it is time consuming and will cause the processing delay if it is handling more than 50 PC at a time), thus i am thinking that is there any way to have a random checking on incoming packets ? Scipt or tools? so that it wont check all the incoming packets one follow by another one. If let say> The incoming packets usage for http is 10 packets that need to be sent in, thus i only check the 1st packet, and then skip the remaining 9 packets checking in order to provide faster processing time to the machine. Is it my idea workable? Does it work in Linux box with Layer7 filtering ? (P/s: my question might be a little bit silly, cause i am still new in this environment) Thanks in advance. Regards, JIN Most of the important things in the world have been accomplished by people who have kept on trying when there seemed to be no hope at all. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
