[Announce] LARTC wiki available

[Niccolò Belli]

Since I keep receiving lots of visits to lartc.linuxsystems.it from=20
spinics archives & co, I'd like to point out I closed the wiki when the=
=20
original domain changed maintainer:=20
http://www.spinics.net/lists/lartc/msg22400.html

http://lartc.org is alive and kicking and there is no need for another=20
wiki anymore. I'd like to thank both Bert and Carl-Daniel.

Niccol=F2

Hi,
I still didn't find a viable solution for the LARTC wiki, so I decide=

d

to start hosting it on my own server. Later we can easily switch
somewhere else if we keep using the same wiki engine (and maybe even
with another wiki engine).
I decided to use wikimedia because it's the only one I know of, so if
someone knows a better alternative please let me know, we are still i=

n

time for a change.
Since I never used a wiki seriously I will probably need someone else
who can help me maintaining it, please let me know if you are
experienced and willing to help.
Here is the wiki: http://lartc.linuxsystems.it/
http://vger.kernel.org/vger-lists.html#lartc
I just copy-pasted the Linux Advanced Routing & Traffic Control HOWTO
atm, it still needs to be wikified and we still need to choose how to
organize the contents.
Cheers,
Niccol=F2

[Julien Vehent]

Post by Niccolò Belli
http://lartc.org is alive and kicking and there is no need for
another
wiki anymore. I'd like to thank both Bert and Carl-Daniel.
Niccol=C3=B2

Very cool !
I'll try to find some time and move over some of the content I have her=
e:=20
http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:t=
raffic_control

--=20
Julien Vehent - http://1nw.eu/!j

[Andy Furniss]

Post by Julien Vehent

Post by Niccolò Belli
http://lartc.org is alive and kicking and there is no need for
another
wiki anymore. I'd like to thank both Bert and Carl-Daniel.
Niccol=C3=B2

Very cool !
I'll try to find some time and move over some of the content I have
http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking=

:traffic_control

A couple of things that stand out after skimming through.

DSL - Jeesper's overhead as noted in the comments is not 5 and anyway I=
=20
think his good work has now been superseded by stab as it allows for=20
negative overheads, which his did not.

man tc-stab has clear and good explanations and examples.

SFQ - well it's literally been years since I knew it in detail, but=20
limit was (back then at least) for all flows combined.

I tested (maybe not hard enough) quantum < mtu and never managed to=20
prevent dequeues - I know it's not efficient and "forbiden" but back=20
then at least it didn't break.

Anyway it seems that early this year SFQ got some love and now has=20
several more options (red, headdrop, limit >127, depth as param) - so a=
s=20
long as your iproute/kernel is current have a look at man tc-sfq for=20
details.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andy Furniss]

Post by Andy Furniss
I tested (maybe not hard enough) quantum < mtu and never managed to
prevent dequeues - I know it's not efficient and "forbiden" but back
then at least it didn't break.

Forgot to say -

also remember mtu as seen by tc on eth has 14 added - default quantum on
sfq, htb etc are 1514 as you can see with tc -s -d qdisc ls etc.

[Eric Dumazet]

Post by Andy Furniss
Anyway it seems that early this year SFQ got some love and now has
several more options (red, headdrop, limit >127, depth as param) - so as
long as your iproute/kernel is current have a look at man tc-sfq for
details.

Yes, but fq_codel is really better than SFQ.

[Andy Furniss]

Post by Eric Dumazet

Post by Andy Furniss
Anyway it seems that early this year SFQ got some love and now has
several more options (red, headdrop, limit>127, depth as param) - so as
long as your iproute/kernel is current have a look at man tc-sfq for
details.

Yes, but fq_codel is really better than SFQ.

Ooh, that does look interesting. I hadn't seen that, thanks.
I should really start checking netdev again.

Just pulled iproute git, and see there is a man for codel, but not
fq_codel (yet?).
It would be handy if it/them were added to man tc's "SEE ALSO" section.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jesper Dangaard Brouer]

Post by Andy Furniss

Post by Julien Vehent

Post by Niccolò Belli
http://lartc.org is alive and kicking and there is no need for
another
wiki anymore. I'd like to thank both Bert and Carl-Daniel.
Niccolò

Very cool !
I'll try to find some time and move over some of the content I have
http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:traffic_control

A couple of things that stand out after skimming through.
DSL - Jeesper's overhead as noted in the comments is not 5 and anyway I think
his good work has now been superseded by stab as it allows for negative
overheads, which his did not.

Thanks for the credits :-)

Its been a while since I looked at that code. I think, the 5 bytes might
ref to the ATM header 5 + 48 = 53 bytes the ATM cell size. But 5 is not
used as overhead.

The linklayer ATM hack is to adjust the rtable array, that the kernel uses
for lookups. The problem is that the rtable array only have an 8 bytes
"resolution" (well depend on cell_log), thus to get this aligned, I use
the ATM payload size of 48, when populating the rtable array. Then
when storing the "data" I the rtable array I use *53 byte ATM cell size.

Post by Andy Furniss
man tc-stab has clear and good explanations and examples.

Good to see some documentation on stab, I always found it difficult to
use.

Cheers,
Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

[Philip Prindeville]

Hi,
I still didn't find a viable solution for the LARTC wiki, so I decide=

d=20

to start hosting it on my own server. Later we can easily switch=20
somewhere else if we keep using the same wiki engine (and maybe even=20
with another wiki engine).
I decided to use wikimedia because it's the only one I know of, so if=

=20

someone knows a better alternative please let me know, we are still i=

n=20

time for a change.
Since I never used a wiki seriously I will probably need someone else=

=20

who can help me maintaining it, please let me know if you are=20
experienced and willing to help.
=20
Here is the wiki: http://lartc.linuxsystems.it/
And here is the new mailing list for those who still don't know:=20
http://vger.kernel.org/vger-lists.html#lartc
=20
I just copy-pasted the Linux Advanced Routing & Traffic Control HOWTO=

=20

atm, it still needs to be wikified and we still need to choose how to=

=20

organize the contents.
=20
Cheers,
Niccol=F2

Between command-line stuff for users/administrators and the kernel hack=
ing bits on linux-net, etc. I'd like to see a middle ground: i.e. bette=
r documentation about the C API to userspace from the kernel routing me=
chanisms.

Better documentation about rtnetlink would be appreciated, and maybe th=
e low-level libraries that run atop that as well, such as libmnl.

-Philip
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html