You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When pressing the stop-button on the screen shown in the attached image, it can sometimes take minutes for data processing to actually stop. My guess is that the code only checks for a stop-condition after having processed the currently available kafka messages. This should be changed so that the stop condition is checked in every iteration of the processing loop.
The text was updated successfully, but these errors were encountered:
Your assumptions are not quite correct. It tries to stop as soon as it can.
If there is lag, it's likely because it has trouble keeping up with either parsing or histogramming. You can mitigate this in two ways, both of which are in the config tree on the DAQ tab.
In ESSStream you can tell it to FF to most recent kafka messages, which will mitigate any lag in parsing
You can tell it to drop spills (top level), which will allow it to skip histogramming some data.
This, of course, will mean that you won't get a totally honest representation of the data, but I am guessing you will analyze it later from the written h5 files. For instantaneous live monitoring it should be fine.
When pressing the stop-button on the screen shown in the attached image, it can sometimes take minutes for data processing to actually stop. My guess is that the code only checks for a stop-condition after having processed the currently available kafka messages. This should be changed so that the stop condition is checked in every iteration of the processing loop.
![screenshot](https://user-images.githubusercontent.com/58835/49696781-82f8eb80-fbaf-11e8-93b0-8e679d2a8dae.jpeg)
The text was updated successfully, but these errors were encountered: