27/03/2005 @09:50:16 ^11:46:22

0044 <RjY> hahahahaha fucking score i successfully trolled fdave

Second update today, I hated the previous one.

Weird shit with traffic control I feel I should share

Last week I changed my traffic control script after I had a complaint of this site not working at all! The only thing I thought the trouble could be was I'd too aggressively shaped the webserver's bandwidth. For some reason I have five bands, as follows:

PriorityNameClassificationGuaranteed
bandwidth
Note
1ssh(dport==ssh &&
TOS==mindelay)
LOTSinteractive ssh traffic (not
scp, that sets TOS=bulk)
2highTOS==mindelay ||
dport==irc ||
length==0..64
LOTS=> ntp uses TOS==mindelay
=> reduce server ping/pong lag
=> tiny packets don't clog link much
3normalno matching rulesA BIT LESSdefaults to here
4bulkTOS==bulk ||
dport==smtp
NOT MUCHProbably could merge normal and bulk.
SMTP priority is arguable
5crapTOS==mincost ||
sport==http
NONE!!Nothing actually uses TOS==mincost!
sport => outgoing web traffic

Crap had as near to zero bandwidth as I could give it without tc complaining. Now most of the time my own outgoing traffic is chopped up into very small packets that don't clog up the connection. You know, a few ssh packets here as I'm typing into something, a few http ack packets from downloading a webpage, etc. However on this one occasion I choked up the entire "bulk" band uploading files to dog. Of course this hardly affected any of the higher priorities (which is the point) but caused the webserver to effectively be stalled, leaving the person who'd just tried to connect hanging and it looked for all the world like my site was down. This clearly isn't right.

So I investigate HTB a bit further, and find myself trying to get the concept of quantums [sic] Simply put, HTB processes a quantum's worth of bytes for each priority. The default size of a quantum is 10 multiplied by your interface's MTU, which is typically 1500 bytes. So HTB is working in units of 15000 bytes every second, which given that I only have about 24000 bytes per second of upload bandwidth, is a bit too coarse! Anyway this is easily solved by putting r2q 1 on your tc qdisc add command. Thus a quantum is 1500 bytes (per second), and this is the smallest unit I can shape.

So I set all the rates to multiples of the quantum size (that is the MTU size since r2q is 1) As I say the smallest one is 1 quantum per second so the web server has a guaranteed 1500B/s. This is probably enough for SNAFU at least... All the others I set to multiples of the quantum size. I think they all sum to the total upstream bandwidth. I'm not sure what would happen if they summed to more than that; if they summed to less, you'd be wasting upstream...

Oh yeah I set the bursts etc. for each of the classes to multiples of the quantum size as well. I'm not so sure about this burst thing, really, I mean the concept is obvious but I'm just guessing at the numbers. I guess I need some sort of traffic profiler.