search

KyleBenson / scale_client

The Python-based SCALE Client software for acquiring data from various sensors (i.e. via Raspberry Pi platform), processing it, and sharing it through multiple networks and data exchange protocols.
http://scale.ics.uci.edu/
Other
4 stars 8 forks source link

Sigfox Sleep Cause EventReporter Blocked #5

Closed substance9 closed 10 years ago

substance9 commented 10 years ago

Phenomenon: We observed that, the messages that were sent by SheevaPlug had a fixed interval. Also, there was serious delay between real events happened and corresponding messages were sent.

Reason: SigFox sleep function cause EventReporter blocked per second(depends on sleep length). Sigfox sleep function was used after send() and before receive() that were called by EventReporter to wait for Sigfox adapter return message. However, this will block the whole EventReporter, and MQTT sending is also influenced.

Temporary Solution: Simply delete sleep function before calling receive on the Sigfox publisher, but this may cause the missing of Sigfox return value.

Possible Solution: We can implement all the publishers as independent threads. Charles gave the idea that, instead of blocking and waiting for response, the response could be obtained by EventReport by Callback functions.

KyleBenson commented 10 years ago

I think that the ideal solution for this problem is to use the Twisted framework to make ALL I/O function asynchronous callbacks. This would even alleviate the issue of multi-threading, which provides no performance gains on the single-core machines we're currently focused on. I'm not sure how this would work on the Raspberry Pi though: can you have a single thread requesting sensor data from multiple ports at once? Or does it block on the first request, meaning we would still have to use the multi-threaded solution?

A bigger issue is that we need some sort of QoS real-time guarantees....

On Fri, May 9, 2014 at 1:03 PM, Guoxi Wang notifications@github.com wrote:

Phenomenon: We observed that, the messages that were sent by SheevaPlug had a fixed interval. Also, there was serious delay between real events happened and corresponding messages were sent.

Reason: SigFox sleep function cause EventReporter blocked per second(depends on sleep length). Sigfox sleep function was used after send() and before receive() that were called by EventReporter to wait for Sigfox adapter return message. However, this will block the whole EventReporter, and MQTT sending is also influenced.

Temporary Solution: Simply delete sleep function before calling receive on the Sigfox publisher, but this may cause the missing of Sigfox return value.

Possible Solution: We can implement all the publishers as independent threads. Charles gave the idea that, instead of blocking and waiting for response, the response could be obtained by EventReport by Callback functions.

— Reply to this email directly or view it on GitHubhttps://github.com/KyleBenson/SmartAmericaSensors/issues/5 .

KyleBenson commented 10 years ago

Guoxi, have you successfully resolved this issue with the threading approach?

substance9 commented 10 years ago

The problem is temporarily solved by make all the publishers be independent threads.

Now, when EventReporter has a event that is ready to send, it will iterate the publisher list. For each publisher, EventReporter will first call a check_available function to see if this publisher is able to send this event. If check_available returns true, the EventReporter will call the send function of this reporter to send the event out.

The send function is asynchronous. It just push the event to publisher's queue. The publisher thread loops to send the events. If there is a failure, it will report this failure to EventReporter by call a callback function

Kyle, you are right, this method provides no performance gains on our platform. We will have a try on Twisted framework later