* New progress meters @ 2016-07-19 6:33 Gary Thomas 2016-07-19 9:16 ` Paul Eggleton 0 siblings, 1 reply; 13+ messages in thread From: Gary Thomas @ 2016-07-19 6:33 UTC (permalink / raw) To: bitbake-devel I quite like the new progress meters, but they seem to not be very accurate. I was just rebuilding webkitgtk and got this: 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% |####################################### | ETA: 0:02:58 Sadly, it sat there, waffling between 02:58 and 03:44 for about 10 minutes... * How is this [estimate] calculated? * Should I be concerned when it's not accurate (or even moving)? n.b. I wasn't sure the best place for this question, the bitbake list, generic Yocto or OE-core. Feel free to redirect as needed. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 6:33 New progress meters Gary Thomas @ 2016-07-19 9:16 ` Paul Eggleton 2016-07-19 9:21 ` Gary Thomas 2016-07-19 9:43 ` Barros Pena, Belen 0 siblings, 2 replies; 13+ messages in thread From: Paul Eggleton @ 2016-07-19 9:16 UTC (permalink / raw) To: Gary Thomas; +Cc: bitbake-devel Hi Gary, On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: > I quite like the new progress meters, but they seem to not be very > accurate. I was just rebuilding webkitgtk and got this: > > 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% > |####################################### | ETA: 0:02:58 > > Sadly, it sat there, waffling between 02:58 and 03:44 for about > 10 minutes... > > * How is this [estimate] calculated? > * Should I be concerned when it's not accurate (or even moving)? There are a few different types of progress handling for different types of tasks. To be specific in this example, for recipes that inherit cmake during do_compile we report the progress that the cmake-produced makefile prints out. The ETA, which is implemented in the python-progressbar code we are using is kind of a rolling average calculated based on recent progress, so it's possible it's inaccurate in this instance if there are places where it stalls. Python-progressbar has an alternative ETA mode which we could try, but to be honest when the progress value sent to it isn't evenly apportioned with respect to time and we don't have any weighting information, there's not a lot anyone can do to estimate time remaining accurately. If it's truly bothersome we could just turn off the ETA display I suppose. > n.b. I wasn't sure the best place for this question, the bitbake > list, generic Yocto or OE-core. Feel free to redirect as needed. Technically this is an OE question although I know that isn't obvious - there are parts of this that are implemented in BitBake and parts in OE, so asking here is fine. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 9:16 ` Paul Eggleton @ 2016-07-19 9:21 ` Gary Thomas 2016-07-19 16:45 ` Burton, Ross 2016-07-19 9:43 ` Barros Pena, Belen 1 sibling, 1 reply; 13+ messages in thread From: Gary Thomas @ 2016-07-19 9:21 UTC (permalink / raw) To: Paul Eggleton; +Cc: bitbake-devel On 2016-07-19 11:16, Paul Eggleton wrote: > Hi Gary, > > On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: >> I quite like the new progress meters, but they seem to not be very >> accurate. I was just rebuilding webkitgtk and got this: >> >> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% >> |####################################### | ETA: 0:02:58 >> >> Sadly, it sat there, waffling between 02:58 and 03:44 for about >> 10 minutes... >> >> * How is this [estimate] calculated? >> * Should I be concerned when it's not accurate (or even moving)? > > There are a few different types of progress handling for different types of > tasks. To be specific in this example, for recipes that inherit cmake during > do_compile we report the progress that the cmake-produced makefile prints out. > The ETA, which is implemented in the python-progressbar code we are using is > kind of a rolling average calculated based on recent progress, so it's > possible it's inaccurate in this instance if there are places where it stalls. > Python-progressbar has an alternative ETA mode which we could try, but to be > honest when the progress value sent to it isn't evenly apportioned with > respect to time and we don't have any weighting information, there's not a lot > anyone can do to estimate time remaining accurately. If it's truly bothersome > we could just turn off the ETA display I suppose. > >> n.b. I wasn't sure the best place for this question, the bitbake >> list, generic Yocto or OE-core. Feel free to redirect as needed. > > Technically this is an OE question although I know that isn't obvious - there > are parts of this that are implemented in BitBake and parts in OE, so asking > here is fine. Thanks. I was mostly asking to see what the expected "user experience" should be since the webkitgtk (which takes FOREVER to build) seemed a bit misleading/optimistic. For the most part, I do like the additional information. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 9:21 ` Gary Thomas @ 2016-07-19 16:45 ` Burton, Ross 2016-07-19 17:06 ` Mark Hatle 0 siblings, 1 reply; 13+ messages in thread From: Burton, Ross @ 2016-07-19 16:45 UTC (permalink / raw) To: Gary Thomas; +Cc: Paul Eggleton, bitbake-devel [-- Attachment #1: Type: text/plain, Size: 581 bytes --] On 19 July 2016 at 10:21, Gary Thomas <gary@mlbassoc.com> wrote: > Thanks. I was mostly asking to see what the expected "user experience" > should be since the webkitgtk (which takes FOREVER to build) seemed a > bit misleading/optimistic. For the most part, I do like the additional > information. > The situation here is that cmake counts the steps and announces its progress through them as the progress. Of course the last step is to link about 8GB of binaries... A progress bar is better than no progress bar, so I still call this an improvement :) Ross [-- Attachment #2: Type: text/html, Size: 1061 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 16:45 ` Burton, Ross @ 2016-07-19 17:06 ` Mark Hatle 2016-07-19 20:29 ` Paul Eggleton 0 siblings, 1 reply; 13+ messages in thread From: Mark Hatle @ 2016-07-19 17:06 UTC (permalink / raw) To: Burton, Ross, Gary Thomas; +Cc: Paul Eggleton, bitbake-devel On 7/19/16 11:45 AM, Burton, Ross wrote: > > On 19 July 2016 at 10:21, Gary Thomas <gary@mlbassoc.com > <mailto:gary@mlbassoc.com>> wrote: > > Thanks. I was mostly asking to see what the expected "user experience" > should be since the webkitgtk (which takes FOREVER to build) seemed a > bit misleading/optimistic. For the most part, I do like the additional > information. > > > The situation here is that cmake counts the steps and announces its progress > through them as the progress. Of course the last step is to link about 8GB of > binaries... > > A progress bar is better than no progress bar, so I still call this an > improvement :) We have (had, python 3 broke it) a patch to knotty that permits the logs to be presented on the screen during a build so for places where you think it might have hung you can at least get some status. I like the idea of a progress bar.. but we need to weigh the 'it looks like it froze' vs 'make sure people know things are still moving'. in the GUI world this is the old hour glass/spinning cursor/rotating progress bar -- vs a progress meter behavior.. --Mark > Ross > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 17:06 ` Mark Hatle @ 2016-07-19 20:29 ` Paul Eggleton 2017-02-09 1:14 ` Trevor Woerner 0 siblings, 1 reply; 13+ messages in thread From: Paul Eggleton @ 2016-07-19 20:29 UTC (permalink / raw) To: Mark Hatle; +Cc: bitbake-devel, Gary Thomas On Tue, 19 Jul 2016 12:06:46 Mark Hatle wrote: > On 7/19/16 11:45 AM, Burton, Ross wrote: > > On 19 July 2016 at 10:21, Gary Thomas <gary@mlbassoc.com > > > > <mailto:gary@mlbassoc.com>> wrote: > > Thanks. I was mostly asking to see what the expected "user > > experience" > > should be since the webkitgtk (which takes FOREVER to build) seemed a > > bit misleading/optimistic. For the most part, I do like the > > additional > > information. > > > > The situation here is that cmake counts the steps and announces its > > progress through them as the progress. Of course the last step is to > > link about 8GB of binaries... > > > > A progress bar is better than no progress bar, so I still call this an > > improvement :) > > We have (had, python 3 broke it) a patch to knotty that permits the logs to > be presented on the screen during a build so for places where you think it > might have hung you can at least get some status. > > I like the idea of a progress bar.. but we need to weigh the 'it looks like > it froze' vs 'make sure people know things are still moving'. > > in the GUI world this is the old hour glass/spinning cursor/rotating > progress bar -- vs a progress meter behavior.. We can certainly do something like that - the progress handler sees all output even if it doesn't contain anything interesting to it (e.g. % complete). The trouble comes when the process prints out nothing - such as when linking a very large binary. I'm not sure how you would introspect into that part of the process. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 20:29 ` Paul Eggleton @ 2017-02-09 1:14 ` Trevor Woerner 2017-02-09 4:09 ` Paul Eggleton 0 siblings, 1 reply; 13+ messages in thread From: Trevor Woerner @ 2017-02-09 1:14 UTC (permalink / raw) To: Paul Eggleton; +Cc: bitbake-devel On Wed 2016-07-20 @ 08:29:52 AM, Paul Eggleton wrote: ^^^^^^^^^^ ... talk about showing up late to the party! ;-) > We can certainly do something like that - the progress handler sees all output > even if it doesn't contain anything interesting to it (e.g. % complete). The > trouble comes when the process prints out nothing - such as when linking a > very large binary. I'm not sure how you would introspect into that part of the > process. Would it be possible to show progress such that once a recipe started to be processed, it would remain in view until it was done (preferably in the same relative location)? Let's say you have a recipe abc.bb whose tasks are: fetch, unpack, patch, configure, compile, deploy, package. I think it might be nice if, once bitbake started processing abc, we saw something like: before-4.5.6 ... abc-1.2.3 do_fetch ===> after-0.9.8 ... Then when the fetch was done we'd see before-4.5.6 ... abc-1.2.3 do_unpack ===|==> after-0.9.8 ... then before-4.5.6 ... abc-1.2.3 do_patch ===|===|=> after-0.9.8 ... Or, maybe: before-4.5.6 ... abc-1.2.3 =fetch= after-0.9.8 ... before-4.5.6 ... abc-1.2.3 =fetch=|=unpack= after-0.9.8 ... before-4.5.6 ... abc-1.2.3 =fetch=|=unpack=|=patch= after-0.9.8 ... Maybe the different tasks could have their own colours? Perhaps the equals signs could be used to show progress: as a task progresses more equals signs would be printed, then the pipe drawn and the new task drawing started when the next task begins? At the end of processing abc we might see something like: abc-1.2.3 =fetch===========|=unpack=|=patch=|=configure====|=compile===========================================|=deploy===|=package== which tells us that fetching and compiling were this recipe's largest jobs. I guess the largest problem would be handling the vertical real-estate. With hundreds of packages, the output would scroll off rather quickly. Maybe once a recipe was complete it could drop off? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2017-02-09 1:14 ` Trevor Woerner @ 2017-02-09 4:09 ` Paul Eggleton 0 siblings, 0 replies; 13+ messages in thread From: Paul Eggleton @ 2017-02-09 4:09 UTC (permalink / raw) To: Trevor Woerner; +Cc: bitbake-devel On Wednesday, 8 February 2017 8:14:11 PM NZDT Trevor Woerner wrote: > On Wed 2016-07-20 @ 08:29:52 AM, Paul Eggleton wrote: > ^^^^^^^^^^ > ... talk about showing up late to the party! ;-) It's never too late :) > > We can certainly do something like that - the progress handler sees all > > output even if it doesn't contain anything interesting to it (e.g. % > > complete). The trouble comes when the process prints out nothing - such > > as when linking a very large binary. I'm not sure how you would > > introspect into that part of the process. > > Would it be possible to show progress such that once a recipe started to be > processed, it would remain in view until it was done (preferably in the same > relative location)? > > Let's say you have a recipe abc.bb whose tasks are: fetch, unpack, patch, > configure, compile, deploy, package. I think it might be nice if, once > bitbake started processing abc, we saw something like: > > > before-4.5.6 ... > abc-1.2.3 do_fetch ===> > after-0.9.8 ... > > Then when the fetch was done we'd see > > before-4.5.6 ... > abc-1.2.3 do_unpack ===|==> > after-0.9.8 ... > > then > > before-4.5.6 ... > abc-1.2.3 do_patch ===|===|=> > after-0.9.8 ... > > > Or, maybe: > > before-4.5.6 ... > abc-1.2.3 =fetch= > after-0.9.8 ... > > before-4.5.6 ... > abc-1.2.3 =fetch=|=unpack= > after-0.9.8 ... > > before-4.5.6 ... > abc-1.2.3 =fetch=|=unpack=|=patch= > after-0.9.8 ... > > Maybe the different tasks could have their own colours? Perhaps the equals > signs could be used to show progress: as a task progresses more equals signs > would be printed, then the pipe drawn and the new task drawing started when > the next task begins? At the end of processing abc we might see something > like: > > abc-1.2.3 > =fetch===========|=unpack=|=patch=|=configure====|=compile================= > ==========================|=deploy===|=package== > > which tells us that fetching and compiling were this recipe's largest jobs. > > I guess the largest problem would be handling the vertical real-estate. With > hundreds of packages, the output would scroll off rather quickly. Maybe > once a recipe was complete it could drop off? So this is an interesting idea. The challenge though as I mentioned in my previous email is about knowing how long the task is going to take - right now we only have this for a few tasks. In this case you would use that to scale the bar for each task with respect to the screen width - if you don't have this scaling then either horizontal real-estate is going to be an additional problem, or there won't be any ability to compare the task times (at least within the same recipe - this would prevent comparing between recipes). Whilst we could get an approximation of total task time if we know how long the log file is expected to be, I still haven't figured out a good way of having even that information available before the build, though I have to admit I haven't spent much time thinking about it since the changes went in. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 9:16 ` Paul Eggleton 2016-07-19 9:21 ` Gary Thomas @ 2016-07-19 9:43 ` Barros Pena, Belen 2016-07-19 9:53 ` Gary Thomas 2016-07-19 21:12 ` Paul Eggleton 1 sibling, 2 replies; 13+ messages in thread From: Barros Pena, Belen @ 2016-07-19 9:43 UTC (permalink / raw) To: Paul Eggleton, Gary Thomas; +Cc: bitbake-devel@lists.openembedded.org On 19/07/2016 10:16, "bitbake-devel-bounces@lists.openembedded.org on behalf of Paul Eggleton" <bitbake-devel-bounces@lists.openembedded.org on behalf of paul.eggleton@linux.intel.com> wrote: >Hi Gary, > >On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: >> I quite like the new progress meters, but they seem to not be very >> accurate. I was just rebuilding webkitgtk and got this: >> >> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% >> |####################################### | ETA: 0:02:58 >> >> Sadly, it sat there, waffling between 02:58 and 03:44 for about >> 10 minutes... >> >> * How is this [estimate] calculated? >> * Should I be concerned when it's not accurate (or even moving)? > >There are a few different types of progress handling for different types >of >tasks. To be specific in this example, for recipes that inherit cmake >during >do_compile we report the progress that the cmake-produced makefile prints >out. >The ETA, which is implemented in the python-progressbar code we are using >is >kind of a rolling average calculated based on recent progress, so it's >possible it's inaccurate in this instance if there are places where it >stalls. >Python-progressbar has an alternative ETA mode which we could try, but to >be >honest when the progress value sent to it isn't evenly apportioned with >respect to time and we don't have any weighting information, there's not >a lot >anyone can do to estimate time remaining accurately. If it's truly >bothersome >we could just turn off the ETA display I suppose. Big caveat: this is just my opinion. Displaying information we are not sure is accurate is probably not a good idea: it disconcerts people, creates false expectations and ultimately undermines trust on the system. If you are not sure the ETA is reliable, I would remove it. Just my 2c. Cheers Belén > >> n.b. I wasn't sure the best place for this question, the bitbake >> list, generic Yocto or OE-core. Feel free to redirect as needed. > >Technically this is an OE question although I know that isn't obvious - >there >are parts of this that are implemented in BitBake and parts in OE, so >asking >here is fine. > >Cheers, >Paul > >-- > >Paul Eggleton >Intel Open Source Technology Centre >-- >_______________________________________________ >bitbake-devel mailing list >bitbake-devel@lists.openembedded.org >http://lists.openembedded.org/mailman/listinfo/bitbake-devel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 9:43 ` Barros Pena, Belen @ 2016-07-19 9:53 ` Gary Thomas 2016-07-19 21:12 ` Paul Eggleton 1 sibling, 0 replies; 13+ messages in thread From: Gary Thomas @ 2016-07-19 9:53 UTC (permalink / raw) To: bitbake-devel On 2016-07-19 11:43, Barros Pena, Belen wrote: > > > On 19/07/2016 10:16, "bitbake-devel-bounces@lists.openembedded.org on > behalf of Paul Eggleton" <bitbake-devel-bounces@lists.openembedded.org on > behalf of paul.eggleton@linux.intel.com> wrote: > >> Hi Gary, >> >> On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: >>> I quite like the new progress meters, but they seem to not be very >>> accurate. I was just rebuilding webkitgtk and got this: >>> >>> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% >>> |####################################### | ETA: 0:02:58 >>> >>> Sadly, it sat there, waffling between 02:58 and 03:44 for about >>> 10 minutes... >>> >>> * How is this [estimate] calculated? >>> * Should I be concerned when it's not accurate (or even moving)? >> >> There are a few different types of progress handling for different types >> of >> tasks. To be specific in this example, for recipes that inherit cmake >> during >> do_compile we report the progress that the cmake-produced makefile prints >> out. >> The ETA, which is implemented in the python-progressbar code we are using >> is >> kind of a rolling average calculated based on recent progress, so it's >> possible it's inaccurate in this instance if there are places where it >> stalls. >> Python-progressbar has an alternative ETA mode which we could try, but to >> be >> honest when the progress value sent to it isn't evenly apportioned with >> respect to time and we don't have any weighting information, there's not >> a lot >> anyone can do to estimate time remaining accurately. If it's truly >> bothersome >> we could just turn off the ETA display I suppose. > > Big caveat: this is just my opinion. Displaying information we are not > sure is accurate is probably not a good idea: it disconcerts people, > creates false expectations and ultimately undermines trust on the system. > > If you are not sure the ETA is reliable, I would remove it. ETA is always that - ESTIMATED. That said, I'd agree that it should be "close" or not used at all. Who amongst us has waited for that last 2 minutes downloading some update...? > > Just my 2c. > > Cheers > > Belén > >> >>> n.b. I wasn't sure the best place for this question, the bitbake >>> list, generic Yocto or OE-core. Feel free to redirect as needed. >> >> Technically this is an OE question although I know that isn't obvious - >> there >> are parts of this that are implemented in BitBake and parts in OE, so >> asking >> here is fine. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 9:43 ` Barros Pena, Belen 2016-07-19 9:53 ` Gary Thomas @ 2016-07-19 21:12 ` Paul Eggleton 2016-07-20 5:34 ` Gary Thomas 1 sibling, 1 reply; 13+ messages in thread From: Paul Eggleton @ 2016-07-19 21:12 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: bitbake-devel@lists.openembedded.org, Gary Thomas On Tue, 19 Jul 2016 09:43:16 Barros Pena, Belen wrote: > On 19/07/2016 10:16, "bitbake-devel-bounces@lists.openembedded.org on > behalf of Paul Eggleton" <bitbake-devel-bounces@lists.openembedded.org on > > behalf of paul.eggleton@linux.intel.com> wrote: > >Hi Gary, > > > >On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: > >> I quite like the new progress meters, but they seem to not be very > >> accurate. I was just rebuilding webkitgtk and got this: > >> > >> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% > >> > >> |####################################### | ETA: 0:02:58 > >> > >> Sadly, it sat there, waffling between 02:58 and 03:44 for about > >> 10 minutes... > >> > >> * How is this [estimate] calculated? > >> * Should I be concerned when it's not accurate (or even moving)? > > > >There are a few different types of progress handling for different types > >of tasks. To be specific in this example, for recipes that inherit cmake > >during do_compile we report the progress that the cmake-produced makefile > >prints out. The ETA, which is implemented in the python-progressbar code we > >are using is kind of a rolling average calculated based on recent progress, > >so it's possible it's inaccurate in this instance if there are places where > >it stalls. Python-progressbar has an alternative ETA mode which we could > >try, but to be honest when the progress value sent to it isn't evenly > >apportioned with respect to time and we don't have any weighting > >information, there's not a lot anyone can do to estimate time remaining > >accurately. If it's truly bothersome we could just turn off the ETA display > >I suppose. > > Big caveat: this is just my opinion. Displaying information we are not > sure is accurate is probably not a good idea: it disconcerts people, > creates false expectations and ultimately undermines trust on the system. > > If you are not sure the ETA is reliable, I would remove it. > > Just my 2c. Right, I see your point - the entire reason I added this was to give the user some reassurance about the progress and if it's misleading then it does the opposite. I think I will just remove it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-19 21:12 ` Paul Eggleton @ 2016-07-20 5:34 ` Gary Thomas 2016-07-20 21:19 ` Paul Eggleton 0 siblings, 1 reply; 13+ messages in thread From: Gary Thomas @ 2016-07-20 5:34 UTC (permalink / raw) To: bitbake-devel On 2016-07-19 23:12, Paul Eggleton wrote: > On Tue, 19 Jul 2016 09:43:16 Barros Pena, Belen wrote: >> On 19/07/2016 10:16, "bitbake-devel-bounces@lists.openembedded.org on >> behalf of Paul Eggleton" <bitbake-devel-bounces@lists.openembedded.org on >> >> behalf of paul.eggleton@linux.intel.com> wrote: >>> Hi Gary, >>> >>> On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: >>>> I quite like the new progress meters, but they seem to not be very >>>> accurate. I was just rebuilding webkitgtk and got this: >>>> >>>> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% >>>> >>>> |####################################### | ETA: 0:02:58 >>>> >>>> Sadly, it sat there, waffling between 02:58 and 03:44 for about >>>> 10 minutes... >>>> >>>> * How is this [estimate] calculated? >>>> * Should I be concerned when it's not accurate (or even moving)? >>> >>> There are a few different types of progress handling for different types >>> of tasks. To be specific in this example, for recipes that inherit cmake >>> during do_compile we report the progress that the cmake-produced makefile >>> prints out. The ETA, which is implemented in the python-progressbar code we >>> are using is kind of a rolling average calculated based on recent progress, >>> so it's possible it's inaccurate in this instance if there are places where >>> it stalls. Python-progressbar has an alternative ETA mode which we could >>> try, but to be honest when the progress value sent to it isn't evenly >>> apportioned with respect to time and we don't have any weighting >>> information, there's not a lot anyone can do to estimate time remaining >>> accurately. If it's truly bothersome we could just turn off the ETA display >>> I suppose. >> >> Big caveat: this is just my opinion. Displaying information we are not >> sure is accurate is probably not a good idea: it disconcerts people, >> creates false expectations and ultimately undermines trust on the system. >> >> If you are not sure the ETA is reliable, I would remove it. >> >> Just my 2c. > > Right, I see your point - the entire reason I added this was to give the user > some reassurance about the progress and if it's misleading then it does the > opposite. I think I will just remove it. Maybe leave the progress bar (which I do find useful), but remove the ETA? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: New progress meters 2016-07-20 5:34 ` Gary Thomas @ 2016-07-20 21:19 ` Paul Eggleton 0 siblings, 0 replies; 13+ messages in thread From: Paul Eggleton @ 2016-07-20 21:19 UTC (permalink / raw) To: Gary Thomas; +Cc: bitbake-devel On Wed, 20 Jul 2016 07:34:51 Gary Thomas wrote: > On 2016-07-19 23:12, Paul Eggleton wrote: > > On Tue, 19 Jul 2016 09:43:16 Barros Pena, Belen wrote: > >> On 19/07/2016 10:16, "bitbake-devel-bounces@lists.openembedded.org on > >> behalf of Paul Eggleton" <bitbake-devel-bounces@lists.openembedded.org on > >> > >> behalf of paul.eggleton@linux.intel.com> wrote: > >>> Hi Gary, > >>> > >>> On Tue, 19 Jul 2016 08:33:54 Gary Thomas wrote: > >>>> I quite like the new progress meters, but they seem to not be very > >>>> accurate. I was just rebuilding webkitgtk and got this: > >>>> > >>>> 0: webkitgtk-2.12.3-r0 do_compile (pid 30494) 96% > >>>> > >>>> |####################################### | ETA: 0:02:58 > >>>> > >>>> Sadly, it sat there, waffling between 02:58 and 03:44 for about > >>>> 10 minutes... > >>>> > >>>> * How is this [estimate] calculated? > >>>> * Should I be concerned when it's not accurate (or even moving)? > >>> > >>> There are a few different types of progress handling for different types > >>> of tasks. To be specific in this example, for recipes that inherit cmake > >>> during do_compile we report the progress that the cmake-produced > >>> makefile > >>> prints out. The ETA, which is implemented in the python-progressbar code > >>> we > >>> are using is kind of a rolling average calculated based on recent > >>> progress, > >>> so it's possible it's inaccurate in this instance if there are places > >>> where > >>> it stalls. Python-progressbar has an alternative ETA mode which we could > >>> try, but to be honest when the progress value sent to it isn't evenly > >>> apportioned with respect to time and we don't have any weighting > >>> information, there's not a lot anyone can do to estimate time remaining > >>> accurately. If it's truly bothersome we could just turn off the ETA > >>> display > >>> I suppose. > >> > >> Big caveat: this is just my opinion. Displaying information we are not > >> sure is accurate is probably not a good idea: it disconcerts people, > >> creates false expectations and ultimately undermines trust on the system. > >> > >> If you are not sure the ETA is reliable, I would remove it. > >> > >> Just my 2c. > > > > Right, I see your point - the entire reason I added this was to give the > > user some reassurance about the progress and if it's misleading then it > > does the opposite. I think I will just remove it. > > Maybe leave the progress bar (which I do find useful), but > remove the ETA? Right - I guess it wasn't clear from what I wrote, but that's what I meant. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-02-09 4:09 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-19 6:33 New progress meters Gary Thomas 2016-07-19 9:16 ` Paul Eggleton 2016-07-19 9:21 ` Gary Thomas 2016-07-19 16:45 ` Burton, Ross 2016-07-19 17:06 ` Mark Hatle 2016-07-19 20:29 ` Paul Eggleton 2017-02-09 1:14 ` Trevor Woerner 2017-02-09 4:09 ` Paul Eggleton 2016-07-19 9:43 ` Barros Pena, Belen 2016-07-19 9:53 ` Gary Thomas 2016-07-19 21:12 ` Paul Eggleton 2016-07-20 5:34 ` Gary Thomas 2016-07-20 21:19 ` Paul Eggleton
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.