[Bloat] building a better toaster

[Bloat] building a better toaster

[Dave Taht]

There are some lessons here for getting anti-bufferbloat fixes into
std hardware.

http://esr.ibiblio.org/?p=8063

One thought, though, if you look at the (oft hysterical) comment
thread - if you make your point loud enough, toaster experts will come
out of the woodwork to help.

"[dualit]s don’t use springs–you lift the toast by hand–and they use a
mechanical timer. It’s like someone made a list of all the toaster
parts that break, then designed a toaster that contains none of them."

If only we could apply more of these design principles to the internet.


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Bloat] building a better toaster

[Jonathan Morton]

> On 30 Jun, 2018, at 6:28 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> There are some lessons here for getting anti-bufferbloat fixes into
> std hardware.
> 
> http://esr.ibiblio.org/?p=8063

Certainly most of the CPE out there is standard hardware bolted together in the same general fashion and stuck in a plastic case, with a crummy "hack on the BSP until we get the feature boxes ticked" firmware and no thought whatsoever for future-proofing or elegance, whose only configuration interface is through a Web browser and exposes a correspondingly large attack surface, while in the process *mandating* a NAT layer.

Case in point, my new 4G router.  Today, at the ripe old age of 2 weeks, it started crashing repeatedly when subjected to what I now consider to be quite a light traffic load (Steam and Elite Dangerous were updating at the same time).  Power-cycling that thing a dozen times an hour got old *really* quickly.  It mostly stabilised once they were finished.  Oh, and it advertises IPv6 support, but no sign of an actual IPv6 address on the wire.

I'm pretty sure it has double-NAT built in, too, in addition to whatever the ISP does behind the scenes.  The built-in 4G module apparently runs Android all by itself - so this thing is basically permanently tethered to a cheap smartphone with no screen or keypad, and at least 3 CPUs are involved on the way (one in the router, one in the "phone", and one in the modem within the "phone").  What the actual *fuck* happened to building a simple goddamned modem that just passes packets through?

It did so even after I finally managed to get the vendor's firmware update to take, which required first unplugging all the cables until only one computer, dedicated to uploading the firmware image, was connected.  Anything less would, at best, cause it to go through all the motions of a firmware upgrade including a reboot after the appropriate delay, but the version number remained the same upon subsequent examination.

Presumably OpenWRT would work somewhat better, but currently support is for the v1 hardware; I have v2.1 hardware, and according to the vendor's website there is already v3 in the retail channel.  Possibly they are all similar enough to consider identical from OpenWRT's point of view, but we've seen vendors change *CPU architecture* without changing the model number before.  Until I figure out how to pry the case open without smashing it to smithereens, I literally can't tell.

So yeah, exactly like your average toaster - commoditised to within a micron of its life.

> One thought, though, if you look at the (oft hysterical) comment
> thread - if you make your point loud enough, toaster experts will come
> out of the woodwork to help.
> 
> "[dualit]s don’t use springs–you lift the toast by hand–and they use a
> mechanical timer. It’s like someone made a list of all the toaster
> parts that break, then designed a toaster that contains none of them."
> 
> If only we could apply more of these design principles to the internet.

It just so happens that I'm trying once again to figure out the best toolchain to use with the ONetSwitch30's FPGA.  So far it looks like MyHDL (based on Python) is a tolerable alternative to coding directly in VHDL or Verilog, and can output the latter to be consumed by Xilinx' official toolchains somehow.

I still dream of putting something very like Cake into hardware *and* not having to configure a router with a Web browser.  But I should probably start with something simpler, like a CPU...

 - Jonathan Morton

Re: [Bloat] building a better toaster

[David Collier-Brown]

If you put your cost accountants in one silo and your engineers in 
another, you get to be an ex-company (;-))

--dave

On 30/06/18 01:36 PM, Jonathan Morton wrote:
>> On 30 Jun, 2018, at 6:28 pm, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> There are some lessons here for getting anti-bufferbloat fixes into
>> std hardware.
>>
>> http://esr.ibiblio.org/?p=8063
> Certainly most of the CPE out there is standard hardware bolted together in the same general fashion and stuck in a plastic case, with a crummy "hack on the BSP until we get the feature boxes ticked" firmware and no thought whatsoever for future-proofing or elegance, whose only configuration interface is through a Web browser and exposes a correspondingly large attack surface, while in the process *mandating* a NAT layer.
>
> Case in point, my new 4G router.  Today, at the ripe old age of 2 weeks, it started crashing repeatedly when subjected to what I now consider to be quite a light traffic load (Steam and Elite Dangerous were updating at the same time).  Power-cycling that thing a dozen times an hour got old *really* quickly.  It mostly stabilised once they were finished.  Oh, and it advertises IPv6 support, but no sign of an actual IPv6 address on the wire.
>
> I'm pretty sure it has double-NAT built in, too, in addition to whatever the ISP does behind the scenes.  The built-in 4G module apparently runs Android all by itself - so this thing is basically permanently tethered to a cheap smartphone with no screen or keypad, and at least 3 CPUs are involved on the way (one in the router, one in the "phone", and one in the modem within the "phone").  What the actual *fuck* happened to building a simple goddamned modem that just passes packets through?
>
> It did so even after I finally managed to get the vendor's firmware update to take, which required first unplugging all the cables until only one computer, dedicated to uploading the firmware image, was connected.  Anything less would, at best, cause it to go through all the motions of a firmware upgrade including a reboot after the appropriate delay, but the version number remained the same upon subsequent examination.
>
> Presumably OpenWRT would work somewhat better, but currently support is for the v1 hardware; I have v2.1 hardware, and according to the vendor's website there is already v3 in the retail channel.  Possibly they are all similar enough to consider identical from OpenWRT's point of view, but we've seen vendors change *CPU architecture* without changing the model number before.  Until I figure out how to pry the case open without smashing it to smithereens, I literally can't tell.
>
> So yeah, exactly like your average toaster - commoditised to within a micron of its life.
>
>> One thought, though, if you look at the (oft hysterical) comment
>> thread - if you make your point loud enough, toaster experts will come
>> out of the woodwork to help.
>>
>> "[dualit]s don’t use springs–you lift the toast by hand–and they use a
>> mechanical timer. It’s like someone made a list of all the toaster
>> parts that break, then designed a toaster that contains none of them."
>>
>> If only we could apply more of these design principles to the internet.
> It just so happens that I'm trying once again to figure out the best toolchain to use with the ONetSwitch30's FPGA.  So far it looks like MyHDL (based on Python) is a tolerable alternative to coding directly in VHDL or Verilog, and can output the latter to be consumed by Xilinx' official toolchains somehow.
>
> I still dream of putting something very like Cake into hardware *and* not having to configure a router with a Web browser.  But I should probably start with something simpler, like a CPU...
>
>   - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain

Re: [Bloat] building a better toaster

[Jonathan Morton]

> On 2 Jul, 2018, at 2:34 am, David Collier-Brown <davec-b@rogers.com> wrote:
> 
> If you put your cost accountants in one silo and your engineers in another, you get to be an ex-company (;-))

Maybe so, but if you let the former have absolute authority over the latter, you'll end up with the same shoddy far-eastern-made crap as everyone else, because buying the standard mass-produced components and plugging them together is all the budget will allow for.  Likewise, if you let Marketing dictate the schedule, you *will* end up releasing something unfinished and buggy as hell, because it took 80% of the time to reach feature-complete and the remaining 20% is distribution lead-time, not available for debugging or even basic usability testing.

The fact that both of the above happen far too often is a source of intense frustration.  The fact that many retailers won't even bother stocking a higher-quality product that happens to exist is downright *insulting*.

I could give you all sorts of railway analogies to go with this.  The British railway industry alone is a rich vein of examples of abject stupidity contrasted with brilliance.

There is a middle ground.  Have cost be one of the factors for the engineers to optimise for, but don't make it the overriding factor.  Tell them the commercial benefits of shipping in time for the holiday season, or back-to-school, or whatever - but let *them* decide if it's worth rushing the product out to meet that schedule.  Consequently, you'll get a better product that might just surprise the market.

 - Jonathan Morton

Re: [Bloat] building a better toaster

[David Collier-Brown]

On 01/07/18 08:17 PM, Jonathan Morton wrote:
>> On 2 Jul, 2018, at 2:34 am, David Collier-Brown <davec-b@rogers.com> wrote:
>>
>> If you put your cost accountants in one silo and your engineers in another, you get to be an ex-company (;-))
> Maybe so, but if you let the former have absolute authority over the latter, you'll end up with the same shoddy far-eastern-made crap as everyone else, because buying the standard mass-produced components and plugging them together is all the budget will allow for.  Likewise, if you let Marketing dictate the schedule, you *will* end up releasing something unfinished and buggy as hell, because it took 80% of the time to reach feature-complete and the remaining 20% is distribution lead-time, not available for debugging or even basic usability testing.
>
> The fact that both of the above happen far too often is a source of intense frustration.  The fact that many retailers won't even bother stocking a higher-quality product that happens to exist is downright *insulting*.
>
> I could give you all sorts of railway analogies to go with this.  The British railway industry alone is a rich vein of examples of abject stupidity contrasted with brilliance.
>
> There is a middle ground.  Have cost be one of the factors for the engineers to optimise for, but don't make it the overriding factor.  Tell them the commercial benefits of shipping in time for the holiday season, or back-to-school, or whatever - but let *them* decide if it's worth rushing the product out to meet that schedule.  Consequently, you'll get a better product that might just surprise the market.
>
>   - Jonathan Morton
>
>

A good cost accountant is a wonderful thing, but they need to work 
closely with engineers in engineering companies  to get the right 
product, one factor in which is cost.

--dave


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain