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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
