Re: [LARTC] Is this actually possible?
"Zviad O. Giorgadze" wrote: > > > > >Only if I lower the ceiling on leaf 1:30 does it show any results. If I > >have the ceiling the same on both, there is no measureable result in > >speed. The both seem to share the connection equally. > > > >Am I missing the point, is it possible at all, or am I just too dum to get > >it right? > > > >.peter > > I have the same problem and unable to solve. I can't promise this is the answer you're looking for, but it sure helped me a lot. grep "changes from state" /user/src/linux/net/sched/sch_htb.c If you don't get a match, go to http://luxik.cdi.cz/~devik/qos/htb/ and find the 21.6.2004 patch. gypsy ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Qdisc statistics project
On Wed, 2004-13-10 at 18:12 -0400, Jason Boxman wrote: > I was playing with that as well, but of late it doesn't seem to be actively > developed. Someone else mentioned LQL[1], but it doesn't seem to have hooks > to let you grab qdisc stats yet. > > [1] http://www.coverfire.com/lql/ > LQL seems to be the only actively developed project currently that could > eventually allow you to plug into netlink and poll for statistics. Right now > it seems you can only get and set parameters. I am currently working on statistics support. These new features are not done yet but should be within a couple of weeks. See below for a bit more information. http://www.coverfire.com/archives/2004/10/13/lql-update/ -- OpenPGP key: http://www.coverfire.com/files/pubkey.txt Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3 0C53 742A 9EA8 891C BD98 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Is this actually possible?
On Thu, 2004-10-14 at 02:10, Zviad O. Giorgadze wrote: > According to tc-htb man page, if we set PRIO parameter, then after > supplying the packets to satisfy the RATE of all classes, the HTB > first sends the available packets to LOWEST PRIO class and so on. I think that's correct > In this case if the above class 1:20 with PRIO 0 requests packets, > than the class 1:30 must receive only 1kbit (the specified RATE), > nothing more. This is true only if that packet is marked to go to the 1:20 chain. It has to _know_ where it's destined for before it gets priority. > In practice class 1:30 shares the bandwidth with class 1:20 and gets > not 1kbit, but much more >20kbit. This I can't be certain. > I have TSL 2.1, kernel 2.4.27-3tr. I changed the PSCHED_CPU and > disabled the HTB hysteresis, set SFQ queue length to 16 I'm not sure what are those. If anyone can explain that,it wold be nice ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Resetting traffic history
Mike Slinn wrote: I'm a tc newbie, and I think I am close to being able to use it to control one of the virtual web sites on our Gentoo Linux server. The site has it's own IP address. I have a bit of a problem in that the way I originally configured tc, the busy site grabbed all the bandwidth, leaving none for the other (and more important) sites. Here is how I had configured it: tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL latency 50ms burst $BURST The total data rate was pegged within acceptable limits, but the problem is that data stopped flowing after tc was active after a few hours. The busy site had a few peak periods and presumably used up all the traffic allotment. Perhaps tc remembers the traffic between invocations? I then tried a slightly more sophisticated setup: tc qdisc del dev $DEV root tc qdisc add dev $NIC root handle 1: cbq avpkt 1000 bandwidth 1000mbit tc class add dev $NIC parent 1: classid 1:1 cbq rate $RATE_PROBLEM allot 1500 prio 5 bounded # isolated tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip dst $IP flowid 1:1 Unfortunately, I still don't get any traffic flowing while tc is active now. Seems that I need to reset something. Any suggestions? I've shut down the problem site and disabled tc while I try to figure out a solution. Thanks for your help! Mike mslinn at mslinn.com From your other post I see 2.6.8.3 - I had to patch 2.6.8.1 to fix a TC options related panic. I don't know if it's in 2.6.8.3 already, though. http://www.linuxhq.com/kernel/v2.6/9-rc2/net/sched/sch_api.c Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Fwd: Re: [LARTC] ssh and cs LAG]
Mike Slinn wrote: We had no problems with smp on 2.6.8.3, and since this cpu supports hyperthreading we enjoy a *big* power boost using smp. :) I think it's this box(via p200) + rtl8139 that's the problem - it's always been a bit flakey. I have the same card in a PII350 intel440bx and it has always been OK. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Fwd: Re: [LARTC] ssh and cs LAG]
We had no problems with smp on 2.6.8.3, and since this cpu supports hyperthreading we enjoy a *big* power boost using smp. :) Mike Andy Furniss wrote: Hariett Jones wrote: Got some solutions myself. LAG is caused by : NETDEV WATCHDOG eth0 timeout this is caused bacause of problems with rtl8139 network card in kernel 2.6.x I had to unselect SMP in kernel config to get my rtl8139 + PCI modem to work with 2.6.8.1 Andy. Solutions : 1.add in lilo.conf : append="noapic" 2.turn apic off in bios 3.if u have 2 rtl8139 cards, then exchange one with some other card type (chipset) btw. all above was found in various polish forums, but none has worked for me. im switching kernel back to 2.4.22, and will report later . ___ 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] Is it possible to shape variable bandwidth?
Zviad O. Giorgadze wrote: Hello LARTC, Internet connection - ADSL, interface nas0 (115kbit guarantied, up to 1mbit possible. Depends on ISP load, impossible to guess). Internal interface LAN, eth0. Is it possible to successfully shape download traffic on eth0 using HTB? Classes must have guarantied rate calculated from 115kbit possible rate (for example 3 classes) and the possibility to borrow up to 1mbit (depends on ISP side). If it's impossible, than how to define additional class for excess bandwidth from 115kbit up to 1mbit? Can be other classfull or classless qdisc used in this case? Very hard, it maybe, depending on the link behaviour over time and exactly how your ISP does the shaping, be possible to detect what rate traffic is arriving at with policers and mark accordingly. I assume you are shaping inbound traffic - if so you will always need to keep your total rate about 20% less than what your speed is or you will not be able to "grow" a queue to shape with. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Fwd: Re: [LARTC] ssh and cs LAG]
Hariett Jones wrote: Got some solutions myself. LAG is caused by : NETDEV WATCHDOG eth0 timeout this is caused bacause of problems with rtl8139 network card in kernel 2.6.x I had to unselect SMP in kernel config to get my rtl8139 + PCI modem to work with 2.6.8.1 Andy. Solutions : 1.add in lilo.conf : append="noapic" 2.turn apic off in bios 3.if u have 2 rtl8139 cards, then exchange one with some other card type (chipset) btw. all above was found in various polish forums, but none has worked for me. im switching kernel back to 2.4.22, and will report later . ___ 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] Qdisc statistics project
On Tuesday 12 October 2004 09:32, Antonios Chalkiopoulos wrote: > As a necessety for my job is to real-time monitor the bytes, packets, > packet dropped etc of all the qdiscs working inside the kernel i've tried > varius methods: > > 1. Parse tc -s command output and update a round robin database and use > rrdtool to graphically display tc statistics. I find that generally works. > [varius perl scripts exist for the above job] > > 2. Unsuccesfully tried QoS SNMP extensions, in order to use a new MIB to > extract qdisc stats from. I was playing with that as well, but of late it doesn't seem to be actively developed. Someone else mentioned LQL[1], but it doesn't seem to have hooks to let you grab qdisc stats yet. [1] http://www.coverfire.com/lql/ > There is also some work in the kernel level that will help reveal qdisc > stats to userspace (thanks Thomas Graf) Are you talking about tcstat[2]? [2] http://reeler.org/tcstat/index.html > To get to the point.. the perl parsing method is hackish and quick&dirty. > A proper open-source tc monitoring tool SHOULD exist ! Maybe inside > iproute2 maybe in sourceforge. LQL seems to be the only actively developed project currently that could eventually allow you to plug into netlink and poll for statistics. Right now it seems you can only get and set parameters. > Are there any volunteers to start working on such a project? I could put > 4-6 weeks full time work on that... any suggestion for the most proper > solution to the above problem is welcome. I wrote yet another script to poll `tc` for statistics and pass that information off to RRDTool via Perl's RRDs module. I am using it for diagnostic purposes. It polls every 10s and updates a graph[3]. For long term tracking I am going to write a simple plugin for Munin[4] to grab information every five minutes and pass that off for graphing. [3] http://edseek.com/foo.png [4] http://www.linpro.no/projects/munin/ -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Fwd: Re: [LARTC] ssh and cs LAG]
Hariett, Switching to the 2.4 kernel is not an option as this is a production server. The machine has a dual Intel PRO/1000 NIC. The machine usies grub, not lilo, but that doesn't really matter. Not sure if APIC is an issue or not. Thanks for your help. Mike Hariett Jones wrote: Got some solutions myself. LAG is caused by : NETDEV WATCHDOG eth0 timeout this is caused bacause of problems with rtl8139 network card in kernel 2.6.x Solutions : 1.add in lilo.conf : append="noapic" 2.turn apic off in bios 3.if u have 2 rtl8139 cards, then exchange one with some other card type (chipset) btw. all above was found in various polish forums, but none has worked for me. im switching kernel back to 2.4.22, and will report later . ___ 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: AW: [Fwd: Re: [LARTC] ssh and cs LAG]
On Wednesday 13 October 2004 17:34, Stephan M. Ott wrote: > Switching back to older kernel won't do much. > I've had this problem much earlier when using two NICs of the same type. > I couldn't figure out why, but there ARE problems is many ways when > using two cards of the same type. I had problems with sharing, with > routing, etc. etc. > Best solution is to use different NICs... don't ask me why... I just > found out that this will solve the problems... > It's probably the machine. I have three rtl8139 based cards in a box and it's been working flawlessly for six months. I've used 2.4 series kernels and 2.6 series kernels on the box in question. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Qdisc statistics project
Hi Antonios. Antonios Chalkiopoulos wrote: As a necessety for my job is to real-time monitor the bytes, packets, packet dropped etc of all the qdiscs working inside the kernel i've tried varius methods: 1. Parse tc -s command output and update a round robin database and use rrdtool to graphically display tc statistics. I have developed myself a similar setup, but i used a perl script with snmp pass_persist to retrieve the data via snmp feed it to MRTG and then display it with a CGI script, since i changed jobs recently i made some changes to the setup and was thinking in creating a sourceforge project. But i don't think it is ready for that yet, i mean, it is working beautifully for me (and in my previous employer) but there are some rough edges to address first. Btw, the setup generates TC, iptables and MRTG configuration from a config file. I think it is time to see how can the setup be improved. [varius perl scripts exist for the above job] 2. Unsuccesfully tried QoS SNMP extensions, in order to use a new MIB to extract qdisc stats from. There is also some work in the kernel level that will help reveal qdisc stats to userspace (thanks Thomas Graf) I have never heard of this, must google it. To get to the point.. the perl parsing method is hackish and quick&dirty. A proper open-source tc monitoring tool SHOULD exist ! Maybe inside iproute2 maybe in sourceforge. I really never tried to write a better tool, with less 'tc -s' parsing, don't have the time or incentive to hack the needed code, so can't help you there :-) Are there any volunteers to start working on such a project? I could put 4-6 weeks full time work on that... any suggestion for the most proper solution to the above problem is welcome. I can forward you the software that i use with some documentation. Thanks, Antonio ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ Hope it Helps José Araújo ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
AW: [Fwd: Re: [LARTC] ssh and cs LAG]
Switching back to older kernel won't do much. I've had this problem much earlier when using two NICs of the same type. I couldn't figure out why, but there ARE problems is many ways when using two cards of the same type. I had problems with sharing, with routing, etc. etc. Best solution is to use different NICs... don't ask me why... I just found out that this will solve the problems... -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Hariett Jones Gesendet: Mittwoch, 13. Oktober 2004 22:13 An: [EMAIL PROTECTED] Betreff: [Fwd: Re: [LARTC] ssh and cs LAG] Got some solutions myself. LAG is caused by : NETDEV WATCHDOG eth0 timeout this is caused bacause of problems with rtl8139 network card in kernel 2.6.x Solutions : 1.add in lilo.conf : append="noapic" 2.turn apic off in bios 3.if u have 2 rtl8139 cards, then exchange one with some other card type (chipset) btw. all above was found in various polish forums, but none has worked for me. im switching kernel back to 2.4.22, and will report later . ___ 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/
[Fwd: Re: [LARTC] ssh and cs LAG]
Got some solutions myself. LAG is caused by : NETDEV WATCHDOG eth0 timeout this is caused bacause of problems with rtl8139 network card in kernel 2.6.x Solutions : 1.add in lilo.conf : append="noapic" 2.turn apic off in bios 3.if u have 2 rtl8139 cards, then exchange one with some other card type (chipset) btw. all above was found in various polish forums, but none has worked for me. im switching kernel back to 2.4.22, and will report later . ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Apologies
Seems I sent an HTML message to the listserv by mistake. Sorry! Mike ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Resetting traffic history
I'm a tc newbie, and I think I am close to being able to use it to control one of the virtual web sites on our Gentoo Linux server. The site has it's own IP address. I have a bit of a problem in that the way I originally configured tc, the busy site grabbed all the bandwidth, leaving none for the other (and more important) sites. Here is how I had configured it: tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL latency 50ms burst $BURST The total data rate was pegged within acceptable limits, but the problem is that data stopped flowing after tc was active after a few hours. The busy site had a few peak periods and presumably used up all the traffic allotment. Perhaps tc remembers the traffic between invocations? I then tried a slightly more sophisticated setup: tc qdisc del dev $DEV root tc qdisc add dev $NIC root handle 1: cbq avpkt 1000 bandwidth 1000mbit tc class add dev $NIC parent 1: classid 1:1 cbq rate $RATE_PROBLEM allot 1500 prio 5 bounded # isolated tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip dst $IP flowid 1:1 Unfortunately, I still don't get any traffic flowing while tc is active now. Seems that I need to reset something. Any suggestions? I've shut down the problem site and disabled tc while I try to figure out a solution. Thanks for your help! Mike mslinn at mslinn.com
Re: [LARTC] Is this actually possible?
>Hi everyone, and thanks for your help so far. > >I have been playing around with tc and htb for a couple of weeks now, and >while I am nowhere near understanding everything here, I am beginning to >know more about packets than I ever wanted to know. > >I have two university buildings with a 1mb connection to the Internet. The >two buildings (on either side of town) are connected through a tunnel >using their internet connection, so that the administration can use the >database across town. They have to share the connection with all the >students on both sides, and the traffic the teachers create. So the people >in admin have a hard time connecting to their database. > >What I have done so far is to create two leaves 1:10 and 1:20 and filtered >the traffic going to the database on the far end. What the admin there >would like is, that the connection is fully available for everyone, until >the secretary wants to look something up on the database. Then it should >have top prority and all the other traffic should virtually stop. > >I managed to apply the filters and have the packets ending up in the right >leaf. But the results are far from satisfactory. > >#!/bin/bash >tc qdisc add dev eth1 root handle 1: htb default 30 >tc class add dev eth1 parent 1: classid 1:1 htb rate 96mbit burst 15k >tc class add dev eth1 parent 1: classid 1:7 htb rate 128kbps burst 15k >tc class add dev eth1 parent 1:1 classid 1:10 htb rate 96mbit burst 15k >tc class add dev eth1 parent 1:7 classid 1:20 htb rate 127kbps ceil 128kbps > burst 15k prio 0 >tc class add dev eth1 parent 1:7 classid 1:30 htb rate 1kbps ceil 128kbps > burst 1k prio 2 >tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 >tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 >tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 >U32="tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32" >$U32 match ip src xx.xx.xx.xx/26 flowid 1:10 >$U32 match ip dst 10.190.19.0/28 match ip sport 19813 0x flowid 1:20 > >Only if I lower the ceiling on leaf 1:30 does it show any results. If I >have the ceiling the same on both, there is no measureable result in >speed. The both seem to share the connection equally. > >Am I missing the point, is it possible at all, or am I just too dum to get >it right? > >Thanks a lot, > >.peter I have the same problem and unable to solve. According to tc-htb man page, if we set PRIO parameter, then after supplying the packets to satisfy the RATE of all classes, the HTB first sends the available packets to LOWEST PRIO class and so on. In this case if the above class 1:20 with PRIO 0 requests packets, than the class 1:30 must receive only 1kbit (the specified RATE), nothing more. In practice class 1:30 shares the bandwidth with class 1:20 and gets not 1kbit, but much more >20kbit. I have TSL 2.1, kernel 2.4.27-3tr. I changed the PSCHED_CPU and disabled the HTB hysteresis, set SFQ queue length to 16, but the results are the same. Is there something wrong with my understanding? Can anyone explain why PRIO not works? Regards, Zviad ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Is this actually possible?
Hi everyone, and thanks for your help so far. I have been playing around with tc and htb for a couple of weeks now, and while I am nowhere near understanding everything here, I am beginning to know more about packets than I ever wanted to know. I have two university buildings with a 1mb connection to the Internet. The two buildings (on either side of town) are connected through a tunnel using their internet connection, so that the administration can use the database across town. They have to share the connection with all the students on both sides, and the traffic the teachers create. So the people in admin have a hard time connecting to their database. What I have done so far is to create two leaves 1:10 and 1:20 and filtered the traffic going to the database on the far end. What the admin there would like is, that the connection is fully available for everyone, until the secretary wants to look something up on the database. Then it should have top prority and all the other traffic should virtually stop. I managed to apply the filters and have the packets ending up in the right leaf. But the results are far from satisfactory. #!/bin/bash tc qdisc add dev eth1 root handle 1: htb default 30 tc class add dev eth1 parent 1: classid 1:1 htb rate 96mbit burst 15k tc class add dev eth1 parent 1: classid 1:7 htb rate 128kbps burst 15k tc class add dev eth1 parent 1:1 classid 1:10 htb rate 96mbit burst 15k tc class add dev eth1 parent 1:7 classid 1:20 htb rate 127kbps ceil 128kbps burst 15k prio 0 tc class add dev eth1 parent 1:7 classid 1:30 htb rate 1kbps ceil 128kbps burst 1k prio 2 tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 U32="tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32" $U32 match ip src xx.xx.xx.xx/26 flowid 1:10 $U32 match ip dst 10.190.19.0/28 match ip sport 19813 0x flowid 1:20 Only if I lower the ceiling on leaf 1:30 does it show any results. If I have the ceiling the same on both, there is no measureable result in speed. The both seem to share the connection equally. Am I missing the point, is it possible at all, or am I just too dum to get it right? Thanks a lot, .peter ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Traffic shaping and tun devices
On 13 October 2004 pm 12:53, Remus wrote: > Hi folks, > I have three network cards on my Slackware box and eth0 and eth1 are for > two Internet connections. They have imq0 and imq1. All traffic shaping > works fine. > Internal eth2 does no traffic shaping. > But recently I have put two OpenVPN tunnels (tun devices) and both work via > eth0. > So my question is - how to shape the traffic on these tun0 and tun1 > devices? > Thanks > Remus Mark on mangle table and place them into IMQ example: iptables -t mangle -o tun0 bla bla bla -j IMQ --todev 0 iptables -t mangle -o tun1 bla bla bla -j IMQ --todev 1 - Rio.Martin - ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Traffic shaping and tun devices
Hi folks, I have three network cards on my Slackware box and eth0 and eth1 are for two Internet connections. They have imq0 and imq1. All traffic shaping works fine. Internal eth2 does no traffic shaping. But recently I have put two OpenVPN tunnels (tun devices) and both work via eth0. So my question is - how to shape the traffic on these tun0 and tun1 devices? Thanks Remus
Re: [LARTC] Traffic Control software port for linux 2.6.X?
On Wed, 2004-10-13 at 03:36, John Zavgren wrote: > Is there a port of this code availble for testing purposes? Wht software? What code? What Testing? tc is already available. I'm using it. -- Ow Mun Heng Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel 2.6.7-2.jul1-interactive Neuromancer 16:36:46 up 7:25, 8 users, load average: 3.44, 1.71, 0.97 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
