Re: [LARTC] Guaranteed bandwidth per connection
Hi, well, that's exactly what I'm doing now. The only thing is that it only makes sense if there are a lot of connections, when there are only a few, they will get a lot of bandwidth, which isn't what I want. Thanks for the response. Jeroen. On Wed, 21 Apr 2004 16:54:11 +0300 Radoslav Kolev <[EMAIL PROTECTED]> wrote: > Hi!Jeroen Vriesman wrote: > > >In stead of defining a min/max for a certain type of traffic (e.g. http, ftp > >whatever), I would like to define a "minimum guaranteed bandwidth per connection". > >e.g. An application connecting to port X would get 10kbit/s guaranteed, the next > >connection to port X would also get 10kbit/s etc. > > > >Would be something like having N (the maximum number of connections) HTB classes, > >and put every new connection in another class. > > > > > I don't know how you can put every new connection in a new class, but > why don't you try this: > Decide what will be the maximum number of connections you want to > provide the guaranteed minimum and how much will it be (kbit/s). > If for example we take connections to port 80, create a HTB class with > rate=max_conn*guaranteed_rate and classify all traffic to port 80 to it. > Then add an SFQ behind. This way if there is a fewer number of > connections than you planned for each will get > (class_rate/connections)kbit, which > will more than the guaranteed minimun. If the number is equal to the > number of connections, the SFQ will make sure that no particular connection > take over the bandwitdh, and evey connection will get it's guaranteed > minimum. If there are more connections than you expected, each will get > an equal portion of the available bandwidth. Actually that's exactly > what SFQ is designed for, to distribute the available bandwidth equally > to every connection. > > Greets, > Rado > > ___ > 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] Guaranteed bandwidth per connection
Dear all, I've got a working HTB configuration with iptables, fwmark, SFQ etc. At the moment, I can mark traffic and give it a maximum bandwidth and a minimum guaranteed bandwidth, so far so good. What I would like to do is the following: In stead of defining a min/max for a certain type of traffic (e.g. http, ftp whatever), I would like to define a "minimum guaranteed bandwidth per connection". e.g. An application connecting to port X would get 10kbit/s guaranteed, the next connection to port X would also get 10kbit/s etc. Would be something like having N (the maximum number of connections) HTB classes, and put every new connection in another class. Does anyone know how to do that? Kind regards, Jeroen Vriesman. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc feature request/bounty (fwd)
Hi, for something like that to work, you need a lot of programming and testing in different situations. Sharing traffic shaping across different boxes can become very complicated if you want to do it right, I don't think you can find experts willing to program and test everything, setup test networks etc. for 300$. Good luck, Jeroen. On Mon, 12 Apr 2004 17:49:00 -0400 (EDT) [EMAIL PROTECTED] wrote: > Currently, linux tc has very useful concept of a 'index' for a given > policy. However, I need to have policers on multiple hosts to share the > same index (and thus, know and police the aggregate traffic across a set > of routers). > > I'd like to be able to share tc policers across a set of boxes. > Unfortunately, I'm not knowledgeable enough myself to implement that, but > I can throw some money at the pool and hope someone picks it up. ;) > > Proposed design: > > Userland daemon that polls kernel tc structure every X milliseconds and > broadcasts current bps rate (assuming we are using ewma) to a set of IP > addresses. Configuration would have list of indices and list of IP > addresses these indices are broadcast to. > > Kernel changes: Add netlink interface to look up/modify (by "injecting" > traffic) policer's structures (interface to tcf_police_lookup and > tcf_police_dump). > > Adding external traffic to policer structures is somewhat tricky, but I'm > sure it is possible. At this point, I only care about EWMA, which isn't > all that hard. > > Budget and bounty: 300$ > > Any takes? > > -alex > > > > > ___ > 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/
Re: [LARTC] large routing table
Another idea: by default shape everything, but allow it to burst a bit (if that's not a problem). make MARK X not shaped. MARK X some big networks which will always be Switserland. Then make a script (using the perl module I metioned previously) to check whether a new connection should be shaped or not, if it should not be shaped, and if it's not part of the marked IP's already, you add an entry to the MARK X list the /24 network where the IP address is in. (I think you can safely say that a /24 network is in one country). After one of these "temporary" marks is inactive for a while, remove it from the MARK X list, increase the "time to stay" for networks which are used often. So, your server apps should trigger a script (in the background) upon every new connection (maybe some tcpwrappers can do that, maybe you have to modify a tcpwrapper). make sure to update the database used by the scripts, Geo::IP has a "premium database subscription" update thingy. Good luck, you can mail me if you need some help, Jeroen. On Wed, 31 Mar 2004 00:56:52 +0200 Rene Gallati <[EMAIL PROTECTED]> wrote: > Hello List, > > I have a little non-standard problem (or so I guess). I'm getting a > sponsored server on a backbone for almost nothing - which is quite nice. > However there is a string attached: Since the bandwith to foreign > countries is expensive, while in-land bandwith is almost free, I need to > shape down access to all "foreign" IPs. > > Now I have a (large) list of routes/prefixes for destinations which are > ok - a whitelist if you want. The question I have now is, how do I best > proceed in using that list so that the kernel does not spend too much > time looking it up for every single packet. > > Is the routing table hashed by default so access is fast and I can just > pump in the ~100KBytes of ip prefixes ? Or does it traverse them > linearly and I need to build a hierarchical structure so that it will be > fast ? (sort of like in section 12.4 of the LARTC howto with the filters?) > > I've also toyed with the idea of doing it in netfilter since I know > netfilter quite a lot better than tc and ip but it is mostly outgoing > traffic that is a problem and I sort of feel that this is better done by > the routing/filtering infrastructure than by the firewall. > > Any advice? > > Thanks in advance > > ___ > 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/
Re: [LARTC] large routing table
Hi, this is exactly why ip addresses are already grouped with respect to location. So it should be possible to optimize things, maybe use some perl with http://search.cpan.org/~nwetters/IP-Country-2.15/lib/IP/Country.pm e.g. 194.0.0.0/8 is NL And I guess you can afford to make some errors, e.g. shaping a destination which shouldn't be shaped is not a crime if it wouldn't happen too often, just make sure you shape foreign IP's, how bad would it be to shape some non-foreign IP's accidently? And, ofcourse, either "foreign IP's" or "non foreign IP's" is the smallest list, use the samllest list. Good luck, Jeroen. On Wed, 31 Mar 2004 00:56:52 +0200 Rene Gallati <[EMAIL PROTECTED]> wrote: > Hello List, > > I have a little non-standard problem (or so I guess). I'm getting a > sponsored server on a backbone for almost nothing - which is quite nice. > However there is a string attached: Since the bandwith to foreign > countries is expensive, while in-land bandwith is almost free, I need to > shape down access to all "foreign" IPs. > > Now I have a (large) list of routes/prefixes for destinations which are > ok - a whitelist if you want. The question I have now is, how do I best > proceed in using that list so that the kernel does not spend too much > time looking it up for every single packet. > > Is the routing table hashed by default so access is fast and I can just > pump in the ~100KBytes of ip prefixes ? Or does it traverse them > linearly and I need to build a hierarchical structure so that it will be > fast ? (sort of like in section 12.4 of the LARTC howto with the filters?) > > I've also toyed with the idea of doing it in netfilter since I know > netfilter quite a lot better than tc and ip but it is mostly outgoing > traffic that is a problem and I sort of feel that this is better done by > the routing/filtering infrastructure than by the firewall. > > Any advice? > > Thanks in advance > > ___ > 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/
Re: [LARTC] "Fair" queuing
I use SFQ for that, works fine. On Tue, 30 Mar 2004 10:44:13 +0300 "Mihai Vlad" <[EMAIL PROTECTED]> wrote: > Hello again, > > Is it possible to split a bandwidth equally among clients regardless of its > current link speed? > > I have a link that can get bursty at times. At any given time the N active > sessions (the ones with non-empty queues) need to be serviced > simultaneously, each at a rate of 1/N'th of the link speed. > > (This might not be a strictly HTB related question) > > Thanks in advance, > Mihai Vlad > > > > ___ > 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/
Re: [LARTC] HTB speed
Strange, must be somthing else going on. I had the same 40 to 50 percent too slow, which was completely fixed bij using PSCHED_CPU in pkt_sched.h. Using kernel 2.4.24, I measure the speed with the iptables byte counters. On Fri, 26 Mar 2004 16:27:42 +1200 Simon Byrnand <[EMAIL PROTECTED]> wrote: > At 12:46 26/03/2004, Simon Byrnand wrote: > >At 18:17 25/03/2004, Andrew Hall wrote: > >>You need to recompile the kernel after altering this value in > >>linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf > >>qdisc, then the queue length may cause delay problems if it's too long > >>(default is 128). Changing this to 32 for rates below 100kb/s, I have found > >>to help things considerably. This change needs to be done in > >>linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. > > > >Hmm, > > > >When I use sfq with cbq at speeds like 256Kbit there is no problem at all, > >runs very sweetly, but with HTB and sfq, it is very jerky and poor. I'll > >try the change in pkt_sched.h first and see how I go... > > Ok, I tried the change in pkt_sched.h and didn't notice any difference > whatsoever. Any other ideas ? cbq is still fine but htb for the same speed > is very jerky and the speed fluctuates around 60-80% of the wanted speed, > while cbq gives a steady 99% of the wanted speed... > > Regards, > Simon > > ___ > 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/
Re: [LARTC] how to create a high latency link ?
That's great! now I can use the uid match of iptables, together with MARK, to make really good shapers for some people like "tc qdisc add dev eth0 root delay latency 2000ms rate 1k", I think I will use it for that guy who tries to be funny all the time. users will long hair, a nice dress and smiling get the full 10Mb.. :) On Fri, 26 Mar 2004 13:39:26 +0200 (EET) Catalin BOIE <[EMAIL PROTECTED]> wrote: > On Fri, 26 Mar 2004, Pascal OFFREDO wrote: > > > Hi, > > > > I'd like to create a high latency link between 2 machines ( more than > > 700 ms round trip) for simulation purpose. > > > > Is it possible to do that with linux qos management software ? > > Yes, it is possible. > Check latest rc from 2.4 or 2.6. It contains sch_delay that can do this. > > You also need: > http://developer.osdl.org/shemminger/tcp/iproute2-delay.tar.bz2 > > Example: > tc qdisc add dev eth0 root delay latency 25ms rate 100mbit > > Good luck! > > > > > > > thanks > > > > Pascal OFFREDO > > > > > > ___[ Pub ] > > www.Tandaime.com/index.php?origine=4 Tandaime, et la vie vous sourit ! > > > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > --- > Catalin(ux) BOIE > [EMAIL PROTECTED] > ___ > 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/
Re: [LARTC] HTB speed
Would the problem with queue lengths also exist if CONFIG_HZ=1000 in .config? (it certainly improves latency) I've configured rates from 10kbit/s...2Mbit/s on one machine, so changing the kernel code "for low rates" would probably effect the high rates too. Or, in other words, what is exactly the problem with an SFQ length of 128 for low rates? Cheers, Jeroen. On Thu, 25 Mar 2004 17:17:44 +1100 "Andrew Hall" <[EMAIL PROTECTED]> wrote: > You need to recompile the kernel after altering this value in > linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf > qdisc, then the queue length may cause delay problems if it's too long > (default is 128). Changing this to 32 for rates below 100kb/s, I have found > to help things considerably. This change needs to be done in > linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. > > - Original Message ----- > From: "Simon Byrnand" <[EMAIL PROTECTED]> > To: "Jeroen Vriesman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, March 25, 2004 4:36 PM > Subject: Re: [LARTC] HTB speed > > > > At 11:14 14/03/2004, Jeroen Vriesman wrote: > > >Hi, > > > > > >just putting the answer to my own question here, for those who have the > > >same problem, and read the mailing list archive. > > > > > >The timing of the P4 based on "jiffies" is hopeless, it's different for > > >every processor, and can be a wrong by a factor 3. > > > > > >If the tsc (time stamp counter) is used, the htb works fine, the error in > > >speed is now only about 1 %. > > > > > >It's set by: > > > > > >in pkt_sched.h: > > > > > >#define PSCHED_CLOCK_SOURCE PSCHED_CPU > > > > > >that's all, I wonder why it's not default to do this, or maybe it's an > > >idea to make the packet scheduler detect the presence of tsc when the > > >module is loaded. > > > > Hi, > > > > Which pkt_sched.h are you refering to ? > > /usr/src/linux/include/linux/pkt_sched.h or > > /usr/src/linux/include/net/pkt_sched.h ? > > > > And after changing it what did you do ? Recompile the kernel ? > > > > Or recompile tc ? > > > > I too see the same problems with htb (very poor accuracy of speed, > > significantly too slow, also very jerky) while cbq is very accurate and > > smooth. (But lacks some features I need) > > > > Regards, > > Simon > > > > ___ > > 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 mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Kernel Settings
Hi, high speed traffic shaping works much more accurate if you set: CONFIG_HZ=500 in /usr/src/linux/.config And in /usr/src/linux/include/net/pkt_sched.h #define PSCHED_CLOCK_SOURCE PSCHED_CPU Accourding to my experience, the above settings improve high speed network stuff enormously. About memory allocation: When using huge netfilter configuration (> 3 lines), there seems to be a possible "unable to allocate memory" issue, I think it might be caused by kmalloc trying to allocate a continuous region. I'm not sure about it, but if this is the case it could be solved by using vmalloc in stead of kmalloc. Any comments from anyone here about the malloc stuff? Good luck, Jeroen. On Fri, 19 Mar 2004 10:06:32 -0500 "Michael Peppard" <[EMAIL PROTECTED]> wrote: > No problems and no issues, but a question this list would probably best > answer. > > Does anyone have a link/book they like that gives some advice on kernel > parameters specifically for a router. It's kernel 2.4. > > I have a Sangoma with dual T1's (ppp /w tc load balancing) running wanpipe. > The machine is pretty darn good (dual-hyper-threaded-Xenon-and-4 > Gig-of-ram-and-mirrored-serial-drives etc etc). I'm embarrassed admitting I > have such a nice machine working as a leaf router... and only in forward > mode too. > > Obviously I know a little about iproute2, firewalling and how to compile a > kernel, or it wouldn't work. A link that would let me actually use some of > the machines capabilities though would be helpful. Kernel tweaks to use the > memory better... You probably know better than me. > > I appreciate your expertise and assistance! > > -Mike > > > ___ > 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/
Re: [LARTC] Bridge + TC
Hi, I've got an almost simular setup, which is working fine. something I noticed: You say everything is going into class 1:10, which is both your default AND you got a filter for it <-?? I also see that your "default filter" has handle 1, in my setup the handles of the filters are unique. For the rest, the only real difference is that I mark in the iptables mangle PREROUTING table, maybe an idea to test that. So I would suggest testing: 1) no filter rule for 1:10 which is default 2) no filters with handle 1, (I start at 101 for the filters) 3) marking with iptables in mangle PREROUTING should work, it's working fine here on 2.4.24+ebtables Cheers, Jeroen. On Mon, 15 Mar 2004 11:15:48 + Jon Anderson <[EMAIL PROTECTED]> wrote: > I'm hoping someone can provide a little input that might help me out a > little... > > I've recently tried to setup a 3-interface transparent bridge, where 2 > internal interfaces (eth1,eth2) funnel into 1 outgoing interface (eth0). > The idea was to be that eth1 gets priority over eth2 in all cases. > > The bridge works flawlessly - it passes all layer2 traffic through > properly. The traffic control however, does not work at all. (The LARTC > Howto says bridging + tc should "work as advertised", but no examples or > instructions are given...) > > The conclusion I came to was that bridging is done in layer2, and so > traffic control code (typically layer3) never gets to touch it. Am I wrong? > > Setup was: mark packets with ebtables, then filter into 2 qdiscs based > on those marks. > > Ebtables bit: > ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1 > ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2 > - This works, as ebtables' counters do count matching packets correctly > (connecting a machine to and interface, and starting . (I assume that > they set sk_buff->nfmark properly.) > > . > > Classes: > tc qdisc add dev eth0 root handle 1: htb default 10 > tc class add dev eth0 parent 1: classid 1:1 htb rate 500kbit ceil 500kbit > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 450kbit ceil 500kbit prio 0 > tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50kbit ceil 500kbit prio 1 > > tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10 > > tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:20 > > As I understand it, the second last line should put packets with nfmark 1 into class > 1:10 (450-500 kbit), and the last line should put packets with nfmark 2 into class > 1:20 (50-500kbit). > > With an active host plugged into eth2, all I get is traffic going through the > default class (1:10) according to 'tc -s show class dev eth0' > > If anyone could offer any suggestions, I'd be glad to hear 'em. > > Cheers, > > jon anderson > > > ___ > 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/
Re: {Spam?} Re: [LARTC] HTB speed
List, I just logged in to a machine with a modern AMD cpu, it also has a TSC. [EMAIL PROTECTED]:~> cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(TM) XP 2000+ stepping: 2 cpu MHz : 1668.736 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips: 3329.22/^\ | So, I think you have to pull some managers' tie and demand new hardware :) Jeroen. On Mon, 15 Mar 2004 12:11:05 + Maria Joana Urbano <[EMAIL PROTECTED]> wrote: > > > Hi Jeroen, > > Thanx for your fast answer. > > > >to use the TSC, the processor has to have a tsc, you can see that in > >/proc/cpuinfo, for as far as I know, every P4 has it (but I'm not sure), > >it's in the "flags" of cpuinfo: > > > >On my P4-1800: > > > >flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > >cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > > > >The "loop calibrated" jiffies stuff dates back to 386, it's used > >everywhere in the kernel timing, and it's very inaccurate, I don't know if > >2.6 still uses it everwhere, what kind of processor do you have? > > I am using and old test machine with an AMD-K7 processor. I think that's > the reason I cannot use TSC, it only works in Pentium processors. > > > >I've never tried to change the Hz value, does changing it in param.h > >really changes the frequency of the clock ticks? If so, why is the default > >only 100Hz these days? doesn't make sense to me. > > I have no ideia why it is still at 100Hz. However, I took this clue from [1]. > > >I do use the PSCHED_CPU in a production environement at the moment, works > >fine. > > OK, that's good news :-) > > Regards, > Joana > > > [1] K. Wagner, "Short Evaluation of Linux's Token-Bucket-Filter (TBF) > Queuing Discipline" > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Hi, to use the TSC, the processor has to have a tsc, you can see that in /proc/cpuinfo, for as far as I know, every P4 has it (but I'm not sure), it's in the "flags" of cpuinfo: On my P4-1800: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm The "loop calibrated" jiffies stuff dates back to 386, it's used everywhere in the kernel timing, and it's very inaccurate, I don't know if 2.6 still uses it everwhere, what kind of processor do you have? I've never tried to change the Hz value, does changing it in param.h really changes the frequency of the clock ticks? If so, why is the default only 100Hz these days? doesn't make sense to me. I do use the PSCHED_CPU in a production environement at the moment, works fine. Cheers, Jeroen. On Mon, 15 Mar 2004 11:37:16 + Maria Joana Urbano <[EMAIL PROTECTED]> wrote: > > >in pkt_sched.h: > > > >#define PSCHED_CLOCK_SOURCE PSCHED_CPU > > > >that's all, I wonder why it's not default to do this, or maybe it's an > >idea to make the packet scheduler detect the presence of tsc when the > >module is loaded. > > Hi, > > I think not all processors accept this #define PSCHED_CLOCK_SOURCE > PSCHED_CPU. At least, I couldn't do it in my router. > > I am not using HTB but TBF, but I think the timing problems are similar. As > to tune TBF with higher precision, I had to manually change Hz value from > 100 to 1000, in param.h, and actually I am getting better results. > > My question is, does anybody tried to do this in an production environment? > For instance, in a router that integrates traffic control, NAT, firewall, > services gateway, etc., can this change in HZ value harm in any way the > rest of the system? > > Thanks in advance, > Joana Urbano > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Hi, Indeed, changing the timer to 1000Hz is possible, it turned out that I have a machine here running with a 1000Hz timer ticker. (I've installed a "realtime" kernel on it for audio recording). About your previous question, I've noticed that the system with 1000Hz ticker (which has been running for a few months) is UNSTABLE. might be more to it than just the 1000Hz, but I did notice that some "realtime" applications running in userspace where able to crash the system completely, happened 2 times in 3 months. Cheers, Jeroen. On Mon, 15 Mar 2004 11:37:16 + Maria Joana Urbano <[EMAIL PROTECTED]> wrote: > > >in pkt_sched.h: > > > >#define PSCHED_CLOCK_SOURCE PSCHED_CPU > > > >that's all, I wonder why it's not default to do this, or maybe it's an > >idea to make the packet scheduler detect the presence of tsc when the > >module is loaded. > > Hi, > > I think not all processors accept this #define PSCHED_CLOCK_SOURCE > PSCHED_CPU. At least, I couldn't do it in my router. > > I am not using HTB but TBF, but I think the timing problems are similar. As > to tune TBF with higher precision, I had to manually change Hz value from > 100 to 1000, in param.h, and actually I am getting better results. > > My question is, does anybody tried to do this in an production environment? > For instance, in a router that integrates traffic control, NAT, firewall, > services gateway, etc., can this change in HZ value harm in any way the > rest of the system? > > Thanks in advance, > Joana Urbano > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on "jiffies" is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Cheers, Jeroen. On Fri, 12 Mar 2004 10:58:40 +0100 Jeroen Vriesman <[EMAIL PROTECTED]> wrote: > Dear all, > > I'm running htb on 2.4.24, following setup: > > running on a bridge, ebtables patch, firewall marks with iptables, and an SFQ for > every HTB. > > Everything works fine, so I don't go into details, there is just one thing which > suprises me: > > When I configure HTB to shape to about 900 kbit/s, the resulting speed is about 400 > kbit/s. > > For higher speeds it's more accurate (but stil too slow), for lower speeds it gets > worse. > > Does anyone here have any idea why? I've just added a "correction factor" to my > scripts, so it's kind of allright, but I would like to know if others experience the > same thing. > > Jeroen. > ___ > 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] HTB speed
Dear all, I'm running htb on 2.4.24, following setup: running on a bridge, ebtables patch, firewall marks with iptables, and an SFQ for every HTB. Everything works fine, so I don't go into details, there is just one thing which suprises me: When I configure HTB to shape to about 900 kbit/s, the resulting speed is about 400 kbit/s. For higher speeds it's more accurate (but stil too slow), for lower speeds it gets worse. Does anyone here have any idea why? I've just added a "correction factor" to my scripts, so it's kind of allright, but I would like to know if others experience the same thing. Jeroen. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
