10:40 a.m.
----- Original Message -----
From: "Malini Rao" <mrao(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: Friday, November 8, 2013 3:42:11 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- 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?
No :) It will just update this one value. Now the question is how often and what value
will you get.
I will look into this deeper and get back to this list.
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
> >
>