New progress meters

New progress meters

[Gary Thomas]

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
------------------------------------------------------------

Re: New progress meters

[Paul Eggleton]

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

Re: New progress meters

[Gary Thomas]

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
------------------------------------------------------------

Re: New progress meters

[Barros Pena, Belen]

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

Re: New progress meters

[Gary Thomas]

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
------------------------------------------------------------

Re: New progress meters

[Burton, Ross]

[-- 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 --]

Re: New progress meters

[Mark Hatle]

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
> 
> 

Re: New progress meters

[Paul Eggleton]

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

Re: New progress meters

[Paul Eggleton]

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

Re: New progress meters

[Gary Thomas]

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
------------------------------------------------------------

Re: New progress meters

[Paul Eggleton]

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

Re: New progress meters

[Trevor Woerner]

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?

Re: New progress meters

[Paul Eggleton]

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