Benchmark design for discovery protocols. #71
Conversation
|
This is to collect data related to Issue #69 (Performance data for discovery protocols). |
|
|
||
| ## SSDP specific | ||
|
|
||
| * Interval between `M-SEARCH` requests. |
There was a problem hiding this comment.
Maybe we need also to consider the SSDP header MX which contains the maximum time in seconds (must be between 1 and 5 seconds) to delay M-SEARCH response. Also the CACHE-CONTROL header could be relevant.
There was a problem hiding this comment.
Good point - MX will definitely affect latency, added it as a variable.
CACHE-CONTROL does also impact the latency of discovery and the quantity of network traffic over a long time frame, since the value is suggested to be greater than 1800 seconds. It could be interesting to vary it while making long term measurements over the course of hours (after discovery hits a steady state). Added a note about steady state behavior as future work to the end.
benchmarks/discovery.md
Outdated
|
|
||
| # Notes | ||
|
|
||
| Power consumption measurement only makes sense as a relative measurement, and |
There was a problem hiding this comment.
We can track battery level, number of discovery requests, number of found devices for both protocols mDNS and SSDP with the same number of senders and responders in the network. The experiment starts with fully charged smartphone and ends until the battery level reaches a pre-defined level e.g. 50%.
There was a problem hiding this comment.
That would be one approach, although I worry that the amount of battery consumed is so small relative to the other power sinks on a mobile device that it will get lost in the noise. There are a lot of mobile-specific implementation techniques that can affect power like coalescing background tasks and/or radio wakeups for passive discovery mechanisms like these.
Added a note to look at battery levels as a first approximation; but this really requires some more research and I will file a task to follow up.
benchmarks/discovery.md
Outdated
| 1. Fork and customize | ||
| [libupnp](http://pupnp.sourceforge.net/) for the [Open Screen SSDP discovery | ||
| protocol](../ssdp.md). | ||
| 2. Write our own SSDP implementation from scratch, possibly based on the |
There was a problem hiding this comment.
Feel free to use this simple Node.js implementation https://github.com/fraunhoferfokus/peer-ssdp/blob/master/lib/peer-ssdp.js in the Benchmark responder test app which works also on Raspberry Pi. It implements only the SSDP protocol and not the whole UPnP Stack. For Android we can use this https://github.com/fraunhoferfokus/cordova-plugin-hbbtv/tree/master/src/android/ssdp class and use it in the Benchmark sender app.
There was a problem hiding this comment.
Done, added the Node.js as an alternative implementation for the SSDP stack here. I also added a link to the Android plugin to the section at the end on mobile device benchmarking.
|
Thx @mfoltzgoogle I added some comments inline. |
|
Thanks @louaybassbouss. I've updated the PR in response to your feedback. Feel free to look again. |
|
LGTM |
No description provided.