Re: [ANNOUNCE] ESFQ --> SFQ patches for Linux 2.6.24

[Corey Hickey]

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