[ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24
The most recent ESFQ patches are getting stale, and I have received a few requests to update them to a current kernel release. Instead, I added hash type selection to my most recent round of SFQ patches and packaged them up. http://fatooh.org/esfq-2.6/ http://fatooh.org/esfq-2.6/sfq-2.6.24.tar.bz2 The ESFQ code was largely rewritten for inclusion in SFQ--not just a sed job. The SFQ patches should be relatively clean and bug-free. If they're not, please tell me! I have so far been unsuccessful in getting them included in the main Linux kernel, and wider testing may help. The SFQ patches aren't up to date with current net-2.6.25 git; I need to forward-port them before I (once again) try to pester the net developers into reviewing my work. Don't misunderstand me--I know patch review is lots of work as well, and I appreciate the very helpful reviews my first few rounds of patches received. Still, the recent silence has been frustrating. ESFQ, meanwhile, has a few bugs I know about, and it doesn't even survive my new stress test for long without crashing my user-mode Linux. I don't know why, and I'm not going to look. My intent is to let ESFQ stagnate and only develop the SFQ patches further. If you really want the original ESFQ, I have included that in the SFQ tarball. The only modification I have made since the last release is a slight alteration to make it compatible with my SFQ patches. You can run ESFQ and patched SFQ in the same kernel, if that seems useful for testing. Have fun! -Corey - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24
Corey Hickey wrote: > The most recent ESFQ patches are getting stale, and I have received a > few requests to update them to a current kernel release. Instead, I > added hash type selection to my most recent round of SFQ patches and > packaged them up. > > http://fatooh.org/esfq-2.6/ > http://fatooh.org/esfq-2.6/sfq-2.6.24.tar.bz2 This release has a silly typo that prevented the conntrack hash types from being used. The annoying part is that I fixed the bug long ago, tested the fix, and then forgot to apply it to my git tree. Oh well. Grab a new one here: http://fatooh.org/esfq-2.6/sfq-2.6.24.1.tar.bz2 ...or just: $ sed -i s/ESFQ/SFQ/ net/sched/sch_sfq.c -Corey - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24
Brock Noland wrote: > Is this going to be merged anytime soon? Part of it ought to be, but first I need to: - update my patches to recent net-2.6 git (there were major changes) - test thoroughly - submit for review - wait for review - etc. That'll happen when I get more time in the near future. -Corey - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24
David Miller wrote: > From: "Brock Noland" <[EMAIL PROTECTED]> > Date: Sat, 9 Feb 2008 20:30:58 -0600 > >> Is this going to be merged anytime soon? > > If it gets submitted to the proper mailing list, it might. > 'linux-net' is for user questions, it is not where the networking > developers hang out, 'netdev' is. > > And you have to post patches for review, not URL's point to > the patches. It has to be int he email, in an applyable form > so people can review the thing properly. Thanks for the reminder. I have submitted my patches to netdev before, though, and I will submit the next ones there as well. This announcement was intended for the ESFQ users, so they could have some fresh patches to use meanwhile. -Corey - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24
Aleksander Kamenik wrote: > Corey Hickey wrote: >> Please let me know if it works; I haven't tested 2.6.23, but it should >> be ok. > > Thanks, that one #ifdef was indeed the problem. It seams to be working > now. I mean it doesn't give me any errors. :) Excellent. > I've got a few questions about sfq though. You ask some good questions, so I hope you don't mind me CC-ing linux-net; the answers may be of general interest. > perturb: I've set it to 60 (seconds?). Yes, perturbation inverval is in seconds. > It is a just in case thing, if > depth is BIG enough to have contain all the flows, it might as well be > disabled (0) or extremly big like an hour (3600), correct? You ought to use a large divisor (to set the hash table size) as well, but even if you do you still might end up with collisions. With 500 flows and a hash table of 2^14 (divisor 14), the expected number of collisions is approximately 8. You can read the readme file and find formulas for expected collision count and worst-case redistribution time. The worst-case redistribution time when perturbation occurs shouldn't be that bad if your bandwidth is decent, so I bet you can find a nice moderate perturb value. > depth: Say I'm using hash ctorigsrc on the wan interface to hash based > on internal IP's. Say I have 2000 unique users with unique internal > IP's, but a maximum of only 500 users online at the same time. Should I > set the depth to 500 or 2000? Eg, how often are the slots freed? Depth 500 will suffice. Slots are freed as soon as they're empty, so if a flow dries up that slot will be available for another flow momentarily. > From the README, limit chapter: > > "Unless you have a reason to maximize bandwidth and don't care about > latency at all, you should leave limit alone." > > Isn't that a double negative? Doesn't this read "don't want to maximize > bandwidth nor care about latency"? If so, what do you mean by that? I'll fix that for the next release; it's from when I was mistakenly under the impression that limit had to be >= depth, whereas the opposite is true. > Basically my question is, what should I do, if I want to lower latency > (student gamers) and don't care about lost bandwidth (there's enough)? SFQ was intended for fair distribution of bulk traffic; it works well enough for general use, but low latency is not its strong point. > I'm using sfq attached to HTB classes btw. If you can identify gaming traffic by iptables or by tc filters, then create a low-bandwidth high-priority HTB class specifically for game traffic. Having a high burst should be good, too. That's what I did when I was in a similar position a few years ago, and it worked well enough. I knew all my users, though, so it was a simple matter to find out what ports some new game used and add them to the iptables script. You can also check out HFSC; if I understand correctly, it's meant to help address such a situation. I have yet to mess around with it, though. -Corey - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
