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
>