[LARTC] tc monitoring

[LARTC] tc monitoring

[Antonios Chalkiopoulos]

I have managed to dynamically parse the output of commands:

tc qdisc ls dev eth0 and 
tc -s class show dev eth0

Save statistics in an rrd database and display it via a php script.
see http://143.233.4.215/graph.php and dload scripts from 
http://143.233.4.210/qos/

My next step in developing this monitoring software is to somehow manage to 
create a tree out of tc and then use it to greatly improve the monitoring 
viewability. Check http://143.233.4.210/qos/applyQoS_Xylouris_v0.20.html

One way is to parse the script that installed the qdiscs into the kernel and 
through parent and handle ids to construct that tree. There is a number of 
problem in the above solution like commented tc commands, no distinction 
between functions applyHTBWondershaper() and applyCBQWondershaper() etc.

So is there a way to use the tc command and manage to get usefull information 
about which qdisc is parent and which is a leaf?

Thanks in advance for your time,

Antonios Chalkiopoulos

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Andreas Klauer]

Am Thursday 30 September 2004 13:31 schrieb Antonios Chalkiopoulos:
> So is there a way to use the tc command and manage to get usefull
> information about which qdisc is parent and which is a leaf?

Well, if there is no child then it is a leaf. You have to do a bit of 
parsing there... tc is not really useful at all for that kind of stuff.

I had the same problem, I wrote a script to create graphs like
this one http://www.metamorpher.de/files/fairnat_ipp2p.png (big image).

The script is http://www.metamorpher.de/files/tc-graph.pl
It creates a graph description which can be used by GraphViz to visualize.

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Thomas Graf]

* Antonios Chalkiopoulos <200409301431.13267.alg0@iit.demokritos.gr> 2004-09-30 14:31
> So is there a way to use the tc command and manage to get usefull information 
> about which qdisc is parent and which is a leaf?

I fixed the missing parent information in changeset:

http://linux.bkbits.net:8080/linux-2.6/cset@1.1992.8.4?nav=index.html|ChangeSet@-2d

It has been included in 2.6.9-rc3.

For prior versions one has to change tc to output the tcm_info field for
leaf classes which contains the handle of the child qdisc.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Antonios Chalkiopoulos]

On Thursday 30 September 2004 14:59, you wrote:
> Am Thursday 30 September 2004 13:31 schrieb Antonios Chalkiopoulos:
> > So is there a way to use the tc command and manage to get usefull
> > information about which qdisc is parent and which is a leaf?
>
> Well, if there is no child then it is a leaf. You have to do a bit of
> parsing there... tc is not really useful at all for that kind of stuff.
>
> I had the same problem, I wrote a script to create graphs like
> this one http://www.metamorpher.de/files/fairnat_ipp2p.png (big image).
>
> The script is http://www.metamorpher.de/files/tc-graph.pl
> It creates a graph description which can be used by GraphViz to visualize.
>
> Andreas

Nice work Andrea! :) The only limitation i noticed so far is that it can not 
properly parse the virtual channels of GRED qdisc. GRED is a tricky qdisc as 
it can contain 1..16 RED qdisc as virtual channels. It shouldn't be too 
complex to implement that feature as the output is straight-forward

qdisc gred 805f:
DP:1 (prio 8) Average Queue 0b Measured Queue 0b
        Packet drops: 0 (forced 0 early 0)
        Packet totals: 0 (bytes 0)  ewma 3 Plog 25 Scell_log 12
DP:2 (prio 8) Average Queue 36110b Measured Queue 35428b
        Packet drops: 517 (forced 0 early 517)
        Packet totals: 14128 (bytes 14721376)  ewma 3 Plog 20 Scell_log 12
Sent 14182662 bytes 13611 pkts (dropped 517, overlimits 517 requeues 0)

Thanks , Antonios Chalkiopoulos
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Andreas Klauer]

Am Thursday 30 September 2004 14:44 schrieb Antonios Chalkiopoulos:
> The only limitation i noticed so far is that it can not properly parse
> the virtual channels of GRED qdisc. GRED is a tricky qdisc as it can
> contain 1..16 RED qdisc as virtual channels.

Ah, sorry, I've never used GRED before, and I wanted to avoid 
QDisc-specific parsing as much as possible. The tc command really isn't 
suited for this kind of application. I really wish there was a library
with a decent API that lets you access this data directly. Parsing tc 
output is just a bad hack. ;)

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Francisco Pereira]

Quoting Andreas Klauer <Andreas.Klauer@metamorpher.de>:

> Am Thursday 30 September 2004 14:44 schrieb Antonios Chalkiopoulos:
> > The only limitation i noticed so far is that it can not properly parse
> > the virtual channels of GRED qdisc. GRED is a tricky qdisc as it can
> > contain 1..16 RED qdisc as virtual channels.
> 
> Ah, sorry, I've never used GRED before, and I wanted to avoid 
> QDisc-specific parsing as much as possible. The tc command really isn't 
> suited for this kind of application. I really wish there was a library
> with a decent API that lets you access this data directly. Parsing tc 
> output is just a bad hack. ;)

I know of these projects, but only lql seems to be active.
Linux QoS Library (lql)
http://www.coverfire.com/lql/

An API for Linux QoS Support
http://www.ittc.ukans.edu/~pramodh/courses/linux_qos/mainpage.html

TC API Projec
http://www-124.ibm.com/developerworks/projects/tcapi 



----------------------------------------------------------
0909 2468 La conexion discada a internet del Portal

La misma conexion pero MEJOR y MAS BARATA

Bajate el discador en http://www.montevideo.com.uy/0909


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] tc monitoring

[Jason Boxman]

On Thursday 30 September 2004 09:06, Andreas Klauer wrote:
<snip>
> Ah, sorry, I've never used GRED before, and I wanted to avoid
> QDisc-specific parsing as much as possible. The tc command really isn't
> suited for this kind of application. I really wish there was a library
> with a decent API that lets you access this data directly. Parsing tc
> output is just a bad hack. ;)

There's also SNMP extensions for QoS.

http://x-ray.prokon.cz/data/snmp/downloads/

-- 

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 / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

RE: [LARTC] tc monitoring

[Michael S. Kazmier]

> There's also SNMP extensions for QoS.
> 
> http://x-ray.prokon.cz/data/snmp/downloads/
> 


Has anyone tried this on a 2.6 kernel?  I talked with Michal Charvat, the
author of the QoS SNMP extensions and he has not looked at the 2.6 kernel
but fears that is where the problem lies.  Any ideas??

--Mike

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/