Re: [LARTC] tc stats and cacti
On Sun, 25 Nov 2007, Stefan Breitegger wrote: Does anybody has a ready solution for graphing the tc stats eg. from htb to cacti? The ADSL-optimizer software package contains a graph module, that can collect TC stats from HTB and store them in RRDtool files, that you should be able to use with Cacti or another RRD display tool. http://www.adsl-optimizer.dk/ADSL-optimizer/graph/ Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Project proposal/idea: Categorize traffic by behavior
Back in 2003/2004 when finding the topic for my masters thesis, I had a secondary project idea, perhaps its about time to do something about the idea, and hear if anyone else thinks its a good idea? The basic idea is to: Categorize traffic by behavior The categorization should be based upon things like packet timing characteristics and packet size, rather than standard port numbers. The categories would be groups like Interactive, (RTP-)Stream, Bulk. - Interactive; would have a high degree of packet inter-timing variants and consist of mainly small packets. - Stream; Real Time Protocols (RTP) (used by e.g. VoIP) can be categorized based upon the very precise inter-packet gap (packets are not send back-to-back). Imagine that it might actually be possible to catch skype voice traffic. - Bulk; could be categorized by large packets being back-to-back. I propose this could be implemented with Netfilter target modules for categorizing traffic, and using conntrack flows for saving the group/type, that other rules can match upon. What can it be used for? Security/NIDS: Detecting backdoors, by identifying interactive on non-standard ports. QoS: Prioritize traffic based on type (e.g. interactive or RTP-streams) without needing to write static iptables rules to match each new protocols port number. Some protocols, like Skype, its not possible to do categorizing based upon standard port numbers. Is it possible? --- I actually got the idea from two scientific papers by Vern Paxson and Yin Zhang, where they actually detect interactive traffic by timing characteristic on real-life data. They use it for detecting backdoors and stepping stones. http://www.icir.org/vern/papers/backdoor/ http://www.icir.org/vern/papers/stepping/ http://citeseer.ist.psu.edu/zhang00detecting.html Cheers, Jesper Brouer http://www.adsl-optimizer.dk -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: dst cache overflow
On Wed, 10 Jan 2007, ArcosCom Linux User wrote: El Mie, 10 de Enero de 2007, 8:15, Patrick McHardy escribió: ArcosCom Linux User wrote: The log says: Dec 30 00:52:27 cura kernel: dst cache overflow The log message dst cache overflow is normally related to overflow of the route cache. The max_size of the route cache can be adjusted through /proc/sys/net/ipv4/route/max_size. What is your settings in /proc/sys/net/ipv4/route/? Run command: grep . /proc/sys/net/ipv4/route/* Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ---___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: dst cache overflow
The values looks reasonable, garbage collection start (gc_thresh:32768) fairly early, but I often see that the GC cannot keep up. The maximum size of the route cache max_size=524288 is okay, but it depends on the usage pattern. On my production systems I has increased max_size to 2 million, to keep up! Another interesting value is secret_interval:600, which is the interval the route cache is flushed, in seconds, that is 10 minuts. 524288/600 = 873 packet/sec to new destinations. You should realize that filling the route cache in 10 minuts can happen, as it only requires 873 packet/sec to new destinations. What to do next: Monitor the route cache, to see whats actually happening. The route cache counters are located in /proc/net/stat/rt_cache, but is not very human readable. Use the tool rtstat to monitor the route cache. The rtstat tool can be downloaded from Roberts site: ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat Cheers, Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- On Wed, 10 Jan 2007, ArcosCom Linux User wrote: Here are: # grep . /proc/sys/net/ipv4/route/* /proc/sys/net/ipv4/route/error_burst:5000 /proc/sys/net/ipv4/route/error_cost:1000 grep: /proc/sys/net/ipv4/route/flush: Operación no permitida /proc/sys/net/ipv4/route/gc_elasticity:8 /proc/sys/net/ipv4/route/gc_interval:60 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:32768 /proc/sys/net/ipv4/route/gc_timeout:300 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:524288 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:20 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:20480 /proc/sys/net/ipv4/route/secret_interval:600 El Mie, 10 de Enero de 2007, 16:01, Jesper Dangaard Brouer escribió: On Wed, 10 Jan 2007, ArcosCom Linux User wrote: El Mie, 10 de Enero de 2007, 8:15, Patrick McHardy escribió: ArcosCom Linux User wrote: The log says: Dec 30 00:52:27 cura kernel: dst cache overflow The log message dst cache overflow is normally related to overflow of the route cache. The max_size of the route cache can be adjusted through /proc/sys/net/ipv4/route/max_size. What is your settings in /proc/sys/net/ipv4/route/? Run command: grep . /proc/sys/net/ipv4/route/* Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
On Thu, 15 Jun 2006, jamal wrote: On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote: On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote: The other problem I see with this code is it is very tightly tied to ATM cell sizes, not to solving the generic question of packetisation. Others have made this point also. I can't speak for Jesper, but I did consider making it generic. I also have considered to make it generic, but choose to make my patch as non-intrusive as possible to the kernel (and try to handle as much in userspace as possible). Actually I do think that the kernel patch part is very generic. The patch simply allow us to align the rate table/array. With the kernel patch in place, we can work on the userspace TC program to support more and more types of exotic link layer modeling. The issue was that doing so would add more code, but I don't personally know of any real world situation that would use the generic solution. I didn't fancy the thought of arguing on these lists for code that no one would actually use. ;-) If someone could put up their hand and say Hey, I need this, then expanding the patch to accommodate them would be a pleasure. I like generic code too. It is probably doable by just looking at netdevice-type and figuring the link layer technology. Totally in user space and building the compensated for tables there before telling the kernel (advantage is no kernel changes and therefore it would work with older kernels as well). I think you have got the setup all wrong. The linux middlebox/router has two ethernet interfaces, one of the ethernet interfaces is connected to the ADSL modem. Thus, the linux ethernet card cannot determine that it is connected to an ADSL line. The patch is the solution to the classical problem people have when tryng to configure traffic control on an ADSL link? Q: The packet scheduling does not work all the time? A: Try to decrease to bandwidth. The issue here is, that ATM does not have fixed overhead (due to alignment and padding). This means that a fixed reduction of the bandwidth is not the solution. We could reduce the bandwidth to the worst-case overhead, which is 62%, I do not think that is a good solution... With the patch, you can now simply configure HTB to use the rate that was specified by the ISP. Please read chapter 6 (Achieving Queue Control) page 55-65, where I demonstrate that the naive approach of reducing bandwidth does not work, when the packet distribution change on the link. http://www.adsl-optimizer.dk/thesis/ Cheers, Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ 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
[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
[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 net/sock.h
#include net/act_api.h
-#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 *skb, struct Qdisc* sch
[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 EXCEEDACT[/NOTEXCEEDACT]
\n);
fprintf(stderr, New Syntax ACTIONTERM := conform-exceed
EXCEEDACT[/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.mpu = mpu
Re: [LARTC] Linux router performance
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). Cheers, Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- On Wed, 31 May 2006, Andreas John wrote: Hi, Maybe: Khan, Sohel; Waheed, Abdul (2003): High Performance Routing on PCshttp://www.ccse.kfupm.edu.sa/~sohel/networking/references/Routing.pdf A rule of thumb: - with current COTS hardware and (standard) PCI Bus, you can reach the maximum of the PCI bus bandwidth. That's 1 GB/s, e.h. two NICs with 500 Meg/s each ( one in and one out ) - with PCI-X and in the future PCI-express you'll for sure be able to reach more performance. I didnt find a sponsor for a test-lab yet :) - in DoS secnarios it may get worse :/ I heavily depends on driver type (polling and NAPI preferred). The problem with the performace is _always_ the number of interrupts, nothing else is a bottleneck (well, we didn't talk about thousands of iptables rules yet, but you ask for a 'maximum'). - The question you have to ask in high-performance scenarios is not MBit/s but MPPS (megapackets per seconds). FreeBSD and Linux broke the 1 MPPS barrier some time ago (on dual xeons). rgds, Andreas Fermín Galán Márquez wrote: 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
Re: [LARTC] HTB at 100+ Mbits/sec
On Mon, 15 May 2006, Larry Brigman wrote: On 5/14/06, Jesper Dangaard Brouer [EMAIL PROTECTED] wrote: On Fri, 12 May 2006, Muthukumar S wrote: cut Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. cut The kernel timer resolution does have an impact on the precision of HTB (the delay jitter). I have done some detailed studies in my master thesis. Which is located at: http://www.adsl-optimizer.dk/thesis/. looks like the site is down, at least for me. It is up again... I have just restarted apache, don't know why apache was dead... Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On Fri, 12 May 2006, Muthukumar S wrote: cut Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. cut The kernel timer resolution does have an impact on the precision of HTB (the delay jitter). I have done some detailed studies in my master thesis. Which is located at: http://www.adsl-optimizer.dk/thesis/. You should look at chapter 7. Read section 7.3.2 Timer Granularity (page 71) and section 7.3.3 Improving Granularity (page 73) Figure 7.8 (page 75), shows how the delay jitter bound is improved when changing the timer from HZ=100 to HZ=1500. For the discusion about, why the you need to reduce the bandwidth to less that the actual bandwidth, you should look at Chapter 6 Achieving Queue Control. Especially if you have an ADSL link. Greeting, Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch to allow for the ATM cell tax
On Fri, 3 Mar 2006, Russell Stuart wrote: On Thu, 2006-03-02 at 14:23 -0800, Stephen Hemminger wrote: I will put it in iproute2 commands when a definitive set of patches is sent to me. So far, it still looks like it needs some fine tuning. Yes, they need some fine tuning. My ultimate goal here is to get something into the main line that makes tc/htb work well for VOIP. I don't care whether it is my patch, or something else. Jesper's patch is more mature, and as such is probably the better starting point. The only problem with using them is this statement on his web site: Commercial use of my work including the ADSL-optimizer is not allowed without my knowledge and consent. The ADSL-optimizer will be released under the GNU public license. ... 4. Jesper clarifying the license on his patch. I'll simply drop this license restriction. Now it is release 100% under GPL. I just held a technical talk about the ADSL-optimizer (4/3-2006) at linuxforum.dk. Where I promised the audience that I would try to get the patches to the kernel and TC into the main line. It seem work on this front is already in progress, Cool! :-) Hilsen Jesper Brouer -- --- Master of Computer Science Cand. scient datalog Dept. of Computer Science, University of Copenhagen --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] equal bandwidth for all IPs
On Thu, 19 May 2005, ro0ot wrote: How can I set equal bandwidth of 512kbit downlink and 256kbit uplink for every single IP address of 254 IP addresses I have in my LAN? See: http://wipl-wrr.sourceforge.net/ The system is made by: Christian Worm Mortensen (worm at dkik.dk) To quote his announce email: The WRR scheduler is an extension to the Traffic Control/network bandwidth management part of the Linux kernels. The scheduler was developed to support distributing bandwidth on a shared Internet connection fairly between local machines. I know a couple of systems which are using WRR in production, but I have not tried it my self. Hilsen Jesper Brouer -- --- Research Assistant Dept. of Computer Science, University of Copenhagen E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21438 --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Qos with 2 internet connections problems
On Tue, 5 Apr 2005, Jason Boxman wrote: On Tuesday 05 April 2005 18:36, Francisco Pereira wrote: snip I would recommend reading the masters thesis of Jesper Dangaard Brouer at http://www.adsl-optimizer.dk/thesis/ Altough he didnt release software yet (there is some code patches in the pdf file) which could lead to the best solution, you could estimate the adsl overhead with real knowledge, and not like it says in some scripts (put x kbit less than the link bandwith, or 5% less,...) I have been eagerly awaiting the release of that software myself. Sorry, I have not released the software yet... I have been delayed by the birth of my little new daughter... have not gotten much sleep lately. (http://www.trykdenaf.dk/gallery/silke_fodsel) I can release the patches and a beta version of the scripts, if people will give me some feedback on the tar.gz distribution file and can live with too much debug information/output from the graph-module. One of my friends are trying out the tar.gz distribution file today. He will hopefully give me some positive feedback tomorrow, wether he succesfully can follow the install instruction and have a functional system. Hilsen Jesper Brouer -- --- Research Assistant and Network Administrator Dept. of Computer Science, University of Copenhagen E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21438 --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ADSL overhead patch (was: Qos with 2 internet connections problems)
On Wed, 6 Apr 2005, Andy Furniss wrote: Jason Boxman wrote: On Tuesday 05 April 2005 18:36, Francisco Pereira wrote: snip I would recommend reading the masters thesis of Jesper Dangaard Brouer at http://www.adsl-optimizer.dk/thesis/ Altough he didnt release software yet (there is some code patches in the pdf file) which could lead to the best solution, you could estimate the adsl overhead with real knowledge, and not like it says in some scripts (put x kbit less than the link bandwith, or 5% less,...) I have been eagerly awaiting the release of that software myself. (see my other excuse mail... ;-) I am testing a version at the moment based on Ed Wildgoose's - if that didn't work for you though, I can't see why this one should. Hmm, I just googled/looked at Ed Wildgoose's patch, and I is not correct/precise. You can read why my patch is correct/precise in Section 6.1.2 of the Thesis (which gives a description of the patch). Mine is for UK pppoatm but if you know your overheads it's easy to modify - Do you? there are tables in the doc linked to. In Chapter 5, I have tried to summarize the different types of encapsulation methods and their according overheads, for easy reference. Is is still a problem figuring out, which type of encapsulation your specific ADSL connection is using... Hilsen Jesper Brouer -- --- Research Assistant Dept. of Computer Science, University of Copenhagen E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21438 --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
