LARTC wiki available

Hi,
I still didn't find a viable solution for the LARTC wiki, so I decided 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 in 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/
And here is the new mailing list for those who still don't know: 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ò

What about

http://www.linuxfoundation.org/collaborate/workgroups/networking/group

Il 29/12/2011 01:27, Hagen Paul Pfeifer ha scritto:

I saw it, but I didn't like it because unregistered users cannot edit the wiki and even registered users need an invite. Also, it seems quite confusing, a traditional wiki is a better solution in my opinion.

Niccolò

Anybody knows that network stack lacks documentation - no doubt. Maybe a wiki is an adequate concept (beside man pages and in Kernel docs). Everybody, not restricted to kernel hackers, can edit documentation and add examples.

Maybe the netem wiki page at

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

is a good example for a good documented subsystem.

But I don't like the idea to outhouse the existing wiki. Why two wikis? What happened with the wiki server if you leave the university? So maybe the user restriction on linuxfoundation.org should be changed? I strongly suggest to keep to documentation as tightly as possible to linuxfoundation (or
https://www.wiki.kernel.org/).

Hagen

Il 29/12/2011 17:19, Hagen Paul Pfeifer ha scritto:

Because if you need an invite to edit something then it isn't a wiki anymore, for example.

This isn't a problem, because relocating would be as simple as doing a database dump. Releasing dumps publicly wouldn't be a problem too. Also, there is no reason to keep using my servers when better alternatives arise. I created the wiki in a dedicated server because I didn't find viable alternatives (unlike for the mailing list) and considering the few feedbacks I received hopefully doing something tangible would create more interest: I'm pretty sure I'm not the only one who thinks there isn't enough documentation for the *end user*.

Yes, IMHO.

It seems a wiki for a kernel hacker, not for the end user.

P.S.
Feedbacks are welcome, if there is no interest at all maybe we should just discard the idea after all.

Thanks,
Niccolò

----- Original Message -----

I can certainly concur that there is a lack of end user documentation. I have found the net devs extremely helpful and am deeply grateful for their support but I do sometimes chuckle because the documentation and the responses are written from such a developer's context. Of course, that is entirely expected and I don't mean the least bit of disrespect; I stand in complete awe of the net devs.

But the needs and perspectives of net devs and system engineers/admins are very different and rightly so. So, I'd love to see a hybrid environment where we have the best of both worlds (but where sys admin types don't feel completely lost and overwhelmed). Thanks, all - John

Wikis seem to be massive spam targets at the moment (I run a small wiki, I added registration to try and limit spammers, then I added silly captchas, then I added some auto spam word recognition. I'm now at the point that for such a small and niche wiki I might just get people to apply to me personally for an edit option, it's just too boring dealing with the spam...)

Good luck

Ed W

Il 02/01/2012 13:48, Ed W ha scritto:

Thank you for your answer, I wanted a wiki because I want lartc to be as independent as possible, the final goal is to find someone who can assure continuity to the documentation even if I give up (like vger for the ml): I want to avoid what happened to lartc.org and the old mailing list.

Did you try ReCAPTCHA (http://www.mediawiki.org/wiki/Extension:ReCAPTCHA)? Do you use mediawiki or something else?

Again, if someone is experienced and willing to help, any help is appreciated. I can share ftp/phpmyadmin if someone wants to co-maintain it.

Thanks,
Niccolò

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

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ò

Il 28/12/2011 16:52, Niccolò Belli ha scritto:

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

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

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.

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

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

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.

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.

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.

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.

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.

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
-------------------------------------------------------------------

Between command-line stuff for users/administrators and the kernel hacking bits on linux-net, etc. I'd like to see a middle ground: i.e. better documentation about the C API to userspace from the kernel routing mechanisms.

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

-Philip