In queueing theory is well-known that for applications which requires less processing time, it is desirable to give a higher priority. In particular for operating systems it means that for processes which demands less CPU time, it is necessary to assign higher priority. But in practice in desktops this simple theoretical rule often cannot be fulfilled. Execution time of various processes cannot be predicted. What's worse - in various periods the same processes create absolutely different load on the CPU.

Somebodies may seem the issue is not important: indeed, whatever the priorities assigned to simultaneously executable tasks, its common running time remains invariable.

We will try to show, what we lose without paying attention to priorities by means of the small program on Perl. The niced_forks.pl program is written respecting the recommendations developed in the "Error message" article. It takes as arguments, priorities for started processes (number from -20 for most favorable scheduling to 19 for least favorable). All processes executes the same operations, but the each next process repeats it 4 times more than previous. At finish process informs its number and execution time.

For demonstration we will start 5 processes.

At first we will try to start them with the same zero niceness:

$ ./niced_forks.pl 0 0 0 0 0
Process 1. 0.074 seconds!
Process 2. 0.390 seconds!
Process 3. 1.507 seconds!
Process 4. 4.360 seconds!
Process 5. 10.323 seconds!

Secondly we'll start it with growing priority (i.e. the processes demanding more time will be executed against the advice of the queuing theory with higher priority):

$ ./niced_forks.pl 8 6 4 2 0
Process 1. 0.468 seconds!
Process 2. 1.155 seconds!
Process 3. 2.818 seconds!
Process 4. 5.661 seconds!
Process 5. 10.139 seconds!

This clearly shows that the execution time of the last (longest) process practically has not changed, but execution time of shorter processes has increased from 6 times (for the shortest process) to 30 % (for 4th process).

Now we will try to start processes with decreasing priority that demanded by the theory:

$ ./niced_forks.pl 0 2 4 6 8
Process 1. 0.031 seconds!
Process 2. 0.259 seconds!
Process 3. 1.019 seconds!
Process 4. 3.491 seconds!
Process 5. 9.528 seconds!

Our experiment with one execution actually is not quite pure, but plural executions only confirm that only changing priorities we can achieve reduction of execution time of short processes by 30-50 % practically approximating them up the time of performance on the absolutely not loaded computer.

In unDE it would be desirable to achieve, that each task has the estimation of the resources necessary to it such as:

Thus under the task understands the task assigned by the user before the system and at execution which not necessary any more data from the user. For example, the task is "to open the document" (time of an application launch till the moment when it will be ready to accept commands of the user), "to save document", "to turn image". Execution of the whole process such as "oowriter" is not task, as really the user constantly enters new commands and only he/she defines, when it will be completed.

It will allow:

It is natural that it is almost impossible to define execution time of any task accurate within a second. And even if it is possible, often it demands so long time as the task. For reduction of this time we can to index such data as the size of directories and some other useful at estimation of execution time of a task. To increase information content for user it is desirable to produce not only estimation time, but also prospective accuracy of this estimation. Among other things it'll help to avoid a situation with every second changing estimation, after all if the following estimation keeps within an error put in previous one, its value can be not changed.

Certainly, all these advantages in many respects while only the wished. But in the project unDE we in details research this question and we will describe in the future articles.