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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
