This project has moved and is read-only. For the latest updates, please go here.

Evaluating delays in the processing flow

Aug 26, 2014 at 7:24 PM

After implementing various Input and Action adapters, I would like to evaluate the delays at different steps of the processing flow (for example to evaluate the time between the reception of a measurement to its transmission to a 1st Action Adapter, then the time before this Adapter publishes a processed measurement based on the original one, etc.).

My first idea was to make Action Adapters compute these time differences, making use of the ReceivedTimestamp and PublishedTimestamp. But these properties don't quite work as I expected:
  • ReceivedTimestamp seems to be set at the creation of the Measurement object (cf the Measurement's Constructor), which is generally done at the end of the processing by the Adapters, not the beginning. I could adapt mine, but it still wouldn't work on the provided Adapters.
  • PublishedTImestamp seems deprecated - "trackPublishedTimeStamp = true" doesn't work. (cf this discussion)
Another difficulty I didn't see at first is the following: to evaluate the delay between the reception of a measurement and the generation of a "custom one" based on it, I need to know which custom measurement correspond to which original one (first, they won't probably be in the same frame).

Am I missing some mechanisms which could help me achieve my goal?
Thanks in advance.
Oct 1, 2014 at 6:42 PM
Hey Aldream,

The trackPublishedTimestamp setting is not deprecated, but rather is defined for another purpose. Any adapter that implements ActionAdapterBase can set this flag to true. If it does, all measurements that enter the adapter (input measurements) will have their PublishedTimestamp set after the adapter has finished processing that measurement. This has some implications.
  • The adapter itself will not be able to see that measurement's PublishedTimestamp.
  • Other adapters may or may not ever see that measurement's PublishedTimestamp since they all work on the same measurements in parallel.
  • Only one adapter should ever set a measurement's PublishedTimestamp or else they will be stepping on each other's toes.
As such, PublishedTimestamp may as well be deprecated because it has very little actual purpose. As for ReceivedTimestamp, it was originally designed to measure certain types of latency, but now finds itself suffering the same fate as PublishedTimestamp. That said, both the ReceivedTimestamp and PublishedTimestamp properties are mutable, meaning that although they no longer have any meaning to the system (this may actually be a good thing in your case), you can modify and use them at your leisure.

Hope this helps,