Opened 3 years ago
Last modified 3 years ago
#1637 new defect
inconsistant timeframe for graphs in console
Reported by: | ReturningNovice | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | undecided |
Component: | apps/console | Version: | 0.9.21 |
Keywords: | graph clock skew ^10 | Cc: | |
Parent Tickets: |
Description
When displaying the graph for clock.skew it seems the mouse-over text is off by a decimal place when it says how long the graph is for.
if I have about 4 days set (according to any other active graphs) then the clock skew graph indicates 43 days
~2 days gives 21 days
~22hrs gives 9 days
Subtickets (add)
Attachments (2)
Change History (5)
Changed 3 years ago by ReturningNovice
Changed 3 years ago by ReturningNovice
comment:1 Changed 3 years ago by ReturningNovice
comment:2 Changed 3 years ago by zzz
- Status changed from new to infoneeded_new
This behavior is by design, not a bug, but you could argue the design is wrong.
The setting at the bottom is for number of data periods, not total time. So a graph based on 60 second data will be for a shorter time period than for one based on 5 minute data.
This makes the graphs consistent with each other on the number of 'bars' displayed, but inconsistent as to total time period.
The underlying clock.skew data is a 10 minute sampling cycle, whereas the default graphs are all based on 1 minute data.
"returning" the ticket to you to ask whether it's ok as-is or would a constant-time display be better.
comment:3 Changed 3 years ago by ReturningNovice
- Status changed from infoneeded_new to new
To me, having all the graphs show the same block of time makes more sense. So the clock skew graph would be the exception to the rule; so that you could correlate performance drops and clock skew issues visually.
not sure what version this crept in, I just started looking at the graph of clock skew recently...