On Thu, Sep 10, 2015 at 7:11 AM, David Reader <da...@reader.me.uk> wrote: > > > On 10 Sep 2015, at 14:00, Dave Taht wrote: > >> I would in general, like to be building better CPE with open drivers >> all the way down the stack. >> >> has anyone seen this effort yet? >> >> https://lite.turris.cz/en/ > > > Yes. > > The problems, really, are around the closed-ness and un-availability of the > xDSL chipsets and their documentation. > > There are lots of low cost ethernet boards out there. > > IMO the world would be a better place if it were possible to have more hands > and eyes iterating over the xDSL stuff in the open source world… but no-one > looks set to allow their implementation to be opened.
No kidding! In progress is a letter intended to protest the FCC's recent rulings over wifi radios, and suggest alternative legeslation. Please feel free to comment: https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing And more background on the savewifi effort here: https://libreplanet.org/wiki/Save_WiFi/Individual_Comments And make-wifi-fast: https://www.youtube.com/watch?v=-vWrFCZXOWk The problems in xDSL are similar to the ones in wifi, as are the potential solutions outlined above. I think a separate letter would be needed, however. I have another project, outside the context of make-wifi-fast, which is attempting to bring up a fully fq_codel'd[1] switch design in the Zynq FPGA. Boards built around the same FPGA would be capable of a truly open dsl design, and if they used the same berkeley design language ("chisel"), the total could be easily integrated into the resulting chip. I gave a brief talk about the fix-the-switches effort here, at battlemesh: https://www.youtube.com/watch?v=QWdL2Wu7M-8 ... anyway... Nowadays, we have a ton of dslreports results for bufferbloat, all over the world, sorted by AS number, etc - http://www.dslreports.com/speedtest/results/isp - as well as a truly spectacular bloat comparison by technology, covering a million user tests. http://www.dslreports.com/speedtest/results/bufferbloat?up=1 While dsl has many other problems... Fixing bufferbloat well on a dsl modem also requires deep access to the dsl firmware. There are a couple ways to go about this aside from the legal method in the first url, or designing our own chips - lantiq, for example was recently bought by intel, and their firmware is written for the ARC256 vliw. Requesting or purchasing their source code would make way for way better dsl on their chipsets. After a bit of personal experience on the complexities of dsp/vliw-ness of the arc256, I am pretty sure that nobody understands that codebase anymore, and the original author in an insane asylum... but as compiler support for that cpu has been arriving in gcc of late, so I would hope, that finally, we can write better DSL firmware with less effort than ever before. [1] well, the upcoming FPGA switch design is based on "cake", actually. http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical > d. -- Dave Täht endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
