Hi R, hi List,
On May 24, 2014, at 16:12 , "R." <[email protected]> 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?
Well, I see a couple of challenges that need to be overcome before this
could work.
In your step 3 you touch the issue of measuring the current stats; and somehow
what is trickier than one would think:
1) what to measure precisely, a "dedicated web server" sounds like a great
idea, but who is dedicating it and where is it located relative to the link
under test?
Rich Brown has made a nice script to measure current throughput and
give an estimate on the effect of link saturation on latency (see
betterspeedtest.sh from https://github.com/richb-hanover/CeroWrtScripts), but
using this from Germany gives:
2014-05-24 15:44:47 Testing against demo.tohojo.dk with 5 simultaneous sessions
while pinging gstatic.com (60 seconds in each direction)
Download: 12.06 Mbps
Upload: 1.99 Mbps
against a server in Europe, but:
Download: 10.42 Mbps
Upload: 1.85 Mbps
against a server on the east side of the USA. So the router would need to
select a close-by server. Sites as speedtest.net offer this kind of server
selection by proximity but do not have a very reliable way to load the link and
do not measure the effect of link saturation on the latency… but the whole idea
is to find the highest bandwidth that foes not cause indecent increase of
latency under load. (Also speed tests are quite stereotypic in observable
behavior and length so some ISPs special case these to look good; but that is a
different kettle of fish…)
Note that there is also the question where one would like to measure
the linkspeed; for example for DSL there is the link to the DSLAM, the link
from the DSLAM to the next network node, sometimes a PPP link to a remote BRAS
system (that might throttle the traffic). All of these can be the bottlenecks
of the ISP connection (depending on circumstances). My take is that one would
like to look at the link between modem and DSLAM as the bottleneck, but the
opinions differ (and then there is cable with its shared first segment...).
2) Some links have quite peculiar properties that are hard to deduce from quick
speed tests. For example ATM based ADSL links (this includes all ADSL1, ADSL2
and to my knowledge all existing ADSL2+ links) will show a packetize dependent
link speed. In short ATM uses an integer number of 48 byte cells to transport
each packet, so worst case it adds 47 bytes to the payload for small packet
that can effectively double the size of the packet on the wire, or stared
differently half the link speed for packets of that size. (Note thanks to the
work of Jesper Brouer and Russel Stuart the linux kernel can take care of that
issue for you, but you need to tell the kernel explicitly.)
3) many links actually do not have a constant wire speed available. For docsis
(basically cable) the local segment is shared between many users and transmit
timeslots are shared between requestors, giving effectively slower links during
peak hours. For DSL a resync between DSLAM and modem can (significantly) change
the negotiated speed; something cerowrt does not get any notice of…
I guess buffer bloat mitigation needs to move into the modems and
DSLAMs to get rid of the bandwidth guessing game. For cable at least the modems
are getting better (thanks to PIE being part of the docsis 3.1? standard), but
for DSL I do not think there is any generic solution on the horizon…
Best Regards
Sebastian
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
