Hello Andreas, AK> Just to see wether we are going into the right direction at all, could AK> you run the following experiment: AK> - Lower the rate and ceil of class 1:2 to 8096kbit. AK> - Lower the rate and ceil of class 1:2000 to 7072kbit. AK> - Lower the rate and ceil of class 1:3000 to 1024kbit. AK> - For class 1:3010, set rate to 64kbit, ceil to 256kbit. AK> - For class 1:3020, set rate to 128kbit, ceil to 768kbit. AK> - For class 1:3040, set rate to 704kbit, ceil to 1024kbit. AK> - For class 1:5040, set rate to 128kbit, ceil to 1024kbit. I did what you suggested and the results are as expected! You can see this picture to verify: http://elusion.sk/visual_inet_7.png At 4:25 I started HTTP download. P2P class immediately droped down to it's RATE, WWW class got it's RATE. At 4:33 I stopped HTTP download, P2P class got rest of capacity. AK> ... it's just too high rates or r2q/quantum that make it go bad. In this AK> case, you'd have to measure realistic throughput rates of your network AK> (even a 100mbit LAN may not be able to guarantee 100000kbit at all times) AK> and of your internet connection (may not be able to serve 2048kbit at AK> all times). For downstream shaping to work, you have to be the bottleneck. There are messages in syslog like this: kernel: HTB: quantum of class 10002 is big. Consider r2q change. kernel: HTB: quantum of class 12000 is big. Consider r2q change. kernel: HTB: quantum of class 13010 is small. Consider r2q change. Please, are there some hints for setting r2q or quantum parameters? http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm does not give extensive information on this. Or, is it just the matter of testing and searching for optimal parameters? Anyway, thanks a lot Andreas. This was the most important break for me. Rest is just tuning. Best Regards B. Gereg _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
