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 <[email protected]> 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 <[email protected]> wrote: >> >> On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek >> <[email protected]> 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/homenet >> >> >> >> -- >> Dave Täht >> >> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > james woodyatt <[email protected]> > Nest Labs, Communications Engineering -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
