meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

peerhood:peerhood_porting_to_maemo-ideas [2011/09/02 12:05] (current)
Line 1: Line 1:
 +====== Porting PeerHood into Maemo environment ======
  
 +PeerHood has been tested in Maemo environment. Works in emulator and in the device. Battery consumption hasn't been tested, memory consumption with WLAN and Bluetooth: ~44 MB which is the same as in Linux, see [[peerhood:​peerhood_performance_and_memory_usage#​nd_test_run_results|analysis of memory consumption in Linux with Bluetooth only]].
 +
 +This __is not required__ anymore because ''​MakeVars''​ file isn't used anymore in the current version of PeerHood. ​
 +><​del>"​Porting"​ required only changing the ''​DEPEND''​ variable content in ''​MakeVars''​ from:</​del><​code>​DEPEND=makedepend -I/​usr/​include/​c++/​4.2 -I/​usr/​include/​linux -I/​usr/​include/​c++/​4.2/​tr1</​code>​to <​code>​DEPEND=dpkg-deb -I/​usr/​include/​c++/​3.4 -I/​usr/​include/​linux -I/​usr/​include/​c++/​3.4/​tr1</​code>​ <​del>​because Maemo environment and N810 uses version 3.4 of C++ libraries. Also GPRS and GPRSgw -plugin directories were ignored in ''​Makefile''​.</​del>​- [[wiki:​user:​julaakko]]
 +
 +Currently PeerHood can be built in Maemo environment without any modification. GPRS and GPRSgw -plugins need to be removed from lib-folder, if they'​re built (another option is to comment out them from ''​Makefile''​).
 +
 +
 +===== Porting ideas =====
 +//These are just ideas which came into mind while thinking about the usage of PeerHood in N810 internet tablet and in [[comlabpub:​umsic:​start|UMSIC]] project - [[wiki:​user:​julaakko]] //
 +
 +==== General ideas about porting ====
 +
 +  * Currently the PeerHood daemon can be run as root only, <​del>​it might be more usable if regular user could run it for own purposes. Or</​del>​ the daemon should be set to start whenever system is loaded.
 +  * Modify current solution in a way that it would consume less power in a mobile device
 +    * <​del>​With current solution battery life would be drastically reduced when moving to an environment where multiple devices are present and many of them advert their own services.</​del>​ //Actually doesn'​t affect too much - should be tested soon ...//
 +       * Background application shouldn'​t degrade the battery lifetime drastically or reserve vast amount of resources
 +         * __Currently being tested with the device__ (WLAN and BT) //Aborted - isn't stable enough for long term testing, although in tests after 24h run the battery hasn't drained lot//
 +       * Continuous polling of WLAN wakes it up every time polling is executed -// necessary for PeerHood to keep track of surrounding devices//
 +         ​*<​del>​GPS could be applied? -> When coordinates change, update device list more frequently.</​del>​ //Slow, consumes a lot of battery -> reject//
 +    * <​del>​No active checking / polling of network interfaces / sockets ?</​del>​ //Loses proactivity//​
 +       * <​del>​User / application programmer could initiate searching of other devices and services</​del>​
 +         * <​del>​Starting of threads for advert / inquiry (e.g. search devices for 5 seconds)</​del>​
 +            * __Maybe threads could be set to sleep when no activity?__
 +         * Setting some service active (INSERT_SERVICE) on a device activates advertising of that service
 +            * **No need to advert anything if no services registered? Stop / pause thread?**
 +         * <​del>​Set background search of devices / services ? </​del>​ // Daemon works already on the background - [[wiki:​user:​julaakko]]//​
 +    * Use only a few threads
 +       * Instead of multiple active threads use a event callback -based approach
 +         * Reactor pattern
 +            * As a hybrid with thread-pool approach (multiple workers ready to work - dynamic depending on work queue?) - used a lot in web-servers and has been proven that this is the most effective one. // Need to find papers/​reference//​
 +         * <​del>​Half-sync/​Half-async - modified ?</​del>​
 +         * <​del>​Acceptor-Connector pattern (apply some parts?​)</​del>​
 +         * {{:​peerhood:​phd_event-driven_approach_idea.jpeg?​linkonly|an illustration of one idea}} - glib causes overhead?
 +         * [[peerhood:​peerhood_performance_and_memory_usage#​rd_test_with_debugger|Test with debugger]] shows that currently every thread takes roughly 8 MB of memory (not in use, reserved virtual memory).
 +    * Do not start plugins with daemon ? // Plugins need to be loaded but not started, on the other hand they could be started and set to sleep when there is no need for that particular plugin or part of that plugin - [[wiki:​user:​julaakko]] //
 +       * Listeners for this - monitor device/​system state!
 +
 +       ​*<​del>​ no threads for adverting / inquiring / listening ?</​del>​ // Threadless version would require probably too much change in the structure - not applicable// ​
 +         * <​del>​In some situations there could be a need to advert something (own service, acting as centralized server in adhoc network?​)</​del>​
 +       * Use PH daemon, but use it only to monitor events? ​
 +         * I/O callbacks with GLib-functionality?​
 +         * Asynchronous approach? If an operation lasts long -> slows the system (waiting times)
 +         * Solution (?) -> Start plugin threads only when something has happened (event) and a certain plugin has to deal with the occurred event and stop itself (idle or completely quit) when event has been dealt with. Thread could inform daemon via D-BUS or emitting a signal (if possible?) when the event has been dealt with. Or this could be seen from thread status (currently implemented,​ more usable -> no extra needed)
 +
 +==== PeerHood research subject ====
 +
 +  * One possibility is to implement only some parts of PeerHood into UMSIC-project if it cannot be modified to be resource-friendly in N810.
 +    * e.g. take parts of code that it still is compatible with other PeerHood enabled devices but the internal functionality could be transformed into a more light-weight form.
 +    * Need to investigate which solution would reduce the battery and resource usage of PeerHood daemon
 +      * Centralized version: all sockets monitored in single thread and pluginthreads are awaken only when there is need for them
 +         * Reactor and threadpool -hybrid. Efficient.
 +      * Centralized version 2: all sockets monitored in single thread and pluginthreads are created only when there is need and destroyed when there is no need.
 +         * Might reduce performance..
 +      * Current version: threaded - advert, inquiry and listen threads for every plugin and each of them listen sockets/​handles belonging to them
 +      * Reactor version, using GLib as reactor, which invokes certain threads or sends signals when something needs to be done.
 +
 +==== Optimize memory usage (solved)====
 +
 +       * Linux implementation (PHD alone) takes ~21 MB memory (~19 virtual) with bluetooth only. With WLAN plugins memory consumption goes over 40 MB
 +          * For comparison the MicroB -browser in N810 (Mozilla based) takes roughly 100 MB of memory when running ..
 +          * [[peerhood:​peerhood_performance_and_memory_usage|Analysis about performance and memory usage]] -> [[peerhood:​peerhood_performance_and_memory_usage#​solution|solution]]
 +       * <​del>​Plugin threads not always active - might reduce memory usage a lot</​del>​ //Virtual memory reserved when thread is started, see [[peerhood:​peerhood_performance_and_memory_usage#​rd_test_with_debugger|test]]//​
 +       * <​del>​use profiling to see which parts take vast amounts of memory - optimize variable usage</​del>​ //Tests done, see [[peerhood:​peerhood_performance_and_memory_usage|page containing test results]].//​
 +          * __started threads__ //This consumes memory a lot - reserves a large block, see [[peerhood:​peerhood_performance_and_memory_usage#​rd_test_with_debugger|test]]//​
 +          * <​del>​loaded plugins?</​del>​ //Consumes memory only a little, see: [[peerhood:​peerhood_performance_and_memory_usage#​exmap2|test]].//​
 +          * unnecessary statically loaded variables? Although in Maemo environment static variables should be preferred, <​del>​memory usage could possibly be reduced with dynamic memory allocation in continuous usage</​del>​ //Tests do not indicate that this is a problem..//
 +          * <​del>​unnecessarily large strings / char arrays?</​del>​ // Tests indicate that this isn't the issue //
 +          * <​del>​libraries?</​del>​ // Tests indicate that the libraries do not consume vast amounts of memory //
 +
 +==== Device Monitoring ====
 +  * Could it be possible to implement a method for monitor latencies of connections?​
 +    * Could be used in UMSIC project to monitor the quality of link(s) when acting as a "jam session"​ server in adhoc mode. Voice and instrument sound synchronization could be quite hard if the latencies between devices rise into too high levels -> if sound is out of sync it would be hard to play together (think of playing a guitar with a drummer who cannot keep up steady tempo)
 +  * Monitor only specific devices (friend devices)
 +    * Identification via MAC / bluetooth address ?
 +    * certificates (Maemo env. has certificate system for applications to use)
 +
 +==== PeerHood and D-BUS ====
 +
 +  * __PH daemon should listen to system D-BUS messages (battery low, shutdown, offline mode )__
 +    * **Implemented with listeners and listener "​framework"​ for initializing and using listeners for different purposes** -> Can be correctly shut down and stop all activity
 +    * Add support for using D-BUS (all applications in Maemo should register to D-BUS - otherwise application is killed - affects only user applications started from menu). Use D-BUS via LibOSSO or directly via libdbus (?).
 +    * <​del>​Use D-BUS for other activities? (vs. local socket)</​del>​
 +      * <​del>​service registration / removal? - Would require a implementation of a handler that deals with reply-messages</​del>​
 +      * <​del>​Activation of service?</​del>​
 +      * <​del>​Use PHD objects via D-BUS (define interfaces with xml and register to D-BUS) - bad?</​del>​
 +         * <​del>​using plugins "​directly"​ (?​)</​del>​
 +
 +> Not suitable, because D-BUS is not as reliable as local socket -> would require a implementation of sending/​receiving replies for messages. Would change current functionality too much.  - [[wiki:​user:​julaakko]]
 +
 +  * <​del>​Could the D-BUS be used for instance PeerHood daemon initiation / startup ?</​del>​
 +    * <​del>​Could the objects in daemon be used via D-BUS?</​del>​
 +       * <​del>​provide object interfaces to D-BUS with xml-definitions?</​del>​
 +    * <​del>​Invoking daemon when running PeerHood library notices an event (using callback in mainloop) via D-BUS?</​del>​
 +
 +> Not suitable, would require too much changes, bad idea.. ​ - [[wiki:​user:​julaakko]]
 +
 +==== Bluetooth ====
 +
 +  * <​del>​Modify Bluetooth plugin -> use [[http://​www.bluez.org/​|BlueZ]] library</​del>​
 +    * <​del>​Currently using lower level functionality (L2CAP - or is it?​)</​del>​ - //already uses BlueZ//
 +    * Always running? Bluetooth consumes power only a little
 +      * For example in UMSIC project external instruments could (should) be actively monitored when connected (instruments would connect via bluetooth)
 +    * Limitations of Bluetooth:
 +      * Maximum amount of active slaves in the same piconet: 7 (3bit address)
 +        * Bandwidth is shared by all active members in the same piconet
 +        * Passive (parked) slaves in the same piconet: 256
 +        * Scatternet? ​
 +      * Bluetooth has no broadcast-address -> cannot send data for all
 +      * Bluetooth has no multicast-address -> multiple unicasts -> delay and increase in latency
 +    * A __feature__ in Bluetooth:
 +      * In Linux using the BlueZ-library some adapters start to report errors after running for several hours. See [[peerhood:​peerhood_bluetooth_feature_and_testing|bluetooth feature testing]]
 +
 +==== Other Maemo related ====
 +
 +    * Localization of information / debug messages?
 +       * General localization / Maemo specific localization ?
 +    * Modify PeerHood daemon that it doesn'​t require root-access in Maemo env. (nokia N810)
 +       * Should be run as service -> root access (?)
 +    * <​del>​Alter variables into Glib-types</​del>​ - //A thing in future perhaps..//
 +       * enhances portability
 +       * a lot easier to bind to another languages
 +       * disadvantages compared to standard libraries?
 +       * Maemo environment uses Glib -> already loaded into memory ​  
 +
 +
 +===== Limitations of Maemo environment conserning PeerHood Linux-implementation =====
 +
 +  * A bit limited processing capabilities compared to modern PCs
 +    * TI [[http://​focus.ti.com/​general/​docs/​wtbu/​wtbuproductcontent.tsp?​contentId=4671&​navigationId=11990&​templateId=6123|OMAP 2420]], 400 Mhz
 +      * ARM1136 processor running at 330 MHz
 +         * In ARM11 processors the cost of context switches is greatly reduced compared to ARM9 processors (saving amounted to a 37-67% reduction in cycles)(([[http://​www.arm.com/​miscPDFs/​1751.pdf|MPF Premiere of ARM1136]]))
 +  * Limited amount of system memory
 +    * 128 MB DDR RAM
 +    * 256 MB Flash
 +  * Battery lifetime
 +    * 1500 mAh battery
 +    * Operating time up to 4 hours with continuous usage (screen on, WLAN active)
 +  * Memory should be allocated and freed in large blocks
 +    * Prefer static variables
 +  * "No busy looping in maemo"
 +
 +FIXME