[LARTC] Re: [PATCH] HTB O(1) class lookup
On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote: On Monday 05 February 2007 11:16, Jarek Poplawski wrote: On 01-02-2007 12:30, Andi Kleen wrote: Simon Lodal [EMAIL PROTECTED] writes: Memory is generally not an issue, but CPU is, and you can not beat the CPU efficiency of plain array lookup (always faster, and constant time). Probably for some old (or embedded) lean boxes used for small network routers, with memory hungry iptables - memory could be an issue. Sure, but if they are that constrained they probably do not run HTB in the first place. We are talking about 4k initially, up to 256k worst case (or 512k if your router is 64bit, unlikely if small is a priority). And the worst memory consumption case considered by Patrick should be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. The current hash algorithm also assumes certain usage patterns, namely that you choose classids that generate different hash keys (= distribute uniformly across the buckets), or scalability will suffer very quickly. Even at 64 classes you would probably see htb_find() near the top of a profiling analysis. But I would say that it is just as unlikely as choosing 64 classids that cause my patch to allocate all 256k. In these unlikely cases, my patch only wastes passive memory, while the current htb wastes cpu to a point where it can severely limit routing performance. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. I decided not to do it because it would mean too many ifdefs (ugly+unmaintanable code). As a matter of fact Andi's recommentation is enough for me. In his first message he wrote probably the right data structure for this, so I thought: why not test and make sure. It should be easier without removing current solution. But his second message convinced me. Generally I think 512k (or even 256k) should matter and don't agree HTB is not for constrained ones. It could be dangerous attitude if every module in the kernel were so generous. And it could be contagious: others don't care - why should I? Some time ago low memory requirements and possibility to run on older boxes were strong arguments for linux. Did we give it up to BSDs? So I only wanted to make sure there would be a real gain, because, for consistency, probably the same model should be used with others (CBQ, HFSC). Cheers, Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] HTB O(1) class lookup
On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote:
...
Regards
...
It seems decisions makers need more time, so I'd add
2 cents more:
1c: an indentation could be improved (spaces around
operators), like in these places:
+#define HTB_MAX_CLS (TC_H_MIN(-1)+1)
...
+ htb_cls_array* a;
...
+ int cnt,done;
etc.
2c: it is a question of taste, but here:
err = -ENOBUFS;
+ if (q-classes[HTB_CLS_ARRAY(minorid)] == NULL) {
+ if ((q-classes[HTB_CLS_ARRAY(minorid)] =
+ kzalloc(sizeof(htb_cls_array), GFP_KERNEL))
+ == NULL)
+ goto failure;
+ }
if ((cl = kzalloc(sizeof(*cl), GFP_KERNEL)) == NULL)
goto failure;
it would be probably more readable and a bit merciful
to the stressed system to free this htb_cls_array after
the last error (I know it's not a leak).
Regards,
Jarek P.
PS: 1c extra - it's easier to read a diff if you use -p option.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] HTB O(1) class lookup
On 01-02-2007 12:30, Andi Kleen wrote: Simon Lodal [EMAIL PROTECTED] writes: Memory is generally not an issue, but CPU is, and you can not beat the CPU efficiency of plain array lookup (always faster, and constant time). Probably for some old (or embedded) lean boxes used for small network routers, with memory hungry iptables - memory could be an issue. Actually that's not true when the array doesn't fit in cache. The cost of going out to memory over caches is so large (factor 100 and more) that often algorithms with smaller cache footprint can easily beat algorithms that execute much less instructions if it has less cache misses. That is because not all instructions have the same cost; anything in core is very fast but going out to memory is very slow. That said I think I agree with your analysis that a two level array is probably the right data structure for this and likely not less cache efficient than the hash table. Strange - it seems you gave only arguments against this analysis... And the worst memory consumption case considered by Patrick should be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. Regards, Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: tc filter
On 18-08-2006 12:28, Andy Furniss wrote: Jarek Poplawski wrote: Should be: # tc filter add dev eth0 parent 1: proto ip pref 100 \ u32 match ip dst 192.168.1.222 flowid 1: police \ conform-exceed drop/drop Looks a bit iffy but I haven't tried it - I thought that would be drop whether under or over - if it's valid at all without action/ a police rate. Maybe I should have written: Should be with a fairly current iproute2 and kernel:. It's so called New syntax (Old syntax didn't work for me), to add exceed action for zero rate. According to help rate and burst should be included, but it works anyway. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Routing packets over multiple links (NICS) all on the same ISP all with same gateway.
On 16-08-2006 16:18, Jacques Rompen wrote: On 8/16/06, *Jarek Poplawski* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: As far as I know multipath cached should work for routing output of a current box but it's not working for router (if something has not changed lately). Multipath without cached should do simple randomization, but maybe for the begining it would be better to assign fixed paths by source ip and save experimenting with multipaths for later. Jarek P. Hi Jarek, I will try with only multipath. Ive tried the static routes. But still ive had trouble getting this code to work ip ro add default nexthop via x.x.x.x dev eth1 weight 1 nexthop via y.y.y.y dev eth2 ip route add default table provider1 via x.x.x.x dev eth1 ip route add default table provider2 via y.y.y.y dev eth2 because x.x.x.x = y.y.y.y in my case. Somehow it doesnt look at the eth device anymore. Anyway in my opinion it should work. Try something like this: #IP_ROUTE_MULTIPATH = y #(if 2.6.x IP_ROUTE_MULTIPATH_CACHED = n !) #Here with CONNMARK method (so without Anastasov's patch!). #Change 192.168.0.0/24 and eth0 to your local network #address/mask and interface. ip route add default nexthop via x.x.x.x dev eth1 \ nexthop via x.x.x.x dev eth2 ip route add 192.168.0.0/24 dev eth0 table 101 ip route add default via x.x.x.x dev eth1 table 101 ip route add 192.168.0.0/24 dev eth0 table 102 ip route add default via x.x.x.x dev eth2 table 102 ip rule add fwmark 1 table 101 ip rule add fwmark 2 table 102 iptables -t mangle -A POSTROUTING -o eth1 -j MARK --set-mark 1 iptables -t mangle -A POSTROUTING -o eth2 -j MARK --set-mark 2 iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark echo 0 /proc/sys/net/ipv4/conf/all/rp_filter You should also add NAT (MASQERADE) rules. Nexthop devices will be changed randomly per flow (with some caching) so try with destinations from different networks. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Routing packets over multiple links (NICS) all on the same ISP all with same gateway.
On 14-08-2006 17:42, Jacques Rompen wrote: ... What we want to do is the following: I live in a student complex with 7 other people. Every room has its own internet connection from the same ISP. Ip, gateway, subnet are asigned through dhcp on mac-adres basis. Every internet connection is capped at 20mbit up/down. We want to get all computers on an internal network. So we need some sort of router that accepts all 8 internet connections and routes it out over a gbit nic - switch - internal network So we have a computer with 10 nics and hopefully enough internal bandwith. Maybe you have some other reasons to make one gateway but to have internal network you only need to set a second address from local range (not colliding with that used by ISP) on each box. But if you really need this together and with multipath, setting CONFIG_IP_ROUTE_MULTIPATH = y and CONFIG_IP_ROUTE_MULTIPATH_CACHED = n (!) should change multipath randomly. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: tc filter
On 10-08-2006 15:38, Jarek Poplawski wrote: ... # tc filter add dev eth0 parent 1: proto ip pref 100 \ u32 match ip dst 192.168.1.222 police drop Should be: # tc filter add dev eth0 parent 1: proto ip pref 100 \ u32 match ip dst 192.168.1.222 flowid 1: police \ conform-exceed drop/drop or: # tc filter add dev eth0 parent 1: proto ip pref 100 \ u32 match ip dst 192.168.1.222 flowid 1: action drop Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Routing packets over multiple links (NICS) all on the same ISP all with same gateway.
On 16-08-2006 14:50, Jacques Rompen wrote: ... The 2 ips on every box wouldnt work because: Most people here are complete network newbies, we want to connect more then 8 computers (most people have a laptop and pc), we would only have a 20mbit internal network. Im a bit confused. In the 2.4 kernel there issent even an option ip_route_multipath_cached, only ip_route_multipath. Or am i mistaking here? If there issent, then I couldnt have put it to 'Y' so why didnt the random function work? In the 2.6 kernel there is a option ip_route_multipath and ip_route_multipath_cached. But if i dont say 'Y' to ip_route_multipatch_cached i cant say yes to round_robin, random_match etc. I thought i needed that option random_match set to 'y'. (im not sure if its exactly spelled like that, but i'm talking about the four or five sub options to ip_route_multipath_cached) As far as I know multipath cached should work for routing output of a current box but it's not working for router (if something has not changed lately). Multipath without cached should do simple randomization, but maybe for the begining it would be better to assign fixed paths by source ip and save experimenting with multipaths for later. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: how to save iproute
On 01-08-2006 11:28, Oscar Mechanic wrote: Say if I have a few routes like this ip rule add from 19.21.12.12 lookup 200 ip route add default via 10.0.0.253 ip rule add to 13.1.2.2 lookup 201 ip route add default via 10.0.0.254 ip route add default via 10.0.0.254 How do I save them, I have looked through the list and have googled this Q for some time and do not have an concrete answers. I have read that you just save and rerun the command but that does not work as the from all to is not valid it has to be the to without the from all. I have used multiple versions of iproute2 and still the same problem. I written a script and put in many sed's to get around problems but its nasty code. Surely someone solved this is there a saveall script or bin that is distro independant. Maybe I miss your point, but ip doesn't care if you write a command by hand (from shell) or run it from a shell script. If you don't use from ..., it is the same as if you've written from all. It doesn't contradict with to ... which is another parameter. After your last command there will be an error because it repeats the previous one. If you add in a script: set -x before the first command, you will see, which end with errors. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: tc filter
On 03-08-2006 18:06, doudouyam wrote: Hi, Is it possible to make a filter with tc which exclude an IP like iptables ?? ex: iptable -t mangle -A PREROUTING -i eth0 -d ! 192.168.1.222 http://192.168.1.222 -j MARK ... Maybe there is something like this, I don't know, but you can try two filters in turn e.g.: # tc filter add dev eth0 parent 1: proto ip pref 100 \ u32 match ip dst 192.168.1.222 police drop (or some other flowid 1:xx instead of police drop) # tc filter add dev eth0 parent 1: proto ip pref 101 \ u32 match ip dst 192.168.1.0/24 flowid 1:99 Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Problem with iptables with -j TOS and MARK
On 28-07-2006 15:57, Jarek Poplawski wrote: On 28-07-2006 14:43, makevuy wrote: Hy, I would want to mark the packets that are entering in a machine, with a mark for using diffserv with DSMARK. My machine has 2 interfaces, a ethernet and a wireless. The ethernet interface is eth1 and the other is wifi0. Firs, I would want to test that I would be able to mark the tos of the paquets that I would be receiving, for this I write in the console of my linux: iptables -A PREROUTING -i eth1 -t mangle -p udp -j TOS --set-tos 0x20 But the TOS doesn't change (I see this with ethereal) Waht could be the problem? If I can remember, TOS is inserted for real some time later, so try to investigate on forward or postrouting. After short weekend testing my memory turned out to be faulty again - it can remember only every second bit (because it's old!). Iptables -j TOS and -j DSCP should change a tos field of ip headers at once (this could be seen with -j LOG everywhere after this setting). This field can influent the way a packet is classified by some qdisc like prio, but not directly - inner priority field is taken for this. And this priority is computed from tos only in forward. So probably ethereal showed packets before changes or you have some problem with iptables. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: problem in Route add using netlink
On 25-07-2006 16:59, VijayaLakshmi Seshadri wrote:
Hi all
Iam trying to implement route add using netlink. The changes are not
reflected in the routing table. I have given my code and screen shots of
the routing tables.
Can anybody tell me is there any mistake iam making in defining the fields .
or any other mistake iam commiting
thanxs
viji
I had some free time at the weekend - it's probably to late and I
hope you've found this bugs yet, but maybe someone else (like me)
will be looking here some day with similar problem, so here is
what I've found.
Jarek P
CODE
//
#include asm/types.h
#include netinet/ether.h
#include netinet/in.h
#include net/if.h
#include stdio.h
#include sys/socket.h
#include sys/ioctl.h
#include linux/netlink.h
#include linux/rtnetlink.h
#include sys/types.h
#define BUFSIZE 192
struct route_info{
u_int dstAddr;
u_int srcAddr;
u_int gateWay;
charifName[IF_NAMESIZE];
};
void fillRoute (struct route_info *rinfo, const char* dstAddr,
const char* srcAddr, const char* gateway, const char*
ifName)
{
/* Convert from the standrad numbers and dots notation
to binary data */
inet_aton(192.168.51.0, (struct in_addr *)rinfo-dstAddr);
inet_aton(192.168.51.90, (struct in_addr *)rinfo-gateWay);
}
Of corse you always have to be sure to have the valid route to
192.168.51.90 on the testing box...
int addAttr (struct nlmsghdr *nlhdr, int maxlen, int type,
void *data, int alen)
{
struct rtattr *rta;
int len = RTA_LENGTH(alen);
if (NLMSG_ALIGN(nlhdr-nlmsg_len) + len maxlen)
return -1;
rta = (struct rtattr*)((char *)nlhdr +
NLMSG_ALIGN(nlhdr-nlmsg_len));
rta-rta_type = type;
rta-rta_len = len;
memcpy(RTA_DATA(rta), data, alen);
nlhdr-nlmsg_len = NLMSG_ALIGN(nlhdr-nlmsg_len) + len;
return 0;
}
int main()
{
struct nlmsghdr *nlMsg;
struct rtmsg *rtMsg;
char dstAddr[30] ;
char srcAddr[30] ;
char gateway[30] ;
char ifName[30];
char msgBuf[BUFSIZE];
struct route_info rinfo;
int sock, len, msgSeq = 0;
int val, i;
/* Create Socket */
if((sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)) 0)
perror(Socket Creation: );
/* Initialize the buffer */
memset(msgBuf, 0, BUFSIZE);
/* point the header and the msg structure pointers into the
buffer */
nlMsg = (struct nlmsghdr *)msgBuf;
rtMsg = (struct rtmsg *)NLMSG_DATA(nlMsg);
/* Fill in the nlmsg header*/
nlMsg-nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg)); // Length
ofmessage.
nlMsg-nlmsg_type = RTM_NEWROUTE; // Get
the routes from kernel routing table .
nlMsg-nlmsg_flags = NLM_F_CREATE ; // The message is a
// the flag is needed here
nlMsg-nlmsg_flags = NLM_F_CREATE | NLM_F_REQUEST;
request for dump.
nlMsg-nlmsg_seq = msgSeq++; //
Sequence of the message packet.
nlMsg-nlmsg_pid = getpid(); // PID of
process sending the request.
rtMsg-rtm_family = AF_INET;
rtMsg-rtm_table = RT_TABLE_UNSPEC;
rtMsg-rtm_dst_len = 16;
rtMsg-rtm_src_len = 16;
// this should be address' lenghts in bits so:
rtMsg-rtm_dst_len = 32;
rtMsg-rtm_src_len = 32;
rtMsg-rtm_scope = RT_SCOPE_UNIVERSE;
rtMsg-rtm_type = RTN_UNICAST;
rtMsg-rtm_protocol = RTPROT_UNSPEC;
rtMsg-rtm_flags = RTM_F_NOTIFY;
fillRoute (rinfo, dstAddr, srcAddr, gateway, ifName);
addAttr (nlMsg, BUFSIZE, RTA_DST,
rinfo.dstAddr, 4);
addAttr (nlMsg, BUFSIZE, RTA_GATEWAY,
rinfo.gateWay, 4);
/* Send the request */
if((val = send(sock, nlMsg, nlMsg-nlmsg_len,0 )) 0){
printf(Write To Socket Failed...\n);
return -1;
}
printf ( No of Bytes sent %d \n, val);
printf ( Value that is sent \n );
for (i =0 ; i val ; i ++)
printf (%u, msgBuf[i]);
printf (\n);
close(sock);
return 0;
}
//
OUTPUT
[EMAIL PROTECTED] netlink_addroute.c -o addroute
[EMAIL PROTECTED] ./addroute
No of Bytes sent 44
Value that is sent
44000240044294967239880021616101008010429496723242949672085108050429496723242949672085190
//
SCREEN SHOTS
*Routing table before execution of program*
Kernel IP routing table
Destination
[LARTC] Re: problem in Route add using netlink
On 31-07-2006 09:03, Jarek Poplawski wrote: ... Of corse you always have to be sure to have the valid route to Cursed! I wish I could spel too: http://www.cherwell.org/of_corse_we_can_spel Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Weird HTB behaviour in 2.6.17
On 27-07-2006 19:45, Marlon Dutra wrote: Hello, ... http://mailman.ds9a.nl/pipermail/lartc/2005q3/016981.html In that post, there is another guy with the same problem, but with 2.6.11. I can't see any problem there! If this guy expected lower rate for 1:39 class, he should have lower the ceil. This class had much higher traffic then the other class and probably was borrowing just when this stats were prepared. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Problem with iptables with -j TOS and MARK
On 28-07-2006 14:43, makevuy wrote: Hy, I would want to mark the packets that are entering in a machine, with a mark for using diffserv with DSMARK. My machine has 2 interfaces, a ethernet and a wireless. The ethernet interface is eth1 and the other is wifi0. Firs, I would want to test that I would be able to mark the tos of the paquets that I would be receiving, for this I write in the console of my linux: iptables -A PREROUTING -i eth1 -t mangle -p udp -j TOS --set-tos 0x20 But the TOS doesn't change (I see this with ethereal) Waht could be the problem? If I can remember, TOS is inserted for real some time later, so try to investigate on forward or postrouting. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: What am I missing?
Ray Van Dolson rayvd at digitalpath.net writes: On a custom compiled Linux 2.6.13 kernel... # tc qdisc add dev ppp145 handle : ingress # tc filter add dev ppp145 parent : protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 384kbit burst 10k drop flowid :1 RTNETLINK answers: Invalid argument This works fine on a CentOS machine and my Fedora Core 2 box with default kernel. I'm trying to figure out what is missing in the custom built 2.6.13 kernel. strace isn't real helpful, and there doesn't appear to be a way to make tc present more useful error messages... Non ingress filtering works. Here's an excerpt from kernel config: ... Any ideas? Can paste entire kernel config if necessary. You didn't write anything about this box: distro or previous kernel. Maybe you should try to recompile or get newer version of iproute? Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: QoS doubt about network machine
Nataniel Klug nata at cnett.com.br writes: Hello all, I am with a doubt about QoS solution... I have a 4 Mbit backbone coming from the telco I use... This is the link I serve to my clients, so I make this classes: $TC qdisc add dev $DL root handle 1: htb default 60 CLASS=/sbin/tc class add dev $DL parent $CLASS 1: classid 1:1 htb rate 4096Kbit $CLASS 1:1 classid 1:10 htb rate 256Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:20 htb rate 256Kbit ceil 1024Kbit burst 15k $CLASS 1:1 classid 1:30 htb rate 2048Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k $CLASS 1:1 classid 1:50 htb rate 256Kbit ceil 256Kbit burst 15k $CLASS 1:1 classid 1:60 htb rate 1024Kbit ceil 2048Kbit burst 15k ... So when my clients try to connect to my ns2 mail server it gets shapped by class 40... I dont want that to happens... So I think in making something like this: $TC qdisc add dev $DL root handle 1: htb default 60 CLASS=/sbin/tc class add dev $DL parent $CLASS 1: classid 1:1 htb rate 100Mbit $CLASS 1:1 classid 1:5 htb rate 100Mbit $CLASS 1:1 classid 1:10 htb rate 256Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:20 htb rate 256Kbit ceil 1024Kbit burst 15k $CLASS 1:1 classid 1:30 htb rate 2048Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k $CLASS 1:1 classid 1:50 htb rate 256Kbit ceil 256Kbit burst 15k $CLASS 1:1 classid 1:60 htb rate 1024Kbit ceil 2048Kbit burst 15k And them direct all traffic coming from my ns2 server (using u32 classifier and src address) to class 1:5... Is this correct? I don't think so. Class 1:5 can now take all bandwidth of dev here. You should limit it's rate and a ceil as a minimum, but I think you would better add it as another root class: CLASS=/sbin/tc class add dev $DL parent $CLASS 1: classid 1:1 htb rate 4096Kbit $CLASS 1: classid 1:5 htb rate 95Mbit $CLASS 1:1 classid 1:10 htb rate 256Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:20 htb rate 256Kbit ceil 1024Kbit burst 15k $CLASS 1:1 classid 1:30 htb rate 2048Kbit ceil 3072Kbit burst 15k $CLASS 1:1 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k $CLASS 1:1 classid 1:50 htb rate 256Kbit ceil 256Kbit burst 15k $CLASS 1:1 classid 1:60 htb rate 1024Kbit ceil 2048Kbit burst 15k And have a look at this bautiful page: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm The second advice is to lower you numbers. Probably this rates are only nominally like this and in reality min. 10% lower. If you don't limit it yourself they will be limited elsewhere and you will have higher delays. 15k burst is also quite high so possible next delays. Mr Devera has very good advices there. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] IMQ vs. local traffic
Andy Furniss lists at andyfurniss.entadsl.com writes: Jarek Poplawski wrote: PS: The included patch could be applied after linux-2.6.16-imq2 patch or eg. my yesterday version linux-2.6.17.4-imq0. I think this should go/cc to the IMQ list linuximq at yahoogroups.com http://groups.yahoo.com/group/linuximq/ Subscribe by mail and you won't get asked for a yahoo ID. Hello, I had this intention from the start but when I havn't seen any changes on the web site (from 2006-03-25), no activity on the group site for long time and no posibility to read any archives of that group, I thought maybe here would be some more interest. I've seen some patches here, so I dared to send mine. The second receiver was Andre Correa (I think he tries to save his address). After your mail I looked at this group site again and, miracuously, I see some activity today, so I'll take your advice and subscribe. Thanks, Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] [PATCH] IMQ vs. local traffic
Hello,
Some time ago I've read somewhere that local traffic in IMQ
could hung up the whole system but it was corrected long time
ago. So I was very surprised yesterday when it occurred not true.
While testing IMQ I've observed for some time that - if you tag
some local traffic with iptables both in pre- and postrouting -
kernel is hunging up. It is happening quite quick with SMP
compiled kernel but without SMP is also possible. After setting
soft lockups debbuging they are visible.
And then I've found this strange thing: packets outgoing from lo
to any local address are hooked to IMQ queue from PREROUTING (on
ingress). I know they are going there from OUTPUT for routing
decision and should be delivered to hooks in PREROUTING like IMQ,
but they also should not have IMQ flag set at the moment (they
will be tagged by iptables in the POSTROUTING future!). But for
some reasons (probably some shortcut) they do have this flag and
IMQ egress queue is not on their way.
So I added this short test in imq_nf_hook and my soft lockups
are gone.
Jarek P.
PS: The included patch could be applied after linux-2.6.16-imq2
patch or eg. my yesterday version linux-2.6.17.4-imq0.
diff -Nru linux-2.6.17.4-imq/drivers/net/imq.c
linux-2.6.17.4-imq2/drivers/net/imq.c
--- linux-2.6.17.4-imq/drivers/net/imq.c2006-07-11 22:00:00.0
+0200
+++ linux-2.6.17.4-imq2/drivers/net/imq.c 2006-07-12 22:15:51.0
+0200
@@ -234,7 +234,8 @@
const struct net_device *outdev,
int (*okfn)(struct sk_buff *))
{
- if ((*pskb)-imq_flags IMQ_F_ENQUEUE)
+ if ((*pskb)-imq_flags IMQ_F_ENQUEUE !(hook == NF_IP_PRE_ROUTING
+indev == loopback_dev))
return NF_QUEUE;
return NF_ACCEPT;
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] IMQ vs. local traffic
Jarek Poplawski wrote: ... And then I've found this strange thing: packets outgoing from lo to any local address are hooked to IMQ queue from PREROUTING (on ingress). I know they are going there from OUTPUT for routing decision and should be delivered to hooks in PREROUTING like IMQ, but they also should not have IMQ flag set at the moment (they will be tagged by iptables in the POSTROUTING future!). But for some reasons (probably some shortcut) they do have this flag and IMQ egress queue is not on their way. Bad diagnose! There is no shortcut. Only in my testing procedure: I've switched off the egress hook, so the IMQ flag traveled from POSTROUTING to PREROUTING not annoyed. I forgot it isn't the real device. Sorry for misleading. So I added this short test in imq_nf_hook and my soft lockups are gone. Nevertheles this method works. I dont't know why, yet. It exludes one direction of local traffic from queuing but who cares? Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] [PATCH] IMQ for linux-2.6.17.4 with behavior param
Hi, I see some inertion on www.linuximq.net, while kernels are at full speed, so here is my testing proposition for IMQ with: - some minor bugs removed in imq.c (like improper err handling while registering queue handler), - changes in ipt_IMQ.c and ip6t_IMQ.c to work with linux-2.6.17.4 (iptables-1.3.5), - added functionality to change behavior with module parameter (without recompiling). I hope it should work, but testing was very limited (ipv6 not tested). Best regards, Jarek P. linux-2.6.17.4-imq0.diff.tar.gz Description: GNU Zip compressed data ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Linux Qos : PRIO qdisc works
Sangho Lee wrote: Hi, all I am interested in Linux related QoS, especially PRIO queue discipline (qdisc). ... First question: The TCP stream with higher priority than UDP stream with lower priority experienced starvation in stead of UDP stream. Is it correct? ... All correct: man tc-prio: BUGS Large amounts of traffic in the lower bands can cause starvation of higher bands. Can be prevented by attaching a shaper (for example, tc-tbf(8) to these bands to make sure they cannot dominate the link. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: Not understanding network setup!!
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: -Original Message- From: Jarek Poplawski [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 9:57 AM To: Eliot, Wireless and Server Administrator, Great Lakes Internet Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] Re: Not understanding network setup!! ... Maybe we are thinking about something else but I don't think: If you were using a /30, then ... .5, and .9 would be the first available addresses in their respective subnets is all correct. 10.0.0.0/30: 10.0.0.0 - NETWORK ADDRESS 10.0.0.1 - HOST 10.0.0.2 - HOST 10.0.0.3 - BROADCAST ADDRESS First available address is .1 10.0.0.4/30: 10.0.0.4 - NETWORK ADDRESS 10.0.0.5 - HOST 10.0.0.6 - HOST 10.0.0.7 - BROADCAST ADDRESS First available address is .5 10.0.0.8/30: 10.0.0.8 - NETWORK ADDRESS 10.0.0.9 - HOST 10.0.0.10 - HOST 10.0.0.11 - BROADCAST ADDRESS First available address is .9 Thus: The .1, .5, and .9 would be the first available addresses in their respective subnets. Is a true statement. How are you interpreting this? OH! Now I understand! I'm sorry for bothering you and many thanks for this clare explaining. Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Not understanding network setup!!
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, June 01, 2006 2:58 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] Not understanding network setup!! Hi to all, ... First, 10.0.0.0/31 would be a network address. Second, a 31 bit subnet is meaningless. It only offers two addresses, the network address at 10.0.0.0 and the broadcast address at 10.0.0.1. That leaves no available addresses for host addresses. You probably mean /30 instead of /31. If you were using a /30, then you would run: ip addr add 10.0.0.1/30 dev eth1 ip addr add 10.0.0.5/30 dev eth2 ip addr add 10.0.0.9/30 dev teql0 The .1, .5, and .9 would be the first available addresses in their respective subnets. You probably mean /28 instead of /30: ip addr add 10.0.0.9/28 dev teql0 Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: For leaf classes is best PFIFO or SFQ?
Stefano Mainardi wrote: Hi to all, i'm following this guide (http://www.opalsoft.net/qos/DS-28.htm), is very detailed, but i'm a bit confused about queuing disciplinse of leaf classes. In this guide the author uses PFIFO (see the scheme that i attached at message) in this way: # tc class add dev eth0 parent 1:21 handle 210: pfifo lmit 10 rather that way: # tc qdisc add dev eth0 parent 1:21 handle 210: pfifo limit 10 Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] IMQ on KPTD
Hi! I would like to thank very much for this great page with Kernel Packet Traveling Diagram and to suggest small update concerning IMQ. I think the sentence: IMQ in input comes before nat so IMQ does not know the real ip address. Ingress comes after nat, so ingress knows the real ip address. could be more precise like that: By default IMQ in PREROUTING comes before nat and in POSTROUTING after nat, so in both cases IMQ knows ip addresses as masqueraded (nated) if it is used. This could be changed with kernel parameters IMQ_BEHAVIOR_??. My opinion is based on IMQ patch by Patrick McHardy from www.linuximq.net. Best regards, Jarek Poplawski ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
