Mike-Bracknell (guest) 08 Jan 2013 16:13
I'd like to see some way of automating the determination of maximum bandwidth through a link so that the bandwidth limiter could be set automatically at a %age of bandwidth rather than a static figure.
i.e. in order for QoS to work properly, Toastman's QoS rules are good but not ideal. I now have a set of rules which work more reliably when used with a VoIP call behind the router and other traffic's occurring. This incorporates the use of the bandwidth limiter to limit the total bandwidth overhead to e.g. 70% of the line speed, and hence produces repeatable good quality VoIP calls. However, there's always this nagging doubt that the line speed is based upon what the attached ADSL modem syncs at, and the Tomato router has no knowledge of this fact. This might cause problems if you set the bandwidth limiter on a "good day" for ADSL and then come back a day later and the modem has resynced at a lower speed meaning the limiter is ineffective. It would also allow people who have set their bandwidth limiter on a "bad day" to have the limit raised on a subsequent faster resync.
e.g. my line speed at home is 3400kbit/s down and 448kbit/s up. I set the bandwidth limiter to 2700kbit/s and 300kbit/s and as a result I never get any packet speed above that. i.e. If my line then resyncs at 3800kbit/s I will never see the extra 400kbit/s due to the manual limiter placed on the line. Worse still is if the line syncs at anything under 3000kbit/s, as that can impact VoIP quality irrespective of other QoS settings.
What would be nice is an option to auto-set the limiter (and the associated speeds in the QoS section) based upon a nightly speedtest (or maybe the aggregates of several) so that the limiter is set appropriately at all times. I wouldn't want to see the manual setting disappear (as you may need to override any auto-setting for any reason), but it would be nice to have an option to do this. Potentially you could also link it to the graphing of IP traffic, such that any maxing-out of throughput which isn't hitting the limiter is flagged up and a retraining of the limiter occurs?
Thanks,
Mike.
