Sorry for the mess posted before. I hit send by mistake. On Thu, 2006-02-23 at 19:49 -0800, gypsy wrote: > Two more things. HTTP is a bursty protocol, so you need to think about > the burst and cburst parameters you give it. I had already figured out that I had to sent burst as small as possible, but the HTB User Guide says "Latest tc tool will compute and set the smallest possible burst when it is not specified", so I had left it alone. In fact it defaults to 1919 bytes in my case. Looking at the TC source, this is calculated as: (rate_in_bytes_per_second / HZ) + mtu and then rounded up to the next entry in the rate table. Perhaps: max(rate_in_bytes_per_second / HZ, mtu) would of been a better choice. In my case that will evaluate to the mtu, so I will try that. > If you want to squash TCP > fast start, use a low burst which will backlog and eventually drop the > excessive packets. On the other hand, my experience is that a slow > started connection never increases its flow rate much even though the > spec says it should. And you can get better precision from HTB by > setting HYSTERYSIS (did I just misspell that?), thus dequeueing a single > packet rather than a pair. I don't recommend that, but you should know > about it. On many ATM links it is a godsend. Looking at the kernel code, HTB_HYSTERESIS is set in kernel.org kernels as shipped. You have to unset it if you have large (>100K byte) bursts, apparently. > In terms of headroom, I find that 85 % of real capacity always works, so > I start with that and push up until something breaks. YMMV. Excellent! Thank you. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
