Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rapid updates to properties
20-04-2012, 12:16 PM
Post: #1
Rapid updates to properties
The ohNet Device Stack documentation says that the device stack may skip some notifications for rapidly updating properties (typically less than a second) to avoid flooding the network with updates.

I've recently added a property whose value can get updated as frequently as every 4ms. I'm surprised to see that the device stack appears to be flooding each of these individual updates to my control point. Is this a bug or intentional behaviour?

For now I've implemented a throttling mechanism in my server so that it keeps the internal state of the property value and limits updating of the ohNet property to no more than once every 100ms. My choice of 100ms (vs 4ms for letting ohNet do this itself) is a pure guess, and I really have no idea how much I could reduce this interval without putting too much traffic on the network.

What is a reasonable figure/guideline for how frequently property updates should be broadcast without causing flooding of the network or overloading the ohNet device stack and control point stack?
Find all posts by this user
20-04-2012, 01:51 PM
Post: #2
RE: Rapid updates to properties
(20-04-2012 12:16 PM)simoncn Wrote:  The ohNet Device Stack documentation says that the device stack may skip some notifications for rapidly updating properties (typically less than a second) to avoid flooding the network with updates.
That sounds like a small bug in the documentation. While it is true that the device stack doesn't guarantee to publish every intermediate value for a property whose value changes rapidly, this isn't an attempt to avoid network flooding. (More discussion on why it works this way in response to your later comments...)

(20-04-2012 12:16 PM)simoncn Wrote:  I've recently added a property whose value can get updated as frequently as every 4ms. I'm surprised to see that the device stack appears to be flooding each of these individual updates to my control point. Is this a bug or intentional behaviour?
Its intended behaviour. The device stack will do its best to keep up with property updates. If updates happen faster than it can event out, it events out the current value of changed properties.

(20-04-2012 12:16 PM)simoncn Wrote:  For now I've implemented a throttling mechanism in my server so that it keeps the internal state of the property value and limits updating of the ohNet property to no more than once every 100ms. My choice of 100ms (vs 4ms for letting ohNet do this itself) is a pure guess, and I really have no idea how much I could reduce this interval without putting too much traffic on the network.

What is a reasonable figure/guideline for how frequently property updates should be broadcast without causing flooding of the network or overloading the ohNet device stack and control point stack?
No level of traffic will overload either the device or control point stacks. It would however be worth considering what behaviour would make your server a good network citizen. Sending a message every 4ms may be justifiable in some cases (Songcast sends a message every 5ms) but you're correct that this does risk using a measurable proportion of network bandwidth so it'd be worth asking yourself how important this property is to applications and how frequently they'd like to be updated on its changes. And then possibly apply some of your own throttling.
Find all posts by this user
20-04-2012, 02:23 PM
Post: #3
RE: Rapid updates to properties
Thanks very much for the quick answer, and for clarifying that this is intended behaviour.

The flooding issue is actually rather worse than I described, because the control point invokes an action on the server when it gets an update notification. This means that there are a total of 3 network messages for each update event. I think it's fairly clear that it wouldn't be reasonable to exchange 3 messages every 4ms, so I'll need to do my own throttling to prevent this.

I've reduced the application update interval from 100 ms to 50 ms, which seems to improve the smoothness of the application's performance. These messages are typically exchanged in short bursts of activity rather than a continuous workload, so I'm fairly comfortable that this won't put too much load on the network.

In case you're interested, I'm doing this to implement remote logging, which can involve quite high volumes of log messages when full tracing is enabled. When a new message is added to the server's log, the server sends a property update to the control point for the total length of the log data. The control point then invokes an action on the server to get the delta of new log information since the last time it did that, and appends this delta to a log window. Ideally the remote log window would scroll smoothly and track server activity in near real time.
Find all posts by this user


Forum Jump: