Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 20/04/2016 09:55, Georg Bauhaus wrote:
> On 19.04.16 15:35, Dmitry A. Kazakov wrote:
>> On 19/04/2016 14:59, G.B. wrote:
>>> On 19.04.16 14:43, Dmitry A. Kazakov wrote:
>>>> It is a value and a time stamp, because data are oversampled. There is
>>>> no way a conventional OS could respond to each change at this rate.
>>>
>>> Is it possible to have a volatile variable T representing
>>> some point in time and a CAS discipline so that
>>>
>>> 1. there is one task that updates T at regular intervals and
>>>
>>> 2. another task that reads T for stamping items more frequently
>>>     than the first would write updates?
>>
>> It is an interesting question. Do you mean CAS = content-addressable
>> storage?
>
> Coincidence! While I'd expect the time storing variable to be located
> in some kind of privileged location, I had meant CAS to refer to some
> thread-safe update mechanism. I now notice that maybe mutex via volatile
> storage might already be in place.

The method I am using is of a lock-free blackboard. There is single 
producer that writes onto it without locking. Consumers scan the 
blackboard without locking starting from the last read position = 
sequence number. They detect losses through the sequence number going 
out of the bounds.

>   All of this would be based on the assumption that reading the time via
> system is much more costly than just reading a volatile variable,
> while perhaps adding a sequence number for ordering the stamped items
> within one time frame. Also separates problems and solutions, as you
> indicated. Nothing new, I guess.

When a bunch of oversampled values are read, their time stamps are 
reconstructed, if the hardware is unable to stamp the values. Then the 
values and stamps are written into the blackboard. So the consumers 
never need not to care of the way the data came there in first place.

>   (For a case at hand, the measuring devices will be collecting only
> about 10-200 signals/second, yet mustn't have their batteries emptied.)

Another user case is when the mobile network traffic must paid for. The 
producer usually filters out updates which are within the tolerance band 
in order to reduce the traffic. Everything is running in the push mode, 
of course.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de