Depends on the type of the provider. Most providers now have shared paths to
the backbone among users and give a peak rate up and down for brief periods
that they will not sustain... In fact they usually penalize use of the peak
rate by reducing the rate after that.
So at what point they create bloat in their access net is hard to determine.
And it depends on your neighbors' behavior as well.
The number you want is the bloatedness of your path through the access provider.
This is measurable by sending small probes back and forth to a measurement
server... Measuring instantaneous latency in each direction and combining that
information with one's recent history in a non trivial calculation.
Note that that measurement does not directly produce provider speeds that can
be input to the shapers used in codel. But it does produce a queue size that
can.
So it's a plausible way to proceed as long as the operators refuse to fix their
gear to manage the actual link that is problematic.
Personally I'd suggest that the gear makers' feet be held to the fire... by not
"fixing" it by an inferior fix at the home router. Keep the pressure on them at
IETF and among their customers.
On May 24, 2014, "R." <red...@gmail.com> wrote:
>>> I should point out that another issue with deploying fq_codel widely
>is that it requires an accurate measurement (currently) of the
>providers bandwidth.
>
>Pardon my noobiness, but is there a technical obstacle that prevents
>the creation of a user-triggered function on the router side that
>measures the provider's bandwidth?
>
>Function, when (luci-gui?) triggered, would:
>
>1. Ensure that internet connectivity is present.
>2. Disconnect all clients.
>3. Engage in DL and UL on a dedicated web server, measure stats and
>straight up use them in fq_codel -- or suggest them in appropriate
>QoS-gui user-boxes.
>
>Further, this function could be auto-scheduled or made enabled on
>router boot up.
>
>I must be missing something important which prevents this. What is it?
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel
-- Sent from my Android device with K-@ Mail. Please excuse my brevity.
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
