Browse Prior Art Database

Smart self-calibrating progress bar Disclosure Number: IPCOM000242954D
Publication Date: 2015-Sep-02
Document File: 3 page(s) / 38K

Publishing Venue

The Prior Art Database


In computer systems a progress of a running task is often presented to the user in a form of progress bar or other progress indicator. User expects from a reliable progress indicator to show what part of the expected execution time has already passed and how much has left. Prior art shows that it is not an easy task to provide a reliable progress bar. It gets easier in special cases when some assumptions can be made about the tasks being executed, but finding a generic solution is much more difficult.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 01 of 3

Smart self-

-calibrating progress bar

   calibrating progress bar
In some applications, for example continuous integration build systems (like Jenkins or Cruise Control) hardly any assumptions can be made about the tasks being executed, because they can change. This innovative solution provides an accurate progress bar in the case when no assumptions could be made about tasks being executed.

This idea can be used in systems that need to show task execution progress, where the task is executed multiple times. A typical example is a continuous integration system where tasks that build a software project are launched many times during project development. The idea allows to accurately estimate progress of task execution based on analysis of logs produced during the current execution and logs produced during previous executions of the same task.

The main advantage of the proposed solution comparing to the prior art:
It is transparent for tasks that are executed. The tasks don't need to call any API for marking progress or any other instrumentation. The only requirement on tasks is that they generate some output (logs), which is a common practice anyway.

If some stage of the task takes more time than usual then the progress indication reflects that (user does not wait until it goes to 99% and then in the last 1% all the work is done).

If a task gets stuck on some step, it can be identified sooner

The idea consists of the following steps:
Gather historical logs of successful task executions


Analyze historical logs of successful task executions to identify log entries that are

2. consistently occurring in the logs. These will be later called reference log entries. For each identified reference log entry calculate average percent of the overall task


execution time at which the reference log entry is printed
Use the knowledge gathered in steps 1 & 2 to analyze log messages from currently


executed task, detect reference log entries and estimate the progress

Below each of the steps is described in more details:

Details for #1:
The supervisor program which executes tasks has to store start time (START_TIMESTAMP) of a task and then watch the log messages printed by the task. Whenever a new line is printed, the supervisor should store the line and current time (LINE_X_TIMESTAMP).

If the execution failed then discard the data stored for that task execution. Otherwise:

After task execution is complete, store the current time. (END_TIMESTAMP).

Calculate total time needed for task execution: TOTAL_TIME = END_TIMESTAMP - START_TIMESTAMP
For each log line X, calculate percent of total execution time: LINE_X_PROGRESS_PERCENT = 100 * (LINE_X_TIMESTAMP - START_TIMESTAMP) / TOTAL_TIME

Details for #2:
1. First, normalize logs:
The log files may contain some strings that are unique to each execution, for example timestamps, or an IP from some pool of machines.

These have to be identified and replaced with a constant label. The supervising program has to be...