Bug 15015

Summary:	Bitbake UI reports incorrect task elapsed time after suspend
Product:	[Build System, Metadata & Runtime] BitBake	Reporter:	Michael Opdenacker <michael.opdenacker>
Component:	bitbake	Assignee:	Richard Purdie <richard.purdie>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Undecided	CC:	poky.bs.watcher, poky.watcher, randy.macleod, ross.burton
Version:	4.2
Target Milestone:	---
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Michael Opdenacker 2023-01-25 08:41:22 UTC

If, during an OpenEmbedded build, the system running BitBake is suspended to RAM, the reported task elapsed times are wrong at resume time. They reflect the difference between current time of day and the time of day the task was started. Instead, I would expect the actual task duration when the system is up:

Currently  4 running tasks (594 of 2884)  20% |####################
0: binutils-cross-x86_64-2.39-r0 do_compile - 12h9m19s (pid 12585)
1: perl-native-5.36.0-r0 do_compile - 12h5m4s (pid 247433)
2: libunistring-native-1.1-r0 do_configure - 38s (pid 274857)
3: libgpg-error-native-1.46-r0 do_configure - 17s (pid 280777)

At least this applies to long enough tasks which were started before the system was suspended.

This should be solved if BitBake compare time using a monotonic clock instead, like by using clock.monotonic().

Comment 1 Richard Purdie 2023-01-25 17:17:44 UTC

I'm not entirely convinced this is a bug. I saw your patch changing the UI code to use time.monotonic() instead of time.time(). 

My worries include:

a) in the code it is documented as "start time" which it no longer is
b) whether we change all places where this is compared to monotonic?
c) there is wide use of time.time() elsewhere in bitbake so we can no longer easily compare timestamps
d) you can't really compare time.monotonic() between processes and we do have multiple processes involved in bitbake

I'd think suspend to RAM in the middle of a build is a relatively rare case and I'm not sure we want to take the risk and complication from trying to change this.

Comment 2 Ross Burton 2023-01-25 17:27:29 UTC

I mostly agree with RP.  It would be nice for the durations to not include time asleep, but that would involve a wholescale review of every timestamp to understand if its a monotonic clock or wall clock.

That's a non-trivial amount of effort for a very niche usecase, IMHO.

Comment 3 Michael Opdenacker 2023-01-25 17:35:27 UTC

Understood, no problem.
I actually suspend my laptop every time I leave it (unless I have an urgent job to complete). This saves a lot a power!
However, I agree this corresponds to a niche case and people are not likely to complain about this minor issue.
I just hoped my patch only impacted the task duration in the UI, but you know better what the side effects may be.
Don't hesitate to close it as "WON'T FIX". It seems I can't.

Comment 4 Randy MacLeod 2023-01-26 15:37:15 UTC

As per discussion above.