On 05/28/2016 03:36 PM, Dave Taht wrote: > On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens <ha...@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. root@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@lede:~# Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
