All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: New progress meters
Date: Tue, 19 Jul 2016 11:21:54 +0200	[thread overview]
Message-ID: <578DF132.7020101@mlbassoc.com> (raw)
In-Reply-To: <9795063.LvlJDZtIeJ@peggleto-mobl.ger.corp.intel.com>

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


  reply	other threads:[~2016-07-19  9:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19  6:33 New progress meters Gary Thomas
2016-07-19  9:16 ` Paul Eggleton
2016-07-19  9:21   ` Gary Thomas [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=578DF132.7020101@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.