> lets say I want to limit traffic to/from client to 64kbit. now, client opens > a tcp connection blasting away at full speed. > > If client now pings isp, it gets on average around 7 seconds latency. I > tried to improve this by using SFQ on the leaf nodes of my HTB hierarchy, > but that does not really improve the situation, only makes it much worse. > with SFQ I get anything between 250ms and 13 seconds latency. You understand what's going on here? As I recall, both pfifo and sfq default to queues of length 128 packets. If you fill that with 1500 byte packets you have ~200Kbytes which is about 1.6Mbits. At 64Kbit/sec that would take ~30 sec to send so your latency could be as high as 30 sec. You can limit this latency by reducing the queue size. On the other hand, the application that fills the queue evidently doesn't mind large latency. Otherwise it wouldn't fill the queue. I think I posted to this list once a description (maybe even the code?) of another way to limit latency - drop packets that have been in the queue for more than a timeout period (I tend to use 3 sec). SFQ should have the desirable result that one tcp connection won't slow down another one or a ping. > I then tried fifos. With small packet fifos the packet loss is just > to great to be of any use and even then the latency is quite high (~200ms). You consider 200ms high? One max size packet = 1500 bytes = 12Kbit which is about 200ms on a 64Kbit link. You can't expect to do better. > I'm thinking of using RED, but the number of parameters is daunting and I > have no idea how the HTB rate correlates to packet size and burst rates for > red. RED should be independent of HTB. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
