> Probably, both my PCI modems still had big buffers beyond the ppp that I > shaped on. Even if nas0 did only accept traffic when it had finished > transmitting I don't think you could do what you want above.
The problem is that DSL sync rates are ATM rates so there are quite alot > of overheads. A small eg. ack packet may be seen as 40 bytes by HTB on > nas0, but will use 106 bytes (2 cells) on the wire. If you connection is > highly asymmetric acks can eat a fair chunk of upload bandwidth. It > affects bigger packets aswell 1500 = 32 cells = 1696 bytes ATM level. Thank you for so technical answer, I suppose that this explains why the saturation speed (the one the line reaches with no shaping), is always 85%~95% of the negotiated speed that I see in the router configuration page. About the buffer size... is the same as the txqueuelength value shown in ifconfig?, it is set at 100 (packets I suppose), but it can be changed. I have no ppp encapsulation, it's a bridged connection, so the packets go directly to this interface... There is a solution, but you'll need to patch your kernel and > iproute2(tc), and find out what your overheads are - it depends how you > connect to your ISP, see - > > http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ > > To handle your varying sync rate you would need to make a script to > check periodically and restart your script with the new rate. > > If you patch you can run almost at sync rate - back off a few kbit to > allow for modem rounding down to whole cells/sec for it's own aal0/5 QOS > and if ppp lcp pings can eat a a few bits/sec if used. Also to cover > yourself for restarting the script when active so any backlog can slowly > drain. > Very interesting information, anyway I think that I'll not need to do this, (I don't even think I can, patching the kernel and the iproute2 that run on the embedded system in the router, bufff...) Hopefully, I have found a simple solution that can achive the proposed goals... It still need further testing, but I think it'll work. I post it here, maybe someone else could be interested. This is what I've tested so far: prio qdisc | -------------------------- | | lower prio higher prio | | pfifo htb* | limit 60KB/s | | p2p ftp *(tbf could also have been used for this simple test) The results of this test were succesfull. I mean, with only the p2p the line was running al full saturation speed, when I started to use the ftp it reached the 60KB/s limit without problems with p2p taking the rest of the line, wich never stopped working at full speed. Given this results, I think that the following scheme will work like a charm... prio qdisc | ------------------------------------------------------ | | | low priority medium priority high priority | | | sfq htb pfifo | dynamic limit | | | | p2p ftp, web, mail... small ACK's, ICMP, ssh... As you told me, I think that I can make a script that constantly checks the top speed on the prio (which will allways be saturated due to the p2p), and adjust the htb limit to some % of it, or substracting a fixed quantity (the quantity that will rest for the p2p when running ftp at full speed, which is what I wated to achieve in the beginning). I hope it'll work...
_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
