[LARTC] shaping on several ppp interfaces
hallo I have the following schema pptpd server, with clients connecting to it and getting access to inside LAN resources; however, there are some roaming clients that have huge files to download and so eating all the bandwidth how can I have the whole x kbps be available on a single ppp interface, if there are none up, and, in reverse, guarantee to all ppp interfaces up at a given time x/nr_ppp_interfaces_up kbps ? thanks, petre -- Petre Bandac Network Scientist - [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Class C network 223.255.255.x
Hi, Most networks are using either 10.x.x.x or 172.x.x.x or 192.168.x.x , but was curious If I can use the range 223.255.255.x for my backbone routing, this looks like a nice block to use as most ppl don't use this, specially if you build quite a big intranet what about the whole 223.x.x.x block, will this be used on the internet? sorry if its a stupid questions Thanks Sew ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Class C network 223.255.255.x
On Wed, 2006-04-12 at 14:52 +0200, the sew wrote: Most networks are using either 10.x.x.x or 172.x.x.x or 192.168.x.x , but was curious If I can use the range 223.255.255.x for my backbone routing, this looks like a nice block to use as most ppl don't use this, specially if you build quite a big intranet what about the whole 223.x.x.x block, will this be used on the internet? These are valid routable ip adresses, so you'd better not use them for your own purposes. What is wrong with the official private ranges? smime.p7s Description: S/MIME cryptographic signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: packet marking: only a ratio, not all
pfer wrote: Hi Andy! I haven't checked the iproute sources for that, but maybe I was not clear: What I need is not having ALL packets re-marked when they are overlimit, or sent to any class, etc.. I want them to be remarked at a ratio. (eg. 2%) And granularity is important, if I have to re-mark with a 20% ratio, I wish to remark every 5th, and not mark 20 continously at not mark other 80 continously. Hmm with the example you give of 3x10 feeding 1x10 egress I don't see how it's going to work as is - I googled RMD-QoS-NSLP and have to admit I know zero about that - so you are alot more qualified than me WRT that. I can't really do more than list a few thoughts. What happens if ingress 2x egress. You want to mark every nth packet on egress but this will be before the flooded bottleneck - so you will then have to drop some of them. The example of 16mbit ingress going to 10mbit egress will not happen for long if tcp is involved - it will back off. Relating bandwidth use to packet counting will need the packets to all be the same size. (maybe doesn't matter for you) It may be doable - I just don't know and haven't played with actions enough to answer questions on that. One thought you could use IFB/IMQ or something to double queue so that the egress marker sees the traffic already cut down to 10mbit and there will be no further dropping. You'll still need to use state from ingress meters - or maybe your code for that. Thomas Graf wrote ematch which is in kernel (I don't know of any examples of usage, but the code has comments on how to write your own). He eventually wanted them to be able to do clever things like use meta data to control tc/classification I beleive. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] trying to find out how much is on a drive?
Yvon Dubinsky wrote: I have a Ferdora 2 machine with 2 drives in it one has the OS and the main drive for our Samba server on it and the other is the Mirror drive. What I am trying to find out is how much is on the primary drive. When I use the du command I get a number that seems to be off. I have the mirror drive mounted to the primary drive, and it apears as though when I do the du command from the root of the drive is adds in some of the files from the mirror drive. What I am trying to figure out is if there is a way to use the du command and exclude the mounted mirror drive in my total amount. I used the command du -ch, which gave the grand total in human form which is what I want but it seems to include the mirror drive also. How do I exclude it from adding in the mirror. Thanks, Have you tried df -h Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Detect and mark 'bulk' http traffic
Andrew Beverley wrote:
To give fast web browsing on my network, I prioritise http traffic by marking it
all into a high priority band ('30'). This generally works quite well, as
unidentified traffic such as p2p falls by default into a lower priority band
('40').
However, I would like to de-prioritise anyone doing large downloads over http,
which currently get high priority. Is there a way I can mark a connection
differently (ie into band '40') once it has got over a certain threshold of
date transfer?
If you use netfilter you can use connbytes for this.
Andy.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] created new q_disc, inserted module, tc tells me unknown qdisc
George P Nychis wrote:
George P Nychis wrote:
Hi,
I am trying to install a proprietary qdisc made for research, it is not
publically released yet, however its been used several times so i know
it works.
The files included are: q_xcp.c: static int xcp_parse_opt() static int
xcp_print_opt() static int xcp_print_xstats() struct qdisc_util xcp_util
= { NULL, xcp . };
sch_xcp.c: static int xcp_enqueue() static int xcp_requeue() static struct
sk_buff * xcp_dequeue() struct Qdisc_ops xcp_qdisc_ops ={
NULL,NULL,xcp, };
printk(KERN_INFO XCP qdisc module loaded.\n); return
register_qdisc(xcp_qdisc_ops);
So, i make everything successfully, it creates q_xcp.so and copies it
to /usr/lib and sch_xcp.o which it copies to /lib/modules/... so then I
insmod sch_xcp and i see in dmesg: XCP qdisc module loaded.
I then try: tc qdisc add dev eth0 root xcp capacity 10Mbit limit 500
and get: Unknown qdisc xcp, hence option capacity is unparsable
So then I read the INSTALL further to find some sort of solution and it
mentions: This again assumes tc version is 2.4.7. If your tc is a
different version, download the iproute2 source code, and edit Makefile
to point TC_INCLUDE to -I/iproute2/include -I/iproute2/tc
So, i did that, and i recompiled the q_xcp.so: lanthanum-ini src-1.0.1 #
make q_xcp.so cc -O2 -fPIC
-I/var/tmp/portage/iproute2-2.6.11.20050310-r1/work/iproute2-2.6.11/inc
lude/
-I/var/tmp/portage/iproute2-2.6.11.20050310-r1/work/iproute2-2.6.11/tc_
include -o q_xcp.o -c q_xcp.c ld -shared -o q_xcp.so q_xcp.o rm -f
q_xcp.o
But i still get the same error so then my very final last effort
was to move q_xcp.c to my iproute2 source code tc/ directory and added
this to the makefile: TCMODULES += q_xcp.o
Then I compiled tc, and i check tc to see if the xcp qdisc functions
were loaded: lanthanum-ini tc # nm tc | grep xcp 080531ec t xcp_parse_opt
080533e0 t xcp_print_opt 08053426 t xcp_print_xstats 08070cc0 D xcp_util
And finally: lanthanum-ini tc # ./tc qdisc add dev ath0 root xcp
capacity 54Mbit limit 500 Unknown qdisc xcp, hence option capacity
is unparsable
I have no clue :( I figured that putting the .so into /usr/lib would
have been enough. Sorry for the long e-mail, I hope someone can help,
and thank you for your time even if you don't know the solution but
read this :)
- George
George,
Please show us iproute/include/linux/pkt_sched.h
There shouldn't be anything there the author wishes to keep private. --
gypsy
They did not include the iproute source code that they used... they only
included the q_xcp.c to create the q_xcp.so ... therefore my pkt_sched.h i am
using is from this build: iproute2-2.6.11.20050310-r1
I can certainly post it if you need, just let me know
George,
Then you probably need to revert to an iproute2 source that included
xcp. In pkt_sched.h you need a struct that defines the parameters xcp
can accept:
enum
{
TCA_XCP_PARM1,
TCA_XCP_PARM2,
TCA_XCP_PARM3,
};
and in ~/tc/Makefile you need TCMODULES += q_xcp.o
--
gypsy
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and default qdisc backlog
James Nelson wrote: Thanks for all of your help Patrick! Just so I'm clear. If hfsc at the class level shows no overlimits and no packet dropps, then hfsc is not effecting my traffic any different (from a throughput perspective computational computer slowness aside) then if i had no traffic shapping in place? Noting what Patrick says as a caveat. But if you set up a rt class in hfsc at the moment (it may change soon) you can sort of get a feel for what's gone on historically by looking at the requeue counters (can't remember if tc -s class ls will do or tc -s qdisc ls with child queues on the class is needed). If you have a rt class you probably don't want it to ever be backlogged - it won't be very rt anymore (OK you could have short queue drop). If a rt class has become backlogged in the past then you will see requeues - it may not be perfect, but I would say big number = bad, 0 = good. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] trying to find out how much is on a drive?
Try 'du -chsx /*'. This should exclude other filesystems. On 12/04/06, Andy Furniss [EMAIL PROTECTED] wrote: Yvon Dubinsky wrote: I have a Ferdora 2 machine with 2 drives in it one has the OS and the main drive for our Samba server on it and the other is the Mirror drive. What I am trying to find out is how much is on the primary drive. When I use the du command I get a number that seems to be off. I have the mirror drive mounted to the primary drive, and it apears as though when I do the du command from the root of the drive is adds in some of the files from the mirror drive. What I am trying to figure out is if there is a way to use the du command and exclude the mounted mirror drive in my total amount. I used the command du -ch, which gave the grand total in human form which is what I want but it seems to include the mirror drive also. How do I exclude it from adding in the mirror. Thanks, Have you tried df -h Andy. ___ 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] Re: packet marking: only a ratio, not all
Hello! Well I won't go into protocol details, but I do not care if an intra-domain node will be congested via packets on ingress. I will drop them, but check with tc .. show .. how much I get on byte-level. Based on this, and maximum egress transmission rate of this congested node, I calculate Overload%, and remark leaving packets at that ratio. Anyway this setup will serve as a demo, having reservations thoughout the domain for UDP video packet streams only. I wrote to netdev-linux mailing list about how to hack in the sources of tc something like: for every packet if(rand()(percent/100)) do_action ,where rand() gives a float of 0..1 but haven't got any answer yet. I'm pretty much confused where an action gets executed, and how for.ex. random determ 2 modifies that. I will check this ematch stuff, but doesn't sound me the solution. I just thought this ratio-marking stuff to be a little less exotic and people already doing it. Could you point me to someone who will probably help me with this? Thanks, Ferenc --- Andy Furniss [EMAIL PROTECTED] wrote: pfer wrote: Hi Andy! I haven't checked the iproute sources for that, but maybe I was not clear: What I need is not having ALL packets re-marked when they are overlimit, or sent to any class, etc.. I want them to be remarked at a ratio. (eg. 2%) And granularity is important, if I have to re-mark with a 20% ratio, I wish to remark every 5th, and not mark 20 continously at not mark other 80 continously. Hmm with the example you give of 3x10 feeding 1x10 egress I don't see how it's going to work as is - I googled RMD-QoS-NSLP and have to admit I know zero about that - so you are alot more qualified than me WRT that. I can't really do more than list a few thoughts. What happens if ingress 2x egress. You want to mark every nth packet on egress but this will be before the flooded bottleneck - so you will then have to drop some of them. The example of 16mbit ingress going to 10mbit egress will not happen for long if tcp is involved - it will back off. Relating bandwidth use to packet counting will need the packets to all be the same size. (maybe doesn't matter for you) It may be doable - I just don't know and haven't played with actions enough to answer questions on that. One thought you could use IFB/IMQ or something to double queue so that the egress marker sees the traffic already cut down to 10mbit and there will be no further dropping. You'll still need to use state from ingress meters - or maybe your code for that. Thomas Graf wrote ematch which is in kernel (I don't know of any examples of usage, but the code has comments on how to write your own). He eventually wanted them to be able to do clever things like use meta data to control tc/classification I beleive. Andy. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] dsmark qdisc does not go without set_tc_index
Hi all! Anyone got the same problem? If I: tc qdisc add dev eth0 handle 1:0 root dsmark indices 4 set_tc_index it works fine. If I: tc qdisc add dev eth0 handle 1:0 root dsmark indices 4 it says: RTNETLINK answers: Invalid argument I just don't need that set_tc_index stuff for marking. Ferenc __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] please ignore my last mail
Ugh, it was some odd iproute version problem. 2-6-15 works fine. Sorry __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QoS - Ping problem
Nataniel Klug wrote: # Regras para a placa eth1 #-- $TC qdisc add dev $DL root handle 1: htb default 50 You are using htb default on eth - unless you make a filter for arp it will also end up in 1:50 which may or may not be the problem - you should fix it anyway. tc filter add . protocol arp u32 match u32 0 0 or stop using htb default class and make a catch all ip filter to send the rest to 50. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ESFQ not so fair?
Hello! I am using since yesterday ESFQ instead of N HTB queues. It mostly works OK, but when somebody is using one single sesion (for example downloading file via FTP), it gets weird speed. For example it is 20 kilobytes pres second, then drops down to 9, then 20 again, and then slowly to 0 and stops. But when using download accelererator of some kind or bittorrent client which uses many connections, speed seems to be stable. I am using esfq that way: qdisc add dev eth0 parent 1:4 handle 4:0 esfq perturb 600 hash fwmark divisor 13 qdisc add dev eth1 parent 1:2 handle 2:0 esfq perturb 600 hash dst divisor 13 On eth0 every IP is marked with different value by IPMARK module. On eth1 it is not necessary so I use dst hash. I have more values than 2^13 so I can't use direct hash. Any ideas? Is it possible to use bigger divisor or algorithm is not designed to deal with bigger hash? Any ideas will be appreciated! -- 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
Re: [LARTC] QoS - Ping problem
Andy, I will try to make this rule and see what happens. Thanks. Att, Nataniel Klug Andy Furniss escreveu: Nataniel Klug wrote: # Regras para a placa eth1 #-- $TC qdisc add dev $DL root handle 1: htb default 50 You are using htb default on eth - unless you make a filter for arp it will also end up in 1:50 which may or may not be the problem - you should fix it anyway. tc filter add . protocol arp u32 match u32 0 0 or stop using htb default class and make a catch all ip filter to send the rest to 50. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems matching by mac address
Adam M. Towarnyckyj wrote: Sorry for bumping this one, but I wanted to know if anyone else had any ideas as well. I'm a bit baffled as to why this isn't working. Thanks. Hmm this is a strange one - I tried both ip and mac version of your script (on non-bridged eth) and both work ie the traffic ends up in htb 12:10 and gets shaped. I tested with proftpd as sender - it's going to be important to test both with the same app that sets tos bits for prio - probably also worth putting a bfifo on 1:3 just for stats as default prio is three band. Now what I don't get is in both cases if I do tc -s filter ls parent 12:0 I don't get any matches, so would have expected them to have gone through htb as default - unshaped not 12:10 - strange. Will have to think/try different kernel and tc versions. Did you do both tests with the same tos bit setting sender app? Alexey's point about filtering to 12:0 is because normally if you set up a tree structure for filters you need a filter rule on root to pass traffic down to child(ren) - prios automatic filtering seems to do it - but not as I expected. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Michał Margula wrote: Hello! I am using since yesterday ESFQ instead of N HTB queues. It mostly works OK, but when somebody is using one single sesion (for example downloading file via FTP), it gets weird speed. For example it is 20 kilobytes pres second, then drops down to 9, then 20 again, and then slowly to 0 and stops. But when using download accelererator of some kind or bittorrent client which uses many connections, speed seems to be stable. I am using esfq that way: qdisc add dev eth0 parent 1:4 handle 4:0 esfq perturb 600 hash fwmark divisor 13 qdisc add dev eth1 parent 1:2 handle 2:0 esfq perturb 600 hash dst divisor 13 On eth0 every IP is marked with different value by IPMARK module. On eth1 it is not necessary so I use dst hash. I have more values than 2^13 so I can't use direct hash. Any ideas? Is it possible to use bigger divisor or algorithm is not designed to deal with bigger hash? Any ideas will be appreciated! Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Corey Hickey wrote: In a recent thread on this list, Robert Kurjata provided me a patch to add hashing by iptables mark to the Linux 2.4 version of ESFQ. Thanks to that contribution, I was able to easily add support to the 2.6 port I maintain. I found out, however, that the existing hash algorithm results in a lot of colllisions when the range of hashed values is small. The purturbation spreads the collisions out a little, but the result still wasn't very fair, especially when hashing only three fwmark values: 0, 1 and 2. So, I wrote an alternative hash function. It's quite simple, and as long as the range of input values is smaller than the hash table (default 1024, up to 16384), collisions will not happen at all. See the updated README file for more details. Home page: http://fatooh.org/esfq-2.6/ Direct URL: http://fatooh.org/esfq-2.6/esfq-2.6.13.tar.gz README (also available in the tar.gz): http://fatooh.org/esfq-2.6/current/README Try it out, have fun, and if you find a bug or have a suggestion please send me an email. -Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Patrick McHardy wrote: Andy Furniss wrote: Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Using jhash is a probably a good idea, the improved hash is broken and will cause reordering in some circumstances: return (h - q-dyn_min) * (q-hash_divisor - 1) / q-dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. Oops I thought he did use jhash don't know where I got that from. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Michał Margula wrote: Andy Furniss napisał(a): Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Thanks, but I am already using his patch :-). It happens with that patch, I haven't tried original version at all. Ahh OK - looks like Patrick spotted the problem I guess Corey will see this thread. His limit is 2^14 though, which is why I thought you must be using a different one. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Problems matching by mac address
Andy, Thanks for investigating so extensively. However, I'm an idiot and made a fundamental mistake in networking that I should have realized in the first place. I completely didn't think about the fact that the filter is looking at the data link layer of the packet and that this gets changed through each device. The test machine is set up behind a router. Also, to answer your question, I'm using a download test app on a web server I set up, so I'm basically using the same program for testing the throughput each time. Sorry if I wasted anyone's time on this. With me, it's always something obvious I missed and usually I don't realize until after I have investigated every FAQ, Googled the hell out of the question, and posted to a list. If anyone has any ideas on how I can accomplish destination mac address filtering through multiple hops, I'd love to hear them. Otherwise, I think I'm going back to the drawing board on this one. Adam Interesting Outlook doesn't recognize Googled as a verb... -Original Message- From: Andy Furniss [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 2:11 PM To: Adam M. Towarnyckyj Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] Problems matching by mac address Adam M. Towarnyckyj wrote: Sorry for bumping this one, but I wanted to know if anyone else had any ideas as well. I'm a bit baffled as to why this isn't working. Thanks. Hmm this is a strange one - I tried both ip and mac version of your script (on non-bridged eth) and both work ie the traffic ends up in htb 12:10 and gets shaped. I tested with proftpd as sender - it's going to be important to test both with the same app that sets tos bits for prio - probably also worth putting a bfifo on 1:3 just for stats as default prio is three band. Now what I don't get is in both cases if I do tc -s filter ls parent 12:0 I don't get any matches, so would have expected them to have gone through htb as default - unshaped not 12:10 - strange. Will have to think/try different kernel and tc versions. Did you do both tests with the same tos bit setting sender app? Alexey's point about filtering to 12:0 is because normally if you set up a tree structure for filters you need a filter rule on root to pass traffic down to child(ren) - prios automatic filtering seems to do it - but not as I expected. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: packet marking: only a ratio, not all
pfer wrote: Hello! Well I won't go into protocol details, but I do not care if an intra-domain node will be congested via packets on ingress. I will drop them, but check with tc .. show .. how much I get on byte-level. Based on this, and maximum egress transmission rate of this congested node, I calculate Overload%, and remark leaving packets at that ratio. OK I guess you know what you want - just thinking there wouldn't be much overload% if tcp was about and you were dropping. Anyway this setup will serve as a demo, having reservations thoughout the domain for UDP video packet streams only. I wrote to netdev-linux mailing list about how to hack in the sources of tc something like: for every packet if(rand()(percent/100)) do_action ,where rand() gives a float of 0..1 If that's userspace tc it may be OK - no floats in kernel code AFAIK. Could you point me to someone who will probably help me with this? I think netdev is the right place. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ESFQ not so fair?
Patrick McHardy wrote: Andy Furniss wrote: Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his announce below. Andy. Corey Hickey wrote: So, I wrote an alternative hash function. It's quite simple, and as long as the range of input values is smaller than the hash table (default 1024, up to 16384), collisions will not happen at all. See the updated README file for more details. Using jhash is a probably a good idea, the improved hash is broken and will cause reordering in some circumstances: return (h - q-dyn_min) * (q-hash_divisor - 1) / q-dyn_range; dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted dynamically, so the hash function changes whenever one of these values changes, resulting in reordering of packets belonging to a single flow. That should stabilize after it's been running a while and has seen the normal range of IP addresses. Anyway, I agree, it's not very good. Working on ESFQ some more has been on my long-term TODO list, but what with getting distracted by mplayer development I didn't get around to it... and now I have 1.2 real jobs and 1.0 girlfriends and don't have time for much programming. :) If any of you want to send patches to this list and they don't look bad to other readers of the list I'll happily apply them and make a new release. Other than that, I can't help you much for now. Thanks, Corey ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] created new q_disc, inserted module, tc tells me unknown qdisc
George P Nychis wrote:
George P Nychis wrote:
Hi,
I am trying to install a proprietary qdisc made for research, it is
not publically released yet, however its been used several times so
i know it works.
The files included are: q_xcp.c: static int xcp_parse_opt() static
int xcp_print_opt() static int xcp_print_xstats() struct qdisc_util
xcp_util = { NULL, xcp . };
sch_xcp.c: static int xcp_enqueue() static int xcp_requeue() static
struct sk_buff * xcp_dequeue() struct Qdisc_ops
xcp_qdisc_ops ={ NULL,NULL,xcp, };
printk(KERN_INFO XCP qdisc module loaded.\n); return
register_qdisc(xcp_qdisc_ops);
So, i make everything successfully, it creates q_xcp.so and copies
it to /usr/lib and sch_xcp.o which it copies to /lib/modules/... so
then I insmod sch_xcp and i see in dmesg: XCP qdisc module
loaded.
I then try: tc qdisc add dev eth0 root xcp capacity 10Mbit limit
500 and get: Unknown qdisc xcp, hence option capacity is
unparsable
So then I read the INSTALL further to find some sort of solution
and it mentions: This again assumes tc version is 2.4.7. If your
tc is a different version, download the iproute2 source code, and
edit Makefile to point TC_INCLUDE to -I/iproute2/include
-I/iproute2/tc
So, i did that, and i recompiled the q_xcp.so: lanthanum-ini
src-1.0.1 # make q_xcp.so cc -O2 -fPIC
-I/var/tmp/portage/iproute2-2.6.11.20050310-r1/work/iproute2-2.6.11
/inc lude/
-I/var/tmp/portage/iproute2-2.6.11.20050310-r1/work/iproute2-2.6.11
/tc_ include -o q_xcp.o -c q_xcp.c ld -shared -o q_xcp.so q_xcp.o rm
-f q_xcp.o
But i still get the same error so then my very final last
effort was to move q_xcp.c to my iproute2 source code tc/ directory
and added this to the makefile: TCMODULES += q_xcp.o
Then I compiled tc, and i check tc to see if the xcp qdisc
functions were loaded: lanthanum-ini tc # nm tc | grep xcp 080531ec
t xcp_parse_opt 080533e0 t xcp_print_opt 08053426 t xcp_print_xstats
08070cc0 D xcp_util
And finally: lanthanum-ini tc # ./tc qdisc add dev ath0 root xcp
capacity 54Mbit limit 500 Unknown qdisc xcp, hence option
capacity is unparsable
I have no clue :( I figured that putting the .so into /usr/lib
would have been enough. Sorry for the long e-mail, I hope someone
can help, and thank you for your time even if you don't know the
solution but read this :)
- George
George,
Please show us iproute/include/linux/pkt_sched.h
There shouldn't be anything there the author wishes to keep private.
-- gypsy
They did not include the iproute source code that they used... they
only included the q_xcp.c to create the q_xcp.so ... therefore my
pkt_sched.h i am using is from this build: iproute2-2.6.11.20050310-r1
I can certainly post it if you need, just let me know
George,
Then you probably need to revert to an iproute2 source that included xcp.
In pkt_sched.h you need a struct that defines the parameters xcp can
accept:
enum { TCA_XCP_PARM1, TCA_XCP_PARM2, TCA_XCP_PARM3, };
and in ~/tc/Makefile you need TCMODULES += q_xcp.o -- gypsy
I think what I'm most confused about this pkt_sched.h thing is that the code
works with version 2.4.7 of iproute2 ... in 2.4.7 of iproute2 there is no
pkt_sched.h anywhere to be found in the source code.
However in the newest version of iproute2 which I am trying to get this
functionality to work in, there is a pkt_sched.h
My last observation, is that in q_xcp.h it includes pkt_sched_xcp.h which has:
struct tc_xcp_qopt
{
__u32 first_param;
__u32 second_param;
};
So I am assuming i need to add something like the enum thing to pkt_sched.h in
the new iproute2 source... however what are the proper names I need to use in
the enum? I don't expect you to know the names, however, what do i match them
with?
Thanks!
George
--
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
