----- Original Message ----- > From: "Tomas Jelinek" <tjeli...@redhat.com> > To: "Malini Rao" <m...@redhat.com> > Cc: "Eldan Hildesheim" <ehild...@redhat.com>, "engine-devel" > <engine-devel@ovirt.org>, "info" <i...@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" <m...@redhat.com> > > To: "Lior Vernia" <lver...@redhat.com> > > Cc: "Tomas Jelinek" <tjeli...@redhat.com>, "Eldan Hildesheim" > > <ehild...@redhat.com>, "engine-devel" > > <engine-devel@ovirt.org>, "info" <i...@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" <lver...@redhat.com> > > To: "Tomas Jelinek" <tjeli...@redhat.com> > > Cc: "Eldan Hildesheim" <ehild...@redhat.com>, "engine-devel" > > <engine-devel@ovirt.org>, "info" <i...@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" <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 > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel