Re: [homenet] Next Steps for Routing Protocol

[Dave Taht <[e-mail]>]

so by my lights the thermostat has a simply astonishing amount
of flash (38MB), and an A8 class processor...

https://learn.sparkfun.com/tutorials/nest-thermostat-teardown-

Peeking at the board from the pics I cant see how much memory
it has, and the OS seems to be quite small (1.5MB) but I have trouble
thinking that a better-then-rasberry pi class processor could be hooked to
less than 16MB ram effectively and certainly not work well as an AP,
as you do need quite a lot of ram to forward aggregates....

Back in 1998 I had given up on scaling up vxworks to do ipv4, and
worked on scaling linux down to fit into 16MB of ram and a floppy disk
to boot from
in order to make an AP (
http://the-edge.blogspot.com/2010/10/who-invented-embedded-linux-based.html
)

(and thus, an industry was born)

And these days we regularly run APs with 4MB of flash doing ipv4, and
8-16MB of flash
doing ipv6, routing, etc, etc in openwrt, usually with about 32MB of
ram as a base - on
much weaker processors than an A8.

So it is unclear how good the thermostat is as an AP, but if it has a
smaller OS (BSD?), possibly
16MB of ram is enough these days to run as a basic AP + 802.14
gateway, and we have already
shown babel and hnetd as being very, very lightweight.


On Mon, Nov 17, 2014 at 12:23 PM, James Woodyatt <[e-mail]> wrote:
> Dave,
>
> At Nest, we have different OS platforms we use depending on the constraints
> of the hardware.
>
> For things like the Nest Learning Thermostat, where there is a graphics
> subsystem and such, we use a $POSIX variant commonly found in larger
> embedded systems.  It has not much flash and even less memory.  We cut a lot
> of things out to make everything we need to fit, and we feel significant
> volatile and non-volatile memory pressure on this platform.
>
> For things like the Nest Protect, which are much smaller, we use a
> library-oriented $RTOS variant.  The current Nest Protect device, for
> example, executes code from 512 kB of flash, using 64 kB of RAM.  It has a
> very lightweight IPv6 stack, over which we have implemented all our
> communications protocols and our application logic.  We are under truly
> extraordinary memory pressures on this platform, of the sort that I believe
> only somebody with experience working in the C64 demoware scene can fully
> appreciate. (Seriously, you can't even. Don't try.)
>
> I'm hoping future evolutions both in these product lines might have
> incrementally more resources, in which it may be possible to demand space
> for Comms Engineering to insert HNCP, when it's finally deployable. Assuming
> HNCP can be made to work. Lot of ifs. However, whatever happens, we
> eventually will need something that does what HNCP does, and I like HNCP
> itself better than I like the idea of rolling something proprietary.
>
> Does that help explain matters?
>
> On Sat, Nov 15, 2014 at 8:46 AM, Dave Taht <[e-mail]> wrote:
>>
>> On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek
>> <[e-mail]> wrote:
>> >> This included technical discussion around a partially unanticipated
>>
>> I have always felt that we needed to have something that could route
>> packets as best as possible based on conditions (and in particular
>> transport configuration information) across many disparate link layers
>> - homeplug, MoCa, 802.11, 802.11ad, 802.14, 6lowpan, VPNs, and sharks
>> with lasers.
>> (https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1
>> ).
>>
>> While full compliance with rfc2549 is not required, wires as we knew
>> them are going the way of the dodo, and already have, in most homes
>> and small businesses.
>>
>> >> requirement for HNCP to support a stub network with a gateway that
>> >> doesn't have sufficient resources to run a routing protocol.
>>
>> Could someone describe what sort of resources these gateways (nest, I
>> assume) actually have? - What OS they run, how much ram and flash is
>> on them, is there virtual memory, etc?
>>
>> Are there devices in this category that can be hacked on? I am
>> reminded of the dnssec debate put to rest by merely producing a proof
>> of concept on an ancient cpe... I mean, babel, for example, is like,
>> 61k, on mips with the sole dependency on libc. Other daemons, like
>> pimd are in the same size category.
>>
>> >
>> > Mark,
>> >
>> > Could you please spell out the requirements for a stub-only
>> > implementation?  Do you expect the stub router to hold the full routing
>> > table, or just two routes (connected network and default route)?
>> >
>> > Is there interest in a stub-only implementation of Babel?  Should it be
>> > a standalone daemon, or should it be integrated in the HNCP daemon?
>> >
>> > -- Juliusz
>> >
>> > _______________________________________________
>> > homenet mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/homenet
>>
>>
>>
>> --
>> Dave Täht
>>
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>>
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
>
> --
> james woodyatt <[e-mail]>
> Nest Labs, Communications Engineering



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks