9:42 a.m.
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>
Sent: Friday, November 8, 2013 2:55:51 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
> From: "Malini Rao" <mrao(a)redhat.com>
> To: "Lior Vernia" <lvernia(a)redhat.com>
> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>
> Sent: Thursday, November 7, 2013 4:40:35 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> While the technical discussion carries on, I want to go back to the user
> requirement here one more time - What is of most value to the user - the
> current value accurate to the second level in time ( in which case why do
> we
> want line chart/ sparklines etc) or a trend of how this entity is doing in
> the last x hours including a 'sense' of where it is at this time? If a
> second to second difference is important to be obvious, then sparklines or
> any other small charting method is possibly not the best way to go. We may
> need to design an entire monitoring view with more detailed graphs for
> various measures etc. My impression with this requirement was that it is
> valuable for the user to get a sense of the trend for the measure on the
> entity just by looking at the shape of the line and the end point gives you
> an 'idea' of where the entity is at so that you can decide if any
> investigation is needed or base your decisions on it. I have a hard time
> wrapping my head around the possibility that decisions will be influenced
> by
> data delays of a few secs. In my mind, this is not like a stock ticker...
> is
> it?
The requirement here (AFAIU) is to have an idea on how the entity is doing -
the trend and the actual value
so you can take appropriate actions if something is suspicious.
The problem with the 15 sec sampling is not the delay but the completely
lost information. It would not be a problem if the resource usage would be
rather stable (e.g. the whole 15
sec interval the CPU usage is 40%) than we can take the sample once in 15
sec, present it to the user and
he/she will know if this is OK or not. But this is unfortunately not true (or
does not have to be) and the
resource usage pretty much jumps up and down. If you take a sample each 15
sec you present one random value
to the user and he/she can not know what the actual usage is.
Imagine this example:
sec 1: 100%
sec 2: 100%
...
sec 10: 100%
sec 11: 0%
sec 12: 0%
sec 13: 0%
sec 14: 0%
sec 15: 0% <- sample
sec 16: 100%
...
And this pattern repeats.
I thought the system would not just report the sec 15 value but update the sparkline with
sec 1- 15 at sec 16 and sec 16- 30 at sec 31. So no info is lost. No? Is it possible that
a change in pattern is not detected until 15 secs later.. yes. But the question is if that
delay is critical and if the action/ decision to address it happens in the 15 secs before
the next refresh.
You will present a user that the CPU usage is stable 0% completely useless
(and also incorrect, but mostly useless ;) ).
What you want to present instead is stable 66% (which is also incorrect but
much more useful).
>
>
> ----- Original Message -----
> From: "Lior Vernia" <lvernia(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>
> Sent: Thursday, November 7, 2013 2:35:55 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> On 07/11/13 09:26, Tomas Jelinek wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Lior Vernia" <lvernia(a)redhat.com>
> >> To: "Einav Cohen" <ecohen(a)redhat.com>
> >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> >> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>
> >> Sent: Thursday, November 7, 2013 8:03:25 AM
> >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>
> >> Sorry, obviously I meant RAM usage...
> >>
> >> On 07/11/13 08:51, Lior Vernia wrote:
> >>>
> >>>
> >>> On 06/11/13 16:26, Einav Cohen wrote:
> >>>> Hi Tomas,
> >>>>
> >>>> Like Itamar, I think that a line chart is a better idea, and that
a
> >>>> chart per monitored fact (rather than a combined chart) is better.
> >>>>
> >>>>>> the statistics readable enough. Maybe if you hover the
chart it
> >>>>>> could
> >>>>>> pop
> >>>>>> up a bigger version of the chart? Or not needed?
> >>>>
> >>>> this is a nice-to-have, I think, definitely not needed.
> >>>>
> >>>>>> - Would it be enough to have it in one color? Or should it
be
> >>>>>> something
> >>>>>> like "the bigger the utilization the more red"?
> >>>>
> >>>> question is what will happen when there are a lot of
"jumps": let's
> >>>> say
> >>>> that the graph changes from 0% to 100% to 0% to 100% and so on...
what
> >>>> will be painted red? the entire line, but only in the periods that
it
> >>>> jumps to 100%? only the parts of line that are in 100%?
> >>>> maybe a single color is enough.
> >>>>
> >>>> I have another concern about this feature: currently, the GUI's
most
> >>>> frequent
> >>>> refresh rate available is 5 seconds, which means that the line
will
> >>>> "change"
> >>>> only every 5 seconds, which would be more noticeably slow when
> >>>> displayed
> >>>> in
> >>>> a form of a line chart (not even talking about lower frequencies).
> >>>> Moreover, I am not sure at what rate the VM statistics are pulled
from
> >>>> VDSM,
> >>>> but if it is 10 seconds or 15 seconds, it means that the line in
the
> >>>> GUI
> >>>> will
> >>>> be "flat" for every 2 reads / 3 reads, which is not so
good, I think.
> >>>>
> >>>> any thoughts around that?
> >>>>
> >>>
> >>> If this is indeed an issue, it could be easily solved by delaying the
> >>> presentation of the value obtained from VDSM, and at each moment
> >>> present
> >>> a linear interpolation of the value between the previous input and the
> >>> current input.
> >>>
> >>> Formally put, let's say T is the measurement period time. If the
value
> >>> at time t is f(t), then at time t-T <= t' <= T we would
display the
> >>> value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the
increment
> >>> rate of t'.
> >>>
> >>> For example, let's say we get a new value from VDSM every 15
seconds.
> >>> 30
> >>> seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now
200MB.
> >>> We decided to update the graph every 3 seconds.
> >>>
> >>> 15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
> >>> seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago 80MB,
> >>> 3
> >>> seconds ago 90MB, and now we display 100MB (which is again late by 15
> >>> seconds). We will only display 200MB in 15 seconds, after increasing
> >>> our
> >>> displayed value by 20MB every 3 seconds.
> >
> > Hey Lior,
> >
> > good idea and certainly better than just draw the current value at each
> > refresh.
> > We should certainly do this.
>
> Just pointing out that it's not necessarily better, as we never actually
> draw the current value, we're always late by T (otherwise we'd have
> continuity issues as we don't know what future value is coming in the
> next measurement). The added benefit is only the feel of constant
> updates, at a time period that is independent of the VDSM update period.
>
> It might be better to just add a dot whenever we get a new measurement,
> and have the dots close enough together for it to look like a nice
> graph, and not have it updated constantly.
>
> >
> > But this is only one side of the problem - how to visualize it. The
> > question is
> > how useful the data are if we sample them once in 15 secs. Imagine that
> > you
> > have
> > peeks every ~10 secs which uses 100% of your cpu for ~2 secs. With the
> > sampling
> > each 15 secs you will see any peek only by luck and certainly not all of
> > them.
>
> Yep, agreed.
>
> >
> > But I'm sure we are not the first facing this problem - adding [now the
> > correct ;) ]
> > Martin as CC:
> >
> > @Martin: does the VdsUpdateRunTimeInfo receive the CPU/memory samples at
> > each 15 secs
> > or it receives some sort of average since the last update?
> >
> >>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim(a)redhat.com>
> >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> >>>>> <engine-devel(a)ovirt.org>
> >>>>> Sent: Tuesday, November 5, 2013 10:10:34 AM
> >>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> >>>>>
> >>>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> There is a feature request [1] which aims to replace the
resource
> >>>>>> utilization graphs (for example the cpu utilization from vm
tab) by
> >>>>>> some
> >>>>>> which shows not only
> >>>>>> the actual percentage which is not so useful by some
monitor graph.
> >>>>>>
> >>>>>> I have the following concerns:
> >>>>>> - I can think of a bar chart or a line chart and not sure
what would
> >>>>>> be
> >>>>>> better.
> >>>>>> - Not sure if replacing the current chart with a bar/line
chart
> >>>>>> would
> >>>>>> make
> >>>>>> the statistics readable enough. Maybe if you hover the
chart it
> >>>>>> could
> >>>>>> pop
> >>>>>> up a bigger version of the chart? Or not needed?
> >>>>>> - Would it be enough to have it in one color? Or should it
be
> >>>>>> something
> >>>>>> like "the bigger the utilization the more red"?
> >>>>>>
> >>>>>> Please advise from the UX perspective. As soon as the final
design
> >>>>>> will
> >>>>>> be
> >>>>>> a bit more clear I will provide a feature page.
> >>>>>>
> >>>>>> Thank you,
> >>>>>> Tomas
> >>>>>>
> >>>>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel(a)ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>
> >>>>>
> >>>>> a moving trend graph (just like fedora's system monitor
for
> >>>>> cpu/ram/network) is what i have in mind. so a line chart.
> >>>>> you could have a single chart with different lines for
> >>>>> cpu/ram/network,
> >>>>> or what seems to be more common, a chart per monitored fact
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel(a)ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel(a)ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>