We have a parameter which is updated every 10s with values at a 1s granularity. Our client would like to have this trending graph displayed on their screens constantly populating with the new data as it is ingested into the system.
At the moment, the timeline progresses in real-time, but new values are not updated onto the graph until 2mins have passed (note the lighter blue prediction becomes the darker blue line after those two minutes have passed):
This is currently using DM 10.1.11. Is there a configuration to define how frequently the trending engine can update?
Note the light blue line is not a “prediction” but represents the actual value changes that happened since the graph was opened. From the moment the graph is opened, we listen to changes to the parameter and append them in real-time to the graph. It’s in light blue because the data you see is not the actual trend data from the database.
As you say, when 2 minutes have passed, an update request will be made and the actual trend data will be appended.
Note that for Cassandra databases, we used to have a much faster update frequency, but if I recall correctly we got rid of that when we introduced the real-time updating through parameter changes (as mentioned above), mostly because we didn’t feel like querying the database every 10 seconds was as efficient as just processing the changes to the parameter in real-time.
Maybe we should bring this back? Is there a particular reason you’d prefer faster updates (and thus higher load for the server and database) over the current mechanism? I’d love to hear from you.
Indeed. I believe the key point I missed in the question was the first sentence: “We have a parameter which is updated every 10s with values at a 1s granularity.”
Seems to me like this means we’re dealing with a tiny history set. So parameter changes only come in every 10 seconds, but the history values actually consist of 10 different values.
Indeed, this could be a good reason to make the update frequency configurable as well.
Hi Toon and Pieter,
Thanks for your comments/answers. Your assessments are correct – we are looking at a 10s history set containing 10 values. This can potentially therefore mean that we will not display the actual value until the call is made after 2mins.
Would this be something Skyline would be interested in re-introducing? I completely understand that for some customers this may not be necessary and should be off by default, but as you can see in this case, it would be very useful.
Hey Jack, thanks for giving us your insights. To get this on our radar, I suggest either contacting your TAM for a feature request or going through dojo and making a feature suggestion (in the header bar, go to More => Feature Suggestions).
If you do go through your TAM, please do sync with that person to see how you would prioritize this compared to other items in your project.
Hi,
Cube will now support configuring the trend graph update interval via a user setting. This user setting would be set to two minutes by default but adjustable to anywhere between five seconds and five minutes. This new feature is currently under review and is targeting upcoming feature release 10.2.4.
Kind regards
Toon,
I guess, after those 2min, the light blue line should be replaced by the dark blue one and we expect exactly the same line, right? Because, from the screenshot in the question, it looks like the light blue line shows something different than the dark blue one (having a constant pace vs stable + larger jumps)