Date: Fri, 22 Jan 2016 11:40:36 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-hackers@freebsd.org Subject: Re: IoT OS Message-ID: <56A20724.8050704@rlwinm.de> In-Reply-To: <CAP8Xrcv1f8j-eQuYW%2B%2By4zAn0=cxC_PR1J6hkdwS%2BA=vL47ASw@mail.gmail.com> References: <CAP8XrcszH-KroGv3nJo5AyH=Mh%2BAe6YhAKNi4SuEEs9ss9M8Rg@mail.gmail.com> <56A10892.2090308@rlwinm.de> <F37089F2-6467-4366-8AE9-C8BD0BF6E6F7@gmail.com> <CAP8Xrcv1f8j-eQuYW%2B%2By4zAn0=cxC_PR1J6hkdwS%2BA=vL47ASw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/01/16 19:08, Mathieu Prevot wrote: > 2016-01-21 17:38 GMT+01:00 NGie Cooper <yaneurabeya@gmail.com>: > >> >>> On Jan 21, 2016, at 08:34, Jan Bramkamp <crest@rlwinm.de> wrote: >>> >>>> On 21/01/16 17:19, Mathieu Prevot wrote: >>>> Dear all, >>>> >>>> I would like to connect several connected object (with homogeneous or >>>> heterogenous hardare: intel edison, samsung artik, apple AX, intel >> core, >>>> etc) so the calculation needs, the storage/memory, the connection, etc >> are >>>> decoupled; hence we can reach an ecosystem with several clouds. >>>> >>>> How do you recommend to reach that ? from the kernel, a module, or >>>> eventually a software ? >>> >>> Your message contains neither enough information nor a precise enough >> question for anyone to provide you a helpful answer. >>> >>> Please describe your problem in sufficient detail and reformulate your >> question. If you still think these mailing lists (current@ and hackers@) >> are a good audience for your question afterward ask them again. >> >> It depends on your workload and hardware requirements (there isn't a >> simple answer to your question because you didn't describe what you needed >> with concrete requirements). >> >> I would talk to cem@. He's working on ioat(4) on head for us ($work). >> Thanks, >> -NGie >> > > Say all objects are connected peer to peer with wifi, some of them are > connected to internet through gsm network or wifi to a box. These object > are moving in space, and for some reasons, connections are dynamical and > can be severely impaired or lost. > > They have incoming local streams of data (eg HD videos, accelerometer, GPS, > other wifi and gsm signals, etc). There are several orders of magnitude between the bandwidth requirements for HD video and sensors samples from accelerometers and GPS receivers (both types of sensor data can be compressed even further with simple delta compression). Anything that can store a few hours of HD video can store a several years worth of your sensor data as well. > I would like to abstract the CPU layer, storage layer, and internet > connection so that in realtime results of one of my objects are saved if > this object dies, so that if one of the object giving internet access to > the group loose its connection, the redundancy allows the group of object > not to lose internet connection. You can't have reliable realtime access to your (new) sensor data without a reliable link with guaranteed bandwidth. You can only have best effort replication to multiple nodes. > Can I consider these as different load balancing layers ? Do you recommend > to implement this at the kernel layer or at an API layer ? Can I see that > as a lightweight cluster ? There is now way I can imagine to implement a sane single image cluster system on a bunch of hardware that happens to have network connectivity and sensors from time to time. The hardware requirements to just encode HD video is again multiple orders of magnitude above what your other sensors require. At this point a difference in quantity turn into a difference in quality. Your cluster won't gain throughput from the puny nodes because the potential gains are outweighed by the overhead. > I think the API is more flexible, especially if I have an heterogeneous (by > CPU, OS) set of connected object. However, working at the kernel level > allows existing programs not to be rewritten. What are your thoughts ? A simple wireless sensor node can't power a CPU and memory subsystem capable of running FreeBSD (or any other modern *nix kernel). Those kernels require something between 32MiB and 64MiB of RAM and wake up the CPU far to often. Such a system would drain its battery in hours if not minutes. This rules out a common kernel unless you want to use a lightweight RTOS on your large nodes as well. My recommendation from what I understood from your messages so far is to structure your sensor network as at least two types of nodes: - Simple sensor nodes operating as message sources (and maybe forwarders in a mesh network) - Larger nodes with enough resources (CPU, RAM, storage, power) to run a common *nix OS working as message sinks (and optionally forwarders or sources).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56A20724.8050704>