Javier Ors wrote:
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.
Then I am a lucky guy, this is mine:
http://wiki.openwrt.org/OpenWrtDocs/Hardware/D-Link/DSL-G624T
I didn't looked for it, it was just the one that the ISP gave to me with the
connection. I was quite surprised when I realized that it was ssh-accesible,
and even more when I checked that it has htb, cbq, sfq, prio, and even red
with ecn. It seems that I recieved a good machine after all. As you see they
are trying to port OpenWrt to it, if they got it maybe it'll be possible to
apply russell's patches.
That's handy :-)
I guess the wireless ones have a bit more room for a better kernel, the
non wireless one I use only has 2meg flash and 8meg ram.
Thanks again for all the info, luckily it's not the case, the latency is no
more penalized than 20 ms in this situation, so it's ok, no buffers.
Just a question anyway...let's suppose that we have big buffers in the
device and this penalize the latency, Would this buffers also prevent from
shaping with a simple prio? As I undertand, they shoudn't as long as any
packet gets dropped between the qdisc and the device buffers, they would
just fill up and then the queue would propagate to the qdisc, where the
packet drop and the shaping should be done. Is this not the case for all
drivers/interfaces?
It could work, but if the buffers are quite big two (unscaled) tcp
connections won't fill them.
Yes I suppose that should be OK as long as the % wasn't too high.
I have also observed this behaviour but I hardly undertand it. HTB works
well only if you set a rate some % smaller than the congestion rate, then
when you see tc -s class show, all the classes have relatively large queues
(backlogged packets), and the shaping is smooth. But if you set the rate
closer to the congestion rate (or higher) then you start to see empty
queues in the classes and/or with few backlogged packets.
I can undertand this happening in a LAN, but not in the adsl modem
interface, theoretically the interface won't dequeue packets at a higer rate
that it can send them. So the queues should form anyway in the classes
whatever high rate you set to the root class... Otherwise neither HTB nor
the prio class would work without rate limiting (like in a LAN), so I don't
understand why in this case it works for the prio but not for HTB.
I can't think why that should be, I was thinking more of the P2P class
being starved if the % was too high.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
