Hi, A while ago I saw a message saying that the TC features in 2.2 aren''t very mature, and I''m wondering what I''d be missing out on if I stayed with 2.2 instead of using 2.4 now. I''m quite familiar with ipchians, and advanced routing on 2.2. I don''t plan on doing any layer 2 based rules, so that''s not an issue. TIA, Mike
Mike Fedyk wrote:> > Hi, > > A while ago I saw a message saying that the TC features in 2.2 aren''t > very mature, and I''m wondering what I''d be missing out on if I stayed > with 2.2 instead of using 2.4 now.download 2.4.6 download 2.2.lastest make a diff on net/sched directory and see the difference. You would miss like 2000 lines of bugfixes if you stay with 2.2, but anyway 2.4.6 is not yet stable with "tc features", so if it works for you dont move it until 2.4.15 or so ... Nikolai
On Thu, Jul 12, 2001 at 01:51:15PM -0500, Nikolai Vladychevski wrote:> Mike Fedyk wrote: > > > > Hi, > > > > A while ago I saw a message saying that the TC features in 2.2 aren''t > > very mature, and I''m wondering what I''d be missing out on if I stayed > > with 2.2 instead of using 2.4 now. > > download 2.4.6 > download 2.2.lastest > > make a diff on net/sched directory and see the difference. You would > miss like 2000 lines of bugfixes if you stay with 2.2, but anyway 2.4.6 > is not yet stable with "tc features", so if it works for you dont move > it until 2.4.15 or so ...Are you saying that the QoS traffic control features have stability problems, or is this just general 2.4 instability?
Mike Fedyk wrote:> > On Thu, Jul 12, 2001 at 01:51:15PM -0500, Nikolai Vladychevski wrote: > > Mike Fedyk wrote: > > > > > > Hi, > > > > > > A while ago I saw a message saying that the TC features in 2.2 aren''t > > > very mature, and I''m wondering what I''d be missing out on if I stayed > > > with 2.2 instead of using 2.4 now. > > > > download 2.4.6 > > download 2.2.lastest > > > > make a diff on net/sched directory and see the difference. You would > > miss like 2000 lines of bugfixes if you stay with 2.2, but anyway 2.4.6 > > is not yet stable with "tc features", so if it works for you dont move > > it until 2.4.15 or so ... > > Are you saying that the QoS traffic control features have stability > problems, or is this just general 2.4 instability?what I have listened and what my friends say general 2.4 is not very stable. What I have seen myself is that 2.4 works ok for me, but since the change logs for 2.4.x are full of "network update" stuff, i still not very sure it is stable. About QoS traffic .... I just had posted about some problems in CBQ code, even if I had incorretly set it up, it shouldn''t freeze kernel, so , as long as you understand it well and use the tc command correctly, it will work for you. But what I am trying to do is to release it for production where the end users would point & click for filter creation & bandwidth definition, so I think it will be an adventure, but I am accepting the risks... after all.... it''s free code.... Regards Nikolai
On 12 Jul 2001 17:41:42 -0500, Nikolai Vladychevski wrote:> But what I am trying to do is to release it for > production where the end users would point & click for filter creation & > bandwidth definition, so I think it will be an adventure, but I am > accepting the risks... after all.... it''s free code....I''ve been working on an XML format for describing a traffic control configuration in-house. We''re working on a good way to describe the rules and its not too hard since most of the settings are hierarchial. We''ve eliminated the need for specifying parents by the inherentness of nesting classes under cbq queues and queues under classes, but have a few more things to iron out. I''ll be posting what we come up with and some code to turn it into TC statements when its more stable unless there''s outside interest in working on it. Offering users a point-and-click QoS+TC environment was on our minds when we realised that what we needed was a good configuration file format to save the settings in. -- Michael T. Babcock http://www.fibrespeed.net/~mbabcock/
This would be wonderful... is it an OS project (And how far along is it)? It always seemd to me that things like routing and rate limiting rules would be better described by a configuration file than by a series of command line commands. -David Talbot Michael T. Babcock wrote:>On 12 Jul 2001 17:41:42 -0500, Nikolai Vladychevski wrote: > >>But what I am trying to do is to release it for >>production where the end users would point & click for filter creation & >>bandwidth definition, so I think it will be an adventure, but I am >>accepting the risks... after all.... it''s free code.... >> > >I''ve been working on an XML format for describing a traffic control >configuration in-house. We''re working on a good way to describe the >rules and its not too hard since most of the settings are hierarchial. >We''ve eliminated the need for specifying parents by the inherentness of >nesting classes under cbq queues and queues under classes, but have a >few more things to iron out. I''ll be posting what we come up with and >some code to turn it into TC statements when its more stable unless >there''s outside interest in working on it. > >Offering users a point-and-click QoS+TC environment was on our minds >when we realised that what we needed was a good configuration file >format to save the settings in. >
> This would be wonderful... is it an OS project (And how far along is it)? > It always seemd to me that things like routing and rate limiting rules > would be better described by a configuration file than by a series of > command line commands.A copy of an example XML description file is available at: http://www.fibrespeed.net/~mbabcock/linux/qos_tc/tc.xml Right now, its fairly specific to the options available in Linux tc, but our goal was to come up with a schema that would be extendable to other QoS configurations (like *BSD''s) -- Michael T. Babcock CTO, FibreSpeed
* Michael T. Babcock; <mbabcock@fibrespeed.net> on 13 Jul, 2001 wrote:> > This would be wonderful... is it an OS project (And how far along is it)? > > It always seemd to me that things like routing and rate limiting rules > > would be better described by a configuration file than by a series of > > command line commands. > > A copy of an example XML description file is available at: > http://www.fibrespeed.net/~mbabcock/linux/qos_tc/tc.xml > Right now, its fairly specific to the options available in Linux tc, but > our goal was to come up with a schema that would be extendable > to other QoS configurations (like *BSD''s)This is what I am getting XML Parsing Error: syntax error Location: http://www.fibrespeed.net/~mbabcock/linux/qos_tc/tc.xml Line Number 1, Column 6:<?xml ?> -- Togan Muftuoglu
Any source code available (and if so where?)? Is this a OS project, an internal app, or a commercial app? -David Talbot Michael T. Babcock wrote:>>This would be wonderful... is it an OS project (And how far along is it)? >>It always seemd to me that things like routing and rate limiting rules >>would be better described by a configuration file than by a series of >>command line commands. >> > >A copy of an example XML description file is available at: >http://www.fibrespeed.net/~mbabcock/linux/qos_tc/tc.xml >Right now, its fairly specific to the options available in Linux tc, but >our goal was to come up with a schema that would be extendable >to other QoS configurations (like *BSD''s) >
> Any source code available (and if so where?)?Not in the open yet, no.> Is this a OS project, an internal app, or a commercial app?Open source, for commercial use. We want to be able to design traffic control configurations for our clients in a better way than the lists of TC commands that are typical -- so this will obviously give us commercial aid, but we will release the conversion tools under the GPL and the XML schema for free use. I''d like to officially encourage contribution to the idea and any syntactic problems you foresee. -- Michael T. Babcock CTO, FibreSpeed
A schema that doesn''t use the obscure referances of tc would probably
be
far easier to use, something similar to:
<qos>
<class id="1:1" devicebandwidth="100mbit"
ratelimit="256kbit"
device="eth0" bounded>
<filter srcip="192.168.0.1"
destination="209.12.12.12"
destinationport="80"/>
<filter destinationip="10.0.0.1">
<route redirectto="10.0.1.1"
redirectport="80"/>
</filter>
</class>
<filter destinationip="10.0.0.1">
<route redirectto="10.0.1.1"
redirectport="443"/>
</filter>
<qos>
This is logically the way I''ve always thought of tc/iptables etc (It
makes sense to me that you would want to configure them both in the same
file. Basically using the syntax above, you define a class, then you
define filters to say when it should apply, and you can even set routing
decisions (iptables) when certain filters apply. It seems like it
wouldn''t be hard to put together a perl script that could interpret the
above and wisk it into a series of iptables and tc commands that produce
the desired configuration.
Of course the example above means alot of things are implied such as the
average packet size and many of the other parts of TC that are
"unknown"
(such as quantum, I still can''t find and documentation as to what It
does, I just know it has to be 1514b). In cases such as the one
mentioned above, we could create "semi-intelligent defaults" but with
the ability for the person to define it if they really want to.
What do you think? Too dummied down to be useful?
-David Talbot
Michael T. Babcock wrote:
>>Any source code available (and if so where?)?
>>
>Not in the open yet, no.
>
>>Is this a OS project, an internal app, or a commercial app?
>>
>Open source, for commercial use. We want to be able to design traffic
>control
>configurations for our clients in a better way than the lists of TC commands
>that
>are typical -- so this will obviously give us commercial aid, but we will
>release
>the conversion tools under the GPL and the XML schema for free use.
I''d
>like to officially encourage contribution to the idea and any syntactic
>problems
>you foresee.
>--
>Michael T. Babcock
>CTO, FibreSpeed
>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://ds9a.nl/2.4Routing/
>
>.
>
David Talbot wrote:> This is logically the way I''ve always thought of tc/iptables etc (It > makes sense to me that you would want to configure them both in the > same file).On a Linux machine -- yes. However, doing XML schemas correctly means that it should describe one thing well, and only that one thing. I''d rather have an extensible schema that describes traffic control rules perfectly than one that also describes routing and filtering half-heartedly.> Of course the example above means alot of things are implied such as > the average packet size and many of the other parts of TC that are > "unknown" (such as quantum, I still can''t find and documentation as to > what It does, I just know it has to be 1514b). In cases such as the > one mentioned above, we could create "semi-intelligent defaults" but > with the ability for the person to define it if they really want to.Quantum is the unit of an individual packet and should be set to the MTU + the ethernet header size (14 bytes). -- Michael T. Babcock CTO, FibreSpeed