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 <dave.t...@gmail.com> wrote: > On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek > <j...@pps.univ-paris-diderot.fr> 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 > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- james woodyatt <j...@nestlabs.com> Nest Labs, Communications Engineering
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
