Technicolor TG582n & Multiasking

[#1]

No need to guess the bandwidth, or rely on the Current Line speed which can lag the BT IP profile. Just drop the PPP session and then Reconnect. The establishment of a new PPP session ensures that the current Downstream and Upstream rates are correctly reported. Then run the BTw Performance test (ignore the red preamble except make sure no other programs are using the Internet) and at the end of the first run, click the Further Diagnostics button, enter just your Phone number and Run the Further Diagnostics Test. The result will give you the current IP Profile for the Line. Depending on the stability of your connection, you may choose to use the actual download speed as the currently available Bandwidth.

[#2]

There's no need to know the line speed with this method.
It places traffic in to different priority queues it doesn't throttle traffic to specific throughput rates.
AFAIK it works just the same on a fibre connection as it does on ADSL.
Like all such domestic systems it only has influence over the LAN traffic, it has no influence over downstream traffic through the ISP's network.

[#3]

That's not true, the point is to handle queuing and priority of packets before the bottleneck of your ADSL/VDSL connection.
First IPQOS determines in what order things are sent out, and sometimes in what order packets are dropped from the buffer, on the link it's set on. It does not, and can not alter the speed of inbound traffic. Outbound traffic management is actually *all* it does. And the configuration you used sets it on the WAN output. You *can* set it on the LAN side, but that's not going to have any realistic effect unless you're doing an unusual amount of internal bandwidth consumption on your home network. In which case, you don't want to bottleneck your traffic on a 10/100 switch in the first place.
Second, QOS does require knowledge of the available bandwidth. QOS is *not* just ordered priority queues. The TG585n uses WFQ QOS, it takes a percentage of the bandwidth available, and then subdivides that percentage between it's class queues. With two extra queues for expedited traffic, and traffic that can always be delayed. When traffic is congested, it will start throttling the lower queues until they are only occupying their percentage of traffic available.
Of course, this means that the WFQ QOS system always needs to know what bandwidth is truly available. Most other QOS systems work along the same lines of working out acceptable percentages of bandwidth use.
The problem with the TG582n appears to be that it doesn't have a simpler ordered priority queue to fall back on when it can't do QOS. (Unless I've missed something looking over it's documentation.) And it flat out won't let you set queues on pppoe connections. Of course, with 20MB upstream that's probably a moot point for most fibre users.

[#4]

You're complicating what is a simple implementation of IPQoS.

Quote from: barberio

The problem with the TG582n appears to be that it doesn't have a simpler ordered priority queue to fall back on when it can't do QOS. (Unless I've missed something looking over it's documentation.)

But that's exactly what Thomson's implementation of IPQoS does do -- place traffic in queues of differing priority.

[#5]

WFQ is Weighted Fair Queue, again explicitly not just priority queues. For WFQ to work, the rate of flow needs to be defined. It's possible to make a queue system that just uses naive ranked FIFOs, but in practice this doesn't provide much benefit and in some circumstances can detriment throughput.
The TG585n creates WFQ prioritisation. The TG585n *can* also do naive FIFO queues, but it still won't let you set up queues on ethernet tunnelled interfaces. I assume because they didn't want it to fail if WFQ was attempted.
dick:quote