On 07/11/13 09:26, Tomas Jelinek wrote: > > > ----- Original Message ----- >> From: "Lior Vernia" <lver...@redhat.com> >> To: "Einav Cohen" <eco...@redhat.com> >> Cc: "Eldan Hildesheim" <ehild...@redhat.com>, "engine-devel" >> <engine-devel@ovirt.org>, "info" <i...@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" <ih...@redhat.com> >>>>> To: "Tomas Jelinek" <tjeli...@redhat.com>, "engine-devel" >>>>> <engine-devel@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@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@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel