Re: [LARTC] how to add my own traffic scheduler to TC
Thanks Roy, I found the answers. I didn't know I had to modify the kernel QoS library (which I did) as well as the iproute2 library (which I didn't). It is working now :) Thanks, Kennedy Roy wrote: TC is like iptables, you need to add suport to tc binary for your module, else you wont be able to configure it. I dont know how to do this , but try to find some analogy with other modules you will need to modify tc makefile, and add aditional module. - Original Message - From: Kennedy Cheng [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 5:17 PM Subject: [LARTC] how to add my own traffic scheduler to TC What are the steps needed to add my own traffic scheduler to TC? My understanding is that I need to do something in the net/sched/ directory: add a schedular eg sch_blue.c, change the Makefile, config.in and sch_api.c; add the appropriate qopt, xstats struct... in the include/linux/pkt_sched.h. I've got it all compiled without warnings or error. When I typed ''tc add dev eth0 root blue limit 1000kB..'', it complained ''Unknown qdisc ''blue'', hence option ''limit'' is unparsable''. When I typed ''tc add dev eth0 root red limit 1000kB.'', it worked fine (of course). The code I wrote was a complete copy of the sch_red.c, with text changed to blue instead of red. TC is not happy with my blue scheduler. What have I done wrong? Have I missed something? Linux Kernel version 2.4.20-8 Many Thanks, Kennedy ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] classless to classless qdisc
Is it possible to link 2 classless qdiscs in serial? For example, red as the root qdisc, with fifo as the child qdisc? Thanks, Kennedy ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: Blue and SFB
Nuutti Kotivuori wrote: Patrick McHardy wrote: There is a blue implementation for Linux at http://home.sch.bme.hu/~bartoki/projects/thesis/2001-May-26/ Nice! I briefly scanned the implementation and it didn't look too bad. Some oddities here and there (such as changing HZ from 100 to 1024??). Yes, it seems to be in a good form. The HZ change doesn't make much sense for a work-conserving scheduler, the PSCHED_CLOCK_SOURCE change is there to get a higher clock resolution. But, as the implementation is rather old, it would require a complete overhaul for 2.6 I think. It is a shame it wasn't worked in to the Linux kernel when it was still current, as I think the algorithm could have a lot of uses. I couldn't sleep this morning so I started to fix up the code for 2.6 ;) It's almost no work, the QoS-subsystem hasn't changed much since 2.4.3. I should be done today or tommorrow. What is the process of getting new traffic schedulers in the kernel? I guess most of the netfilter stuff goes through netfilter development and patch-o-matic - but there isn't anything similar for QoS, is there? No, there isn't. The usual way it to submit new stuff to netdev for discussion, if it is useful and of good quality it usually is accepted. Regards Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Preferring routing cache over ip rule
Hello! I have problem setting up some ip routing rules. Let's assume following network configuration: ___ server: 10.1.1.1 | eth1|-- ISP1 internal |eth0 | 10.1/16 | eth2|-- ISP2 10.2/16 | | | eth3|-- ISP3 |___| And following ip route rules All traffic from 10.1.1.1 via ISP1 All traffic from 10.1/16 via ISP2 All traffic form 10.2/16 via ISP3 So users' connections go via IPS2 or ISP3 and ISP1 is dedicated link for the server. It's quite good, but I have a problem I cannot overcome: When someone from the Internet wants to connect to 10.1.1.1 by the ISP2, the return packets goes via ISP1. And of course someone from the Internet drops those packets, as they don't come from the right IP address. I would like to have the followin: 1. traffic from 10.1.1.1 goes via ISP1 2. traffic from 10.1 goes via ISP2 3. traffic from 10.2 goes via ISP3 4. 10.1.1.1 is accessible via every ISP # ip route show cache | grep GUEST_IP 10.1.1.1 from GUEST_IP dev eth0 src ISP2 GUEST_IP from 10.1.1.1 via ISP1 dev eth1 src eth0_ip_address How do I prefer routing cache over ip rule? So let's explain it more clearly on a drawing: Situation now: Guest is confused, because he gets packets from the wrong IP address ___ | | | |eth1|--ISP1| internal ---|eth0 | guest (very confused) 10.1.1.1 | ^eth2|---ISP2---| | | | eth3|-- ISP3 |___| Thanks! Szymon Miotk ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Basic HTB shaping configuration
John Buttery wrote: I'm trying to create a relatively simple traffic shaping environment; basically, we're a home network with three different classes of traffic: 1) High-priority, which means usually low bandwidth but very demanding latency requirements. In English: online gaming. :) 2) Medium-priority, which includes most of what people think of as normal Internet traffic. Web browsing, email, USENET, IRC, etc. 3) Low-priority, which includes bulk traffic like big file downloads. Basically, the cake that I'm trying to have and eat it too is where we can be running a bunch of stuff like BitTorrent clients to download new Quake maps, and still be playing Battlefield 1942 without getting hammered on by the P2P clients' data transfers and node-building traffic. Bittorrent is the hardest thing I've tried to shape yet. It uses 20+ full duplex tcp and your peers may well have a 2 sec flooded buffer. This means that if you use it alot you would be best to get it in it's own class and set, say max 60% down - and down is the problem, you have total control over upstream so that is sortable. This is what I have so far; it has made a definite improvement for prio 1 traffic (the medium stuff, web browsing and such) but doesn't seem to be enough; online gaming is still quite laggy while the file transfers and such are active. At this point it seems that what I basically need to do is tweak the values of the $UPSTREAM_* variables, but I thought I might ask here first to see if there's an entire design-level improvement to be made. The basic idea is that medium traffic should be able to stomp on low traffic (represented by the default case) when it needs bandwidth/latency, and that high traffic should be able to stomp on both medium and low when it needs bandwidth/latency...but the lower classes can borrow bandwidth when the classes that outrank them aren't using it. This is sort of what I am doing (though what I do keeps changing). TCP slowstart is a pain - It's hard not to get a latency blip, when new connections start - but they don't last that long. From reading the parts of the HOWTO that I could get my mind around, I understand that only outbound traffic can be molded, so the script below makes no attempt to do anything with inbound traffic. You can and need to shape downstream - it's not actually possible to do it perfectly with the TC stuff, but you can make it alot better than doing nothing. It involves sacrificing some 20-40% of your bandwidth - depending on how many active tcp connections and how much you care about latency. How you do it exactly depends on your setup - there is an example of using the basic ingress policer in the wonder shaper script. It is better to shape using htb queues on your LAN facing interface if possible, you can also use IMQ. For ingress I find esfq is better than sfq as you can limit the queue length. I am still experementing with my home setup and have modified the hash for ingress and made it head drop, which seem to help a bit - but I haven't tested enough to see if it's now broken in any way. In a tangentally-related question, I'm having some trouble determining what number I should put for $UPSTREAM_TOTAL. I sort of arrived at 15 by trial and error -- but if anybody has any suggestions on ways to empirically determine what your upload speed actually is, they would be most welcome. :) Most people know what their bandwidth is :-) However If you have dsl and it's sold as 128kbit/s up then 15KB is probably too high - there is alot of overhead and while htb calculates an empty ack as 40 bytes, it actually uses 106 on a dsl wire. I throttle to 85% upstream - could go higher I guess, but remember that while a bulk upload may be OK at say 90%, 30 small game packets/sec will be miscalculated more % than bigger packets. Another tweak which helped me, was changing a setting in htb, before I did this I found that packets were being sent in pairs. set HTB_HYSTERESIS 0 in net/sched/sch_htb.c Oh, one other thing...does u32 match ip [sd]port N match both TCP and UDP port N, or just TCP? I'm wondering if that may be part of the problem, since most online games use UDP for the client connections. Thanks to anyone who takes a look; let me know if there's any more information from our configuration/setup that would be helpful. I can't help you there - I mark with iptables and filter on the marks. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Limiting bandwidth to entire LAN
Hi Gastón, tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 1.2.3.0/24 classid 1:30 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 1.2.3.0/24 classid 1:30 I'm pretty sure you want 'flowid 1:30' instead of classid on the filters. To my knowledge, the classid is declaring the filter to have that class, instead of directing the matching to the class with that id. Although, taking a quick look through the doco, I can't see anywhere where it explicitly says what the flowid does, maybe it's just assumed because all the examples are like that. regards -- ~~~ Damion de Soto - Software Engineer email: [EMAIL PROTECTED] SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliancesweb: http://www.snapgear.com ~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
