Javier Ors wrote:
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.
Ahh OK embedded. There may be hope then. I know that TI AR7 based
routers don't have a buffer beyond the device. The one I tested didn't
have any qdiscs built in apart from TIs prio/wrr, but it did work
without any rate limiting.
The buffer that I was talking about would not have been the 100
txqueuelen, but would have filled up before any packets got queued in that.
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...
Was latency OK? If you can put a simple prio on the device with ICMP
(and I suppose arp to be safe since your connection is bridged) to high
band and all other to low, flood it with data and you still get good
latency then there isn't much of a buffer beyond the device.
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...
Yes I suppose that should be OK as long as the % wasn't too high.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
