----- Original Message ----- > From: "Malini Rao" <m...@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: 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" <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?
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" <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