[LEDE-DEV] TR-069, bufferbloat, and BQL

[John Crispin]

On 28/05/2016 16:02, Hauke Mehrtens wrote:
> On 05/28/2016 03:36 PM, Dave Taht wrote:
>> On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens <hauke at hauke-m.de> wrote:
>>> On 05/27/2016 12:43 PM, David Lang wrote:
>>>> On Thu, 26 May 2016, Delbar Jos wrote:
>>>>
>>>>> We are conscious of the fact that together with the proposals made by
>>>>> Felix, Luka and Wojtek we are now looking at many "competing"
>>>>> proposals. As a next step, we recommend to organize a workshop, at a
>>>>> practical location and time, where we put everything on the table and
>>>>> define the most appropriate path forward to the benefit of OpenWrt as
>>>>> a whole.
>>>>
>>>> nothing wrong with supporting many different remote management daemons.
>>>>
>>>>> TR-069 is a complicated remote management system and in order to make
>>>>> this initiative a success, we must ensure that the complexity is
>>>>> handled in an elegant way and with respect for OpenWrt's core
>>>>> architecture. More than on the protocol itself, we believe that we
>>>>> should focus on the architectural enhancements required to support
>>>>> remote management in general.
>>>>
>>>> What is it that you think is needed to "support remote management in
>>>> general"?
>>
>> I am curious if TR-069 has any ability to set parameters for upload
>> and download speeds, so they could be leveraged by sqm-scripts to
>> manage the bufferbloat that DSL modems and dslams have?
>>
>> Also:
>>
>> I have been hoping for nearly 4 years now that we'd see *someone*
>> actually produce a BQL enabled dsl driver for their modem interface so
>> advanced QoS techniques wouldn't be needed on outbound, where we could
>> just enable fq-codel on top of a tightly written driver and be done
>> with it. 100 million modems, all exhibiting 100s of ms of extra,
>> unneeded latency, under load:
>>
>> http://www.dslreports.com/speedtest/results/bufferbloat?up=1
>>
>> sadly, aside from the freebox revolution v6, I'm not aware of anyone
>> actually doing dsl more right yet. (?)
>>
> 
> The Lantiq / Intel DSL drivers are open source and integrated in
> OpenWrt, but I haven't checked if BQL is implemented there. They are
> also using a big firmware which does all the PHY related stuff.
> 
> You can get some statistics from the device like this. These information
> are from the DSL PHY layer, so it does not show when your ISP would
> limit your rate somewhere else in the internal network, but these
> information are available on all DSL lines.


there is no BQL and there is a 256 packet buffer in the driver.

if i am not mistaken, there is a secondary 64 packet ring handled by the
firmware blob.

	John

> 
> root at lede:~# /etc/init.d/dsl_control status
> ATU-C Vendor ID:                          Broadcom 176.15
> ATU-C System Vendor ID:                   Broadcom
> Chipset:                                  Lantiq-VRX200 Unknown
> Firmware Version:                         5.7.3.3.0.6
> API Version:                              4.16.6.3
> XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x2
> Annex:                                    B
> Line Mode:                                G.993.2 (VDSL2)
> Profile:                                  17a
> Line State:                               UP [0x801: showtime_tc_sync]
> Forward Error Correction Seconds (FECS):  Near: 0 / Far: 2116802
> Errored seconds (ES):                     Near: 0 / Far: 2938
> Severely Errored Seconds (SES):           Near: 0 / Far: 50
> Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
> Unavailable Seconds (UAS):                Near: 31 / Far: 31
> Header Error Code Errors (HEC):           Near: 0 / Far: 0
> Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
> Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
> Power Management Mode:                    L0 - Synchronized
> Latency / Interleave Delay:               Down: Interleave (8.0 ms) /
> Up: Interleave (4.0 ms)
> Data Rate:                                Down: 51.391 Mb/s / Up: 10.046
> Mb/s
> Line Attenuation (LATN):                  Down: 10.6dB / Up: 10.6dB
> Signal Attenuation (SATN):                Down: 10.6dB / Up: 10.2dB
> Noise Margin (SNR):                       Down: 7.7dB / Up: 13.9dB
> Aggregate Transmit Power (ACTATP):        Down: -11.6dB / Up: 12.5dB
> Max. Attainable Data Rate (ATTNDR):       Down: 61.928 Mb/s / Up: 23.355
> Mb/s
> Line Uptime Seconds:                      62
> Line Uptime:                              1m 2s
> root at lede:~#
> 
> Hauke
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>