Stuart Clark wrote:
> I see what you are getting at, but I'd argue that is a different feature
> connected but independent of QoS, being bandwidth throttling. And a lot
> of routers which might support QoS don't also do throttling
I'm not too sure actually! But to ensure satisfactory QoS the router
needs to establish just what rate it can send before it'll loose
packets. It is therefore helpful in my view if you can manually specify
this. On a per-class basis as well would be even better (you CAN on
tomato and assign minimum-max data rates per class. Makes a consumer
grade router really, really impressive!)
If the router doesn't know what data rate the line can take, how does it
know where to stop so queues don't get full? If it's a cable modem, it
can't see the queue on the cable modem.
So if you set the limit at 99% of what the line can take, and then shape
the traffic based on this (into the various classes) your EF traffic
should be fine, and not subject to delay due to the queue, or drops due
to the queue being full.
Obviously I appreciate a combined modem/router (i.e: ADSL router) can
see the Queues on its own interface (I'd assume) so it can work out if
it's trying to send more than the line will take.
> It is unfortunate that more don't include such feature as they aren't
> really that complex to write (though making them simple to control for
> the average user can be a challenge) as they just use CPU rather than
> needing additional hardware (assuming the CPU power is sufficient as is
> RAM/flash), especially for the increasingly common case of cable modems
> with 100baseT connectors.
Tomato on the Linksys WRT54G does - I can't give enough praise to this
firmware. Some of the firmware you couldn't specify the limit and it
didn't really work without it to be honest.
I guess if you're router is a linux one running for example busybox, you
could always muck about and do it yourself, with iptables? I'm not a
linux person though so I wouldn't really have the first clue about how
to actually do it.