Re: [LARTC] make tc stop!
Hi Jonathan :) * Jonathan Gazeley [EMAIL PROTECTED] dixit: I want to stop shaping from running on my box, without rebooting it. What's the best way to get rid of any tc rules? I have tried tc qdisc del dev eth0 root which appeared to be successful but traffic through my box is still very slow. The slow speed has probably another explanation, but the command above, if successful, will stop shaping in eth0 :?? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] About b meaning byte and bit
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: Yes, I already knew that, what I was asking is why SI units are not used and shortcuts are used instead: see my original message, I was not sure if kilobit was being used correctly (meaning 1000 bits) or if it was being used mistakenly for kibibit (1024 bits), and on top of that, why b was being used as byte when the SI prefix for byte is B. It got changed so kbit means 1000 when S.Hemminger took over maintenance IIRC. Ok, thanks :)) I mean, tc doesn't seem to follow any standard except maybe in kilobit (which should be then used as kb, not kbit). I think changing kb and kbit would break too many existing scripts. That's the problem with scripts that insist blindly on parsing command output, specially with commands whose output may (and should) change regularly when improvements are made. I supposed this was the reason. Does tc have another interface, preferably in sys or proc or the only way of getting the information is asking the kernel directly (through tc, for example). Thanks a lot for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] About b meaning byte and bit
Hi Indunil :) * Indunil Jayasooriya [EMAIL PROTECTED] dixit: On 8/31/07, DervishD [EMAIL PROTECTED] wrote: Hi all :) I think that this issue has already been discussed on this list, but google didn't find anything interesting, so I'm bringing the subject again. The output of tc uses b meaning byte and bit for bit. The official suffixes for those units are B and b, respectively, and on top of this, I'm not sure if kbit means kilobit or kibibit in tc output. SEE below that was taken form this URL http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Please read: tc tool (not only HTB) uses shortcuts to denote units of rate. kbps means kilobytes and kbit means kilobits ! This is the most FAQ about tc in linux. Yes, I already knew that, what I was asking is why SI units are not used and shortcuts are used instead: see my original message, I was not sure if kilobit was being used correctly (meaning 1000 bits) or if it was being used mistakenly for kibibit (1024 bits), and on top of that, why b was being used as byte when the SI prefix for byte is B. I mean, tc doesn't seem to follow any standard except maybe in kilobit (which should be then used as kb, not kbit). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] About b meaning byte and bit
Hi all :) I think that this issue has already been discussed on this list, but google didn't find anything interesting, so I'm bringing the subject again. The output of tc uses b meaning byte and bit for bit. The official suffixes for those units are B and b, respectively, and on top of this, I'm not sure if kbit means kilobit or kibibit in tc output. I haven't had time to look at iproute2 sources, so I don't know if this should be dealt with in iproute2 or in the kernel itself. Most of the kernel has switched to SI units already, and IMHO most of the utils should do the same, to avoid the endless problem of SI vs. binary units. This said, maybe this weird syntas is used in tc so third party apps can parse the output. These apps certainly will break if a change in the syntax is made, but otherwise I see no reason to keep using b instead of B and bit instead of b. Currently the only way of having a sane syntax (and not only regarding units...) is tcng· If such a modification is seen as appropriate, I volunteer to make the patch. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] cpufreq affects rate in, at least, htb
Hi Adam :) * Adam James [EMAIL PROTECTED] dixit: On Tue, 28 Aug 2007 09:47:38 +0200 DervishD [EMAIL PROTECTED] wrote: I've tested this and having a cpufreq that slows down the CPU affects the rate of HTB. My ondemand cpufreq governor scales down the CPU frequency about 40% and this is more or less the slowdown the rate suffers, 40%. This is expected behaviour when CONFIG_NET_SCH_CLK_CPU is defined: Sh*t! I thought I changed that when I turned on cpufreq and set it to jiffies, but I've seen my /proc/kconfig.gz and it's not true, I have CONFIG_NET_SCH_CLK_CPU : Sorry for the noise, I'm embarrassed... And thanks a lot for your help. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: I've thought that the culprit may be cpufreq. I have cpufreq scaling activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz when the processor is idle. This is more or less the same amount that I lose in the rate. May this be the problem? How to fix without deactivating cpufreq? Could be - I don't know. Forgetting cpufreq htb can be limited by Hz if the burst size is too small. I've tested with a burst size of 1500 (my MTU) and with precomputed values (which are 1614b for burst, 1633b for cburst) and the result is the same. I'm using HZ=1000 in my kernel, so my resolution is 1ms. According to HTB docs, the burst that will cause the rate to be burst-bound is 272000bit * 1m = 272bit. I'm using htb+sqf, and I can post here my tc setup if needed (is quite short), including the filters. It should be OK, since it has been working for almost two years. Right now I cannot disable cpufreq because temperature problems, and I cannot shut down the machine either, so I cannot test if cpufreq is the culprit, that's why I'm asking. I haven't found anything while googling, either. If you have perturb too low on sfq the packet reordering it causes could make the sender back off too much. I have a perturb of 10, as I've always used. Finally I could turn the machine off and clean the CPU fan, so I've make a test using the performance governor and the ondemand governor of cpufreq and yes, the problem is the cpufreq thing : I'll start a new thread here for this and will report to LKML too. Thanks for your answer :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] cpufreq affects rate in, at least, htb
Hi all :) I've tested this and having a cpufreq that slows down the CPU affects the rate of HTB. My ondemand cpufreq governor scales down the CPU frequency about 40% and this is more or less the slowdown the rate suffers, 40%. Any known way of dealing with this without having to disable cpufreq? Thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] cpufreq affects rate in, at least, htb
Hi Andreas :) * Andreas Mueller [EMAIL PROTECTED] dixit: DervishD wrote: Hi all :) I've tested this and having a cpufreq that slows down the CPU affects the rate of HTB. My ondemand cpufreq governor scales down the CPU frequency about 40% and this is more or less the slowdown the rate suffers, 40%. Any known way of dealing with this without having to disable cpufreq? What kernel-version do you use? Sorry, I forgot to include that documentation... I'm using 2.6.20.14, and I was waiting until 2.6.22 stable branch reached at least 10 (I'm tired of regressions with all 2.6.x kernels, so I try to avoid updating if possible). In 2.6.22 another timer is used for psched. I'll give it a try, then, but not before 2.6.22.10 at least. Maybe NO_HZ could interfere on this issue too. Currently I have CONFIG_HZ_1000=y and CONFIG_HZ=1000, and no tickless idle since that feature was introduced in a later kernel. Probably the problem is the shared timer and I will have to use 2.6.22 kernel to have it if I dare upgrading ;)) Thanks for the information, Andreas :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: I'll start a new thread here for this and will report to LKML too. OK you should probably report to [EMAIL PROTECTED] rather than LKML. I was considering it, but then I thought that maybe this problem was known and affecting other parts of the kernel. Given the lack of response, probably reporting to netdev is better. I'll bounce the message there. Thanks :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] HTB doesn't give me the promised rate: cpufreq?
Hi all :) I've been using a tc setup for almost two years, but at some point (probably when I switched to kernel 2.6.x, but I'm not sure) it has started making something very weird. For a certain class, the rate is 125000bit and the ceil is 27bit, but the fastest rate I get is about 75-8bit, instead of the promised 125000, *with no other traffic in the device*. If I disable tc entirely, the upload rate is more than 30bit (a little below the line capacity, which is 32bit), but as soon as tc is enabled again, the upload speed drops again to 75-80kbit. There is no other traffic on the device, really, it's just like if the htb couldn't queue packets fast enough :??? I've thought that the culprit may be cpufreq. I have cpufreq scaling activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz when the processor is idle. This is more or less the same amount that I lose in the rate. May this be the problem? How to fix without deactivating cpufreq? I'm using htb+sqf, and I can post here my tc setup if needed (is quite short), including the filters. It should be OK, since it has been working for almost two years. Right now I cannot disable cpufreq because temperature problems, and I cannot shut down the machine either, so I cannot test if cpufreq is the culprit, that's why I'm asking. I haven't found anything while googling, either. If anybody has any idea about this problem, please tell. Thanks a lot in advance :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] about the traffic control
Hi Fionna :) * ???p?F [EMAIL PROTECTED] dixit: 1. Why most traffic shaping implement in the egress side (Uplink) rather than the ingress side(Dnlink)?(e.g. why put the police rule on the smaller bandwidth side but not put on the larger side) You cannot shape ingress traffic, because you cannot control the sending speed of the remote equipment. The only thing you can do is to drop packets, but that doesn't make bandwitdh smaller, it just cause less packets to arrive to applications, so while you effectively set a smaller bandwidth for applications, the cable BW is fully used. I suppose that ECN can be used to shape incoming traffic, but I don't know. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Where do I post patches?
Hi Russell :) * Russell Stuart [EMAIL PROTECTED] dixit: I have found a few bugs in tc, and have produced patches for them. Two require changes to tc, one to the kernel. Where should I post these patches? IMHO, you should start by posting the patches here for peer-review and betatesting. After that, the kernel related patches should be posted to LKML too. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] match'ing packets by size
Hi Ethy :) * Ethy H. Brito [EMAIL PROTECTED] dixit: match u16 0x 0xffb0 at 2 With this match he says that packet with less than 80 bytes will match the rule. That's right. Well, 0xffb0 translates to 1011 (which is -80 BTW). It is a mask, not a number (and certainly not a signed one), so there's no point in considering it -80. It is just a mask. Am I correct or I completely misunderstood it? You're right, packet sizes between 16 and 63 (both included) won't match the rule. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] match'ing packets by size
Hi Ethy :) * Ethy H. Brito [EMAIL PROTECTED] dixit: Well, 0xffb0 translates to 1011 (which is -80 BTW). It is a mask, not a number (and certainly not a signed one), so there's no point in considering it -80. It is just a mask. My point in considering it a number is explained by: printf(%hx, -80); OK, I just didn't think about that, sorry :) So, if you intend to creat a mask for 256 bytes size, you printf it as -256. Only if your C implementation treats negative numbers in 2's complement ;) Of course, I don't know of any C implementation where integers don't use 2's complement for negative numbers, anyway... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB burst/cburst decremented by one
Hi Patrick :) * Patrick McHardy [EMAIL PROTECTED] dixit: DervishD wrote: If I set the burst/cburst parameter to, let's say, 1500, the command tc -s -d class show dev eth0 says that the value is 1499b/8 instead of the (correct?) 1500b/8. Is this right or am I doing anything wrong? No, this is related to an integer division loosing precision in some cases. I'm looking into a fix, but it might take a while. OK, thanks a lot :) In the meantime I'll just add 1 by hand to get the numbers I really want ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] HTB burst/cburst decremented by one
Hi all :) If I set the burst/cburst parameter to, let's say, 1500, the command tc -s -d class show dev eth0 says that the value is 1499b/8 instead of the (correct?) 1500b/8. Is this right or am I doing anything wrong? Many thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
Hi Salim :) * Salim [EMAIL PROTECTED] dixit: I got this problem while trying to shape traffic with iptables MARK and HTB. MARK: targinfosize 8 != 4 --set-mark gives invalid argument error message. Kernel version is 2.4.29 (some patches from patch o matic applied) Iptables version 1.3.4 Intel x86 architecture. I saw this problem discussed in a few places, but the discussions didn't come to a conclusion or solution. You've hit a bug in iptables :( I've notified in the bugzilla but I have had no answers. You're building iptables with no shared libraries (NO_SHARED_LIBS=1). This means that the code in iptables, when loading the modules for the matches and targets is taking a slightly different code path. The problem is that the MARK target has two versions, 0 and 1, and kernel 2.4.x (at least until 31) supports only version 0. If you don't use share libraries in iptables, both versions are loaded and v1 is used instead of v2. Unfortunately, v1 has a bigger data structure than v0 and your kernel complaints. The only solution for your problem is to rebuild iptables with shared libraries instead of compiling the matches and targets in the binary, statically. I've tried to make a patch, and worked for me but I don't want to mess anything so I've described the problem, the wrong code path and other details to the iptables people. If you want to take a look the bug is #413 in bugzilla.netfilter.org And yes, nobody seems to have this problem because it seems that only few people uses iptables built statically :?? or because nobody seems to be interested. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] MARK: targinfosize 8 != 4
Hi Jones :))) * Jones Desougi [EMAIL PROTECTED] dixit: That can't be the reason, all revisions of a single match/target are in the same object file and the supported revision is (supposed to be) probed. They are not due to the DONT_LOAD usage ;)) The patch below is much better than the one I tested ;))) Try the patch below. (It's bug #413 in bugzilla) Thanks a lot :)) I'll test it as soon as I can. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Which option is better
Hi all :) Currently I'm shaping the traffic that goes to my ADSL router, using HTB. .Root (HTB) 1: .| .|| .LAN (1:1)ADSL router (1:2) .90Mbit/90MBit20bit/20bit . | . (Here go some children classes) I find the above a bit overkill, since LAN and ADSL classes won't NEVER borrow nor lend bandwidth to one another. Moreover, every time I set up my traffic control I get the same warning: HTB: quantum of class 10001 is big. Consider r2q change. Of course it is big!, it's my LAN class, limited to 90Mbit/s... Is there any better alternative to the above, given the great difference in rates and the fact that I won't NEVER share bandwidth between 1:1 and 1:2? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Which option is better
Hi Andreas :) * Andreas Klauer [EMAIL PROTECTED] dixit: On Friday 02 December 2005 21:16, DervishD wrote: I find the above a bit overkill, since LAN and ADSL classes won't NEVER borrow nor lend bandwidth to one another. They won't do that because the classes got the same rate/ceil. I did that on purpose, just in case I add another class above them in the future. Right now they cannot borrow/lend even if the rate is less than the ceil, because they are root classes, am I wrong? I got that idea from the HTB documentation. HTB is used for bandwidth limiting only here, probably except for (some children classes), whatever they are. Exactly. The children classes are a couple of classes to limit the rate for my ftp server, etc. There I want share, but on the top classes I just want to do limiting. I'm doing it practically the same way, except I don't like setups with more than one root class, so I actually got a fat root class with the device speed as rate above those two. In my personal opinion, having two root classes in HTB implies that these two are completely independent, which is not the case since they have to share the same interface after all. Interesting... And I think it's not overkill at all, since this is the only way to ensure that LAN traffic (file transfers and such) leave a bandwidth window open for the more fragile internet traffic. Well, in fact I didn't use 100Mbit as the rate/ceil of the LAN class for two reasons: - I don't think my cheap Ethernet card will never get that throughput even in a sunny day XDD - I want to leave a bit of bandwidth for the other PC in the LAN, which is running Windoze and, I don't know why, doesn't fight for the Ethernet bus... HTB: quantum of class 10001 is big. Consider r2q change. Of course it is big!, it's my LAN class, limited to 90Mbit/s... You can get rid of this message by specifying the quantum for this class directly. I know, I just wanted to show an additional advantage of using another approach for classes instead HTB O:) Is there any better alternative to the above, given the great difference in rates and the fact that I won't NEVER share bandwidth between 1:1 and 1:2? I don't have any problems at all with this solution, so I never bothered looking for something better. In fact, I think it's a very good solution, and if you're shaping using nothing but HTB, it's probably even the best solution you can get. Well, then I will run it as-is, although I take note of your idea of putting another class on top of my two main classes, just in case I want to shape things differently in the future. Thanks for your answer! :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] [RESEND] tc filter: match tcp src vs. match ip sport
Hi all :)) Sorry for asking again, but got no answers and google doesn't give useful information (seems like nexthdr doesn't work right, but I don't know why...). I really want to know what am I doing wrong... This filter matches what I want: tc filter add dev eth0 protocol ip parent 1:0 prio 9 u32\ match ip sport 0x3000 0xf000 flowid 1:22 and traffic goes to 1:22, but this one doesn't match: tc filter add dev eth0 protocol ip parent 1:0 prio 9 u32\ match tcp src 0x3000 0xf000 flowid 1:22 I don't understand why the first one matches and the second one doesn't :? because in the output of tc filter show the only difference is that the first one matches at 20 and the second one at nexthdr+0, which should be identical :? Looks like nexthdr is not working, and I prefer to use it just in case I have to filter IP packets with options (because then the first filter won't work). What the heck am I doing wrong? Is iptables my only option? What's the matter with nexthdr? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tc filter: match tcp src vs. match ip sport
Hi all :)) This matches what I want: tc filter add dev eth0 protocol ip parent 1:0 prio 9 u32\ match ip sport 0x3000 0xf000 flowid 1:22 and traffic goes to 1:22, but this one doesn't match: tc filter add dev eth0 protocol ip parent 1:0 prio 9 u32\ match tcp src 0x3000 0xf000 flowid 1:22 I don't understand why the first one matches and the second one doesn't :? because in the output of tc filter show the only difference is that the first one matches at 20 and the second one at nexthdr+0, which should be identical :? What the heck am I doing wrong? Thanks a lot :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] passive FTP trafic control
Hi Ethy :) * Ethy H. Brito [EMAIL PROTECTED] dixit: How to make shure that only FTP RELATED packets will be CLASSIFY'ed?? I can only suggest that you limit the source ports available to passive FTP. In my FTP server this can be configured, but probably in other servers you can do it too. Once you do this, it's quite easy to setup a tc filter to mark packages (or iptables if you prefer). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Latency/burst problem with HTB
Hi Toby, and thanks for your answer :) Excuse me for the long reply, but I wanted to put my current settings for tc just in case. Feel free to ignore. * Toby [EMAIL PROTECTED] dixit: DervishD wrote: tc filter add dev eth0 ... ip sport 0x3000 0x3000 flowid 1:111 tc filter add dev eth0 ... ip sport 0x4000 0x4000 flowid 1:111 tc filter add dev eth0 ... ip sport 0x20 0xff flowid 1:111 I'm serving passive FTP only in ports from 0x3000 to 0x4fff, and active FTP in port 20. Then you should use the following port numbers in your filters: 0x3000 0xf000 0x4000 0xf000 20 0x The first two of your filters were matching more ports than needed, while the latter WAS NOT MATCHING YOUR ACTIVE FTP TRAFFIC AT ALL. I suggest you read a tutorial on ip addresses and netmasks, that should cover the basis of how bitmasks work. I know how they work, but sometimes my brain doesn't work correctly ; The first two are a typo, in my tc setup I have masks 0xf000 and 0xf000, I don't know why I made such mistake, because I swear I cut'n'pasted it :??? and the third one is an error, caused because I was testing with ports 0x??20 to differentiate connections (to test settings for different FTP servers) with a hand made client that used different ports for active connections. I simply didn't put the mask back to 0x and worst, I didn't move to 20 *decimal* and left the 0x. I chose 0x??20 because it was easier to remeber and fancier to read O:) than 0x??14. Thanks for advising, because right now I don't have active ftp traffic and I would NEVER have spotted the errors. Thanks a lot, really. And I don't understand the typo :? I've seen the output of tc filter show dev eth0 and shows match 3000/f000 at 20. Is there any value I can tweak to make general ADSL traffic more responsive? Yes, you can make another HTB class, let's call it 1:112, for ICMP traffic (ie. ping, port unreachable...) and very small TCP packets (SYN, ACK, RST... all that stuff) and give it the highest priority. But all that traffic goes already through a higher priority class. The general ADSL traffic has a higher priority (prio 0) and ADSL outgoing FTP traffic has prio 1 :??? Sorry but that value doesn't show in what I posted, certainly I had a problem when cutting and pasting... I had to modify what I cut because I took it from a zsh script. Here is the real contents: TCQA=tc qdisc add dev eth0 parent TCCA=tc class add dev eth0 parent TCFA=tc filter add dev eth0 protocol ip parent action Starting traffic control on eth0 # root qdisc, defaults to ADSL other traffic $=TCQA root handle 1: htb default 21 r2q 1 # hispeed class (Ethernet) $=TCCA 1: classid 1:1 htb rate 95Mbit ceil 95Mbit $=TCQA 1:1 handle 10: sfq perturb 10 # lospeed class (ADSL) $=TCCA 1: classid 1:2 htb rate 256kbit ceil 256kbit burst 16384 cburst 8192 # Other ADSL traffic $=TCCA 1:2 classid 1:21 htb rate 224kbit ceil 256kbit prio 0 burst 16384 cburst 8192 $=TCQA 1:21 handle 21: sfq perturb 10 # FTP thru ADSL traffic $=TCCA 1:2 classid 1:22 htb rate 64kbit ceil 160kbit prio 1 # Filters $=TCFA 1:0 prio 1 u32 match ip dst 192.168.0.0/24 flowid 1:1 $=TCFA 1:0 prio 2 u32 match ip sport 0x3000 0xf000 flowid 1:22 $=TCFA 1:0 prio 2 u32 match ip sport 0x4000 0xf000 flowid 1:22 $=TCFA 1:0 prio 2 u32 match ip sport 20 0x flowid 1:22 I removed yesterday the old 1:1 class because I want no borrowing between Ethernet general traffic and Ethernet ADSL traffic. If I add this as you suggest (modifiying identifiers) $=TCCA 1:2 classid 1:23 htb rate 1kbit ceil 256kbit prio 0 then it will have the same priority that general traffic. I don't undertand why it should improve responsiveness :? I'm going to test, or course :), but I don't understand... By the way, I didn't invent all this, it's by Bert Hubert. You should check his wondershaper script: http://lartc.org/wondershaper/ I did, but if I don't do any borrowing (as wondershaper seems to do), latency is low. I want low latency when borrowing. With the setup I've posted above (that is, reducing ftp ceil to 160kbit and raising adsl-general rate to 250kbit) there's almost no latency, but I would like to add a bit more of ceil to ftp traffic. I'll test your suggestions, which I find quite interesting, and if I have success, I'll tell :) Thanks for your invaluable help, but if this works I'm afraid I won't understand why, because by default all that traffic that will be matched by the new filters will go to the fast-adsl class anyway :? Would it be because it will go out of the queue *even before* than general ADSL traffic? I think that's the reason, right? Well, I've finally tested your suggestion, and I've noticed only a marginal improvement in responsiveness and latency, around 10% more or less. Anytime I increase the ceil of the FTP
[LARTC] Latency/burst problem with HTB
Hi all :) I'm new to this list, as I'm new too to traffic shaping ;) I've set up an FTP server in my ADSL line and I wanted it to serve as fast as possible as long as I don't use my outgoing ADSL bandwidth, and I'm currently using HTB for that (succesfully, I must add). The problem is (when the FTP server is serving higher than its rate and near to its ceil) that protocols like SMTP or POP-3, when I use them as client, slow to a crawl because being short-burst in nature never use the speed I have configured for them :(( I don't know if I'm missing something, but other protocols seems to work OK. For example, when I browse the web, pages start to download slowly, DNS queries are very slow but once the pages start dowloading, speed is pretty good. My setup is for a few PC connected to an ADSL router using Ethernet cards, and I'm only shaping outgoing traffic in one box, the one serving FTP. The other boxes are more or less inactive. My shaping has an HTB discipline at root: tc qdisc add dev eth0 root handle 1: htb default 110 I've played with r2q, because it assigns too big a quantum to some classes and too small a quantum to others, until I noticed that using the default r2q assigned a very big quantum to classes that I want big quantums for and very small quantum to classes I want very small quantums for. After that I add a base class to be able to borrow bandwith, althoug I'm not sure now if that's a good idea: tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit ceil 100Mbit This class has the speed and ceil of my Ethernet card (100Mbit). Now I add two major classes, one for general LAN traffic and other for Ethernet traffic to the ADSL router: # Hi speed class tc class add dev eth0 parent 1:1 classid 1:10 htb rate 95Mbit ceil 95Mbit tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 # Low speed class (ADSL) tc class add dev eth0 parent 1:1 classid 1:11 htb rate 256kbit ceil 256kbit As you can see, bandwidth cannot be borrowed, so I think I could get rid of 1:1. Anyway, this shouldn't make any difference for bursted protocols that now are slow. In the hispeed class I use 95 as rate and ceil because being averaged values, I prefer to slow down LAN traffic and ensure I always have a bit of unused Ethernet slots so the low speed (ADSL) class doesn't have to wait. Should I specify (100M-256k)bit for rate and ceil here? The low speed class gets 256kbit although my ADSL is capable of upload at 300kbit. I give a bit for the other box that may use the ADSL and runs an operating system without shaping ;) I want to make sure that box has at least 50kbit more or less, no matter if I'm serving FTP in my box. For general LAN traffic I've chosen an SFQ queue discipline since I sometimes use many protocols at a time and adding a bit of fairness is desirable, although a pfifo_fast will probably work here, too. Last, I add two classes below the ADSL class, one to shape FTP traffic, the other class to shape the rest of traffic. # Other ADSL traffic tc class add dev eth0 parent 1:11 classid 1:110 htb rate 192kbit ceil 256kbit prio 0 tc qdisc add dev eth0 parent 1:110 handle 110: sfq perturb 10 # To filter FTP traffic tc class add dev eth0 parent 1:11 classid 1:111 htb rate 64kbit ceil 256kbit prio 1 Here are the most important classes. They share bandwidth, because I want the FTP server to borrow traffic if the ADSL is otherwise unused. The FTP server gots 8Kbps and the rest of the traffic 24kpbs. Finally, the filters: tc filter add dev eth0 prio 1 protocol ip parent 1:0\ u32 match ip dst 192.168.0.0/24 flowid 1:10 tc filter add dev eth0 prio 2 protocol ip parent 1:0\ u32 match ip sport 0x3000 0x3000 flowid 1:111 tc filter add dev eth0 prio 2 protocol ip parent 1:0\ u32 match ip sport 0x4000 0x4000 flowid 1:111 tc filter add dev eth0 prio 2 protocol ip parent 1:0\ u32 match ip sport 0x20 0xff flowid 1:111 I'm serving passive FTP only in ports from 0x3000 to 0x4fff, and active FTP in port 20. The rest of LAN traffic (including FTP) is sent to the hispeed class. As you can see, I give more priority to general ADSL traffic, and I'm sure such traffic is NEVER 24kbps, always much less than that, but if someone is using my FTP server at, let's say, 15kbps (borrowing bandwidth and still with a backlog of 15-30 packets, I can tell from the tc -d -s stats), if I try to download 300kB of email using POP-3, the client slows to a crawl. If I browse many small pages, the speed is slow. At the same time, browsing large pages or downloading gcc-4.0.2 ;) gives a speed more or less similar to that I would have without shaping and without the FTP server (well, a bit less because the burst effect affects this transmissions too and the slower pace in the ack packets makes FTP download a bit slower). I've played with burst and cburst values, and increasing burst in class 1:110 (ADSL general traffic) and its parents
