HEURISTIC’S JOB ORDER EFFICIENCY IN TIGHT-TARDY PROGRESSIVE IDLING-FREE 1-MACHINE PREEMPTIVE SCHEDULING OF EQUAL-LENGTH JOBS

Background. In setting a problem of minimizing total tardiness by the heuristic based on remaining available and processing periods, there are two opposite ways to input the data: the job release dates are given in either ascending or descending order. It was recently proved that an efficient job order can save significant computation time by using the Boolean linear programming model provided for finding schedules with the exactly minimal total tardiness. Objective. The goal is to ascertain whether the job order input is significant in scheduling by using the heuristic. Job order efficiency will be studied on tight-tardy progressive idling-free 1-machine preemptive scheduling of equal-length jobs. Methods. To achieve the said goal, a computational study is carried out with a purpose to estimate the averaged computation time for both ascending and descending orders of job release dates. Instances of the job scheduling problem are generated so that schedules which can be obtained trivially, without the heuristic, are excluded. Results. Scheduling a few jobs is expectedly faster by ascending order, but this part is full of computational artifacts. Scheduling 30 to 70 jobs is 1.5 % to 2.5 % faster by descending order. However, scheduling up to 90 jobs is expectedly still faster by descending order, although a risk of losing this advantage exists. For the number of jobs between roughly 90 and 250, the ascending job order again results in shorter computation times. Since the point of about 250 jobs, the advantage trend (of either ascending or descending order) appears more stable. Conclusions. In scheduling by using the heuristic, the job order input is indeed significant. The average relative difference does not exceed 1.5 % for 2 to 1000 jobs consisting up to 17 processing periods. For obtaining a statistically reliable computation speed advantage, it is better to consider no less than 250 jobs. As either the number of jobs or the number of job parts increases, the computation speed advantage may become unstable and eventually vanish. Nevertheless, the ascending job order can save a lot of computational time in the case of scheduling at least a few thousand jobs having just a few processing periods each. After solving thousands of such cases the saved time may be counted in hours.


Introduction
In scheduling, total tardiness is a measure of delays in executing certain operations. The problem of total tardiness minimization refers to attempts of optimizing time resources and minimizing costs, where jobs have no priorities. This problem has a great impact on dispatching processes like those at airports, water ports, railway stations, etc. [1,2]. Besides, in computing, it is connected with optimizing parallelization of tasksets on multiprocessor systems [3,4].
The exact minimization of total tardiness is possible just for a few jobs whose processing periods are not very long. The Boolean linear programming model and its variations are used for that [5,6]. Nevertheless, the tasksets considered on multiprocessor systems may consist of a few hundreds or thousands of jobs. In this case, total tardiness is minimized by heuristics [7,8]. The heuristic approach is the only means to deal with total tardiness minimization when the number of jobs and the numbers of their processing periods increase.
The heuristic based on the remaining available period and remaining processing period [8] is closely the best as of February 2020. It is an online scheduling algorithm which builds a sequence of jobs successively, without re-arranging them. Once a job is scheduled at a time moment, it will not be changed. So, the jobs already scheduled can be executed straightforwardly without waiting for the entire schedule. All the more so because the entire schedule can be an extremely long sequence of jobs [2,4,8,9].
The accuracy of the heuristic is not ever perfect but, as the size of the job scheduling problem grows, the difference between the heuristic's total tardiness and the real minimum of total tardiness gradually vanishes [8]. A remarkable property of the heuristic is that it schedules just 2 jobs always at the 100 % accuracy, not depending on in how many parts the job is divided (the "2/any" exception). Moreover, the heuristic is sufficiently accurate if no less than 7 jobs divided into no less than five parts each are scheduled (the "7/5" pattern). In general, as the job scheduling problem size grows, the inaccuracy of the heuristic drops [8].

Problem statement
The problem of total tardiness minimization considers job processing periods, release dates and due dates. All they are given as natural numbers. A partial case is when every job has the same length, i. e. the processing periods of all the jobs are equal. In setting a problem of minimizing total tardiness by the heuristic, there are two opposite ways to input the data. On one hand, the job release dates are given in ascending order. This is the common way of inputting the data into the algorithm. Strictly speaking, the release dates can be permuted as one likes or needs to satisfy some external conditions. Thus, on the other hand, the job release dates are given in descending order. Article [5] proves that scheduling a fewer jobs divided into a fewer job parts, using the Boolean linear programming model provided for finding schedules with the exactly minimal total tardiness, is executed on average faster by the descending job order. As the number of jobs increases along with increasing the number of their processing periods, the ascending job order becomes more efficient, although the computation time efficiency by both job orders is not so regular. Hence, the goal is to ascertain whether the job order input is significant in scheduling by using the heuristic. Job order efficiency will be studied on tight-tardy progressive idling-free single machine (1-machine) preemptive scheduling of equal-length jobs [5].

The heuristic based on remaining available and processing periods
, having H processing periods each, their release dates and due dates for release dates (1) or for release dates (2) and at least one of inequalities is violated, where operator (1, ) N returns a pseudorandom  1 N vector whose entries are drawn from the standard normal distribution (with zero mean and unit variance), and function   ( ) returns the integer part of number  (e. g., see [5,9]). So, for a properly given due date shift vector (6), where condition (7) is true and condition (8) is false, due dates (3) set in the order corresponding to ascending order of the release dates (1) are and due dates (4) set in the order corresponding to descending order of the release dates (2) are Thus, components of due dates vector (3) are not given in non-descending order. This is done so because in the case of when is true, a schedule ensuring the exactly minimal total tardiness is found trivially, without resorting to any algorithm or model (see Theorem 1 in [5]). Components of due dates vector (4) are not given in nonascending order by symmetrical reasoning. The heuristic based on remaining available and processing periods minimizes sum (5) Then, for every set of available jobs and a subset Assignment (18) executed by condition (17) for subset (15) implies that, in a case when there are two or more maximal decisive ratios in (15), the earliest job is preferred to be scheduled [8]. Thus, job n is completed after moment Finally, using formula (5), amount is an approximately minimal total tardiness that corresponds to schedule

Generation of the job scheduling problem instances
When due date shift vector (6) is properly generated by the definite numbers of jobs N and of job parts H , due dates (9) corresponding to ascending order and due dates (10) corresponding to descending order are calculated. Then an ascending order schedule by release dates (1) and due dates (9) is computed by the heuristic (12) -(19). Alternatively, a descending order schedule by release dates (2) and due dates (10) is computed as well.
At fixed numbers of jobs N and of job parts , H for a job scheduling problem instance tagged by an integer с, denote the schedule computation times by ascending order and descending order by  ( , , ) Asc N H c and  ( , , ) Desc N H c in milliseconds (ms), respectively. If the total number of the instances is C , then the averaged computation times are In percentage terms, the relative difference between computation times (20) and (21) is Relative difference (22) will be estimated over a natural rectangular lattice, which is formed by It is assumed that the rectangular lattice formed by (23) is sufficient to obtain reliable statistics for unbiased estimation of relative difference (22) by setting number C at no less than 100. So, let  100 C for scheduling more than 400 jobs. For scheduling between 251 and 400 jobs, the most appropriate number is  200. C Further, let  500 C for scheduling between 101 and 250 jobs. Finally, let  1000 C for scheduling no more than 100 jobs. For quick reference, these numbers of the instances are visualized in Fig. 1.

Computational study
The computational study is executed on CPU Intel Core i5-7200U@2.50 GHz using MATLAB R2018a. Fig. 2 shows all the 16 polylines (20) on the same plot versus the number of jobs to be scheduled. For every next H the plot of its polyline is higher. The computational artifacts (unexpected and non-predictable bad range fluctuations) are clearly seen. As the number of job processing periods increases, the averaged computation time by ascending order resembles more an exponential growth. The averaged computation time by descending order appears similarly (Fig. 3), although its computational artifacts are less striking. cessing periods increases from the left to the right downwards. The plot is an entire view of the 16 relative differences, in which all the fluctuations are preserved. There are 11 subplots which are clearly seen to be displaced downwards, i. e. their maximal positive fluctuations are greater than the respective maximal negative fluctuations. However, this does not mean that computing by descending order is faster on average here. Those three subplots clearly seen to be displaced upwards do not imply also an advantage of computing by ascending order. The two subplots in the second row, which seem to have no displacement, cannot be used for implications as well.
A refined version of the fused plot in Fig. 4 is presented in Fig. 5 using the same presentation style, by only cutting values of every polyline to the range of -5 % to 5 %. The horizontal zero level line is put on every subplot: if, within some interval of N , the range fluctuations are below the zero level, then it means that the ascending job order is faster over this interval; otherwise, if they are above the zero level, computing by descending order is faster. Visually, only polylines on the first row (i. e., for ) are seen to be certainly lower (except for a few places which could be considered as microartifacts) than the zero level for  100 N . As the number of job processing periods increases, it is hard to ascertain the computation speed advantage. Nevertheless, it is well seen in every subplot in Fig. 5 that scheduling up to 90 jobs (except for scheduling a few jobs) is faster by descending order. Then, up to approximately 250 jobs, the ascending job order results in shorter computation times. Since the point of about 250 jobs, the advantage trend (of either ascending or descending order) appears more stable.
shown in the barred plot in Fig. 6. Now, it is certainly seen that scheduling jobs consisting of two to four parts is on average faster by ascending order. Scheduling jobs consisting of more than seven parts is on average faster by descending order. The range of jobs consisting of five to seven parts is an interval of uncertainty, where the advantage of the ascending job order is not so reliable. Nevertheless, this is a place wherein the advantage of the ascending job order vanishes and the advantage of the descending job order appears, being weaker though. With the heuristic, neither the advantage of the ascending job order, nor that of the descending job order is significantly strong. For example, scheduling 1000 jobs divided into 17 processing periods each (Fig. 7 shows the due dates for this example) by ascending order takes 327.7 ms, whereas the same task is computed by descending order in 312.2 ms. In fact, the difference is not very great (just 15.5 ms) but if the similar task is computed for, say, 10000 times, then the descending job order allows saving up to 155 seconds. Another example, with 1000 jobs divided into 50 processing periods each (Fig. 8 shows the due dates for this example), is not so promising: the ascending and descending job orders take about 931.8 ms and 929.3 ms, respectively. So, here the difference is just about 2.5 ms and thus the descending job order allows saving slightly more than 25 seconds after 10000 rounds of such a task. Fig. 7. The due dates corresponding to the release dates in ascending order for an example of scheduling 1000 jobs divided into 17 processing periods each; despite the due dates are not given in non-descending order, they roughly are linearly-increasing on average Fig. 8. The due dates corresponding to the release dates in ascending order for an example of scheduling 1000 jobs divided into 50 processing periods each; the due dates roughly are linearly-increasing on average but they appear more scattered (compared to those in Fig. 7) Other scheduling examples similar to the mentioned do not necessarily lead to that the descending job order allows saving some time, whichever it is. As the number of job processing periods increases, there is no certain proof that the average of relative difference (22) shown in Fig. 6 will be still positive. As the number of jobs increases (with the same great number of job processing periods), the descending job order is likely to lose its advantage.

Discussion
Unfortunately, Fig. 6 does not show an entire and reliable panorama of which job order has a computation speed advantage. Moreover, these bars are just a result which should be treated as "on average" only. Thus, scheduling jobs having the minimal number of processing periods is averagely almost 1.5 % faster by ascending order, whereas scheduling 30 to 70 jobs is 1.5 % to 2.5 % faster by descending order (see this in the subplotted polylines of Fig. 5). Therefore, the bars in Fig. 6 will really work for multiple solvings (at least, a few tens of the heuristic's applications are required to establish a stable statistical ratio).
Another nuance is that the computation speed advantage seems to vanish as either the number of jobs or the number of job processing periods increases. Thus, scheduling 1000 jobs divided into 30 processing periods each (the due dates for this example in Fig. 9 appear less scattered than those in Fig. 8, and more scattered than those in Fig. 7) by the ascending and descending job orders takes about 557.5 ms and 557.1 ms, respectively. Such a tiny difference can be really counted as a statistically negligible. After increasing the number of processing periods to 100 each (the due dates for this example in Fig. 10 appear already badly scattered), the job order advantage changes: the ascending and descending job orders take about 1846.8 ms and 1864.1 ms, respectively; so now the ascending job order saves almost 173 seconds after 10000 rounds of such a task. Fig. 9. The on-average-linearly-increasing due dates corresponding to the release dates in ascending order for an example of scheduling 1000 jobs divided into 30 processing periods each Fig. 10. The on-average-linearly-increasing due dates corresponding to the release dates in ascending order for an example of scheduling 1000 jobs divided into 100 processing periods each; in this example, unlike the examples with 17, 50, 30 processing periods, the ascending job order saves almost 173 seconds after 10000 rounds of such a task) Nevertheless, the advantage in computing schedules of huger amounts of jobs having a few processing periods each can be pretty impressive. Thus, a task of scheduling 1000 jobs with two processing periods is solved by the ascending and descending job orders taken about 31.7 ms and 32.4 ms, respectively (the relative difference is 2.32 %, which does not much contradict the longest bar in Fig. 6). For 10000 jobs, these computation times become about 1934.1 ms and 2325.9 ms, respectively, and here the relative difference is a way huger: it is 20.26 %, so, after 10000 rounds of such a task, the ascending job order saves more than an hour (!). Furthermore, for 10000 jobs with three processing periods (it is better to pass to seconds now), these computation times become about 3.57931 seconds and 4.0849 seconds, respectively, and the ascending job order saves more than 1.4044 hours (!).

Conclusions
By using the heuristic based on remaining available and processing periods, the job order input is indeed significant in tight-tardy progressive idlingfree 1-machine preemptive scheduling of equallength jobs. The relative difference between computation times by the job release dates given in ascending order and given in descending order can achieve up to 5 % and even more, although then it is considered as a computational artifact whose probability Regardless of how many processing periods the job has, scheduling a few jobs is expectedly faster by ascending order, but this part is full of computational artifacts. Then, scheduling up to 90 jobs is expectedly faster by descending order. For the number of jobs between roughly 90 and 250, the ascending job order again results in shorter computation times.
On average, where it is better to consider no less than 250 jobs, the computation speed advantage of the ascending job order gradually disappears as the number of job processing periods increases and then the descending job order becomes faster. The break is at about five to seven parts of the job. However, as either the number of jobs or the number of job parts increases, the computation speed advantage may become unstable and eventually vanish. Nevertheless, the ascending job order can save a lot of computational time in the case of scheduling at least a few thousand jobs having just a few processing periods each. After solving thousands of such cases the saved time may be counted in hours. Whether the obtained properties keep in the similar manner for the case of jobs having different number of processing periods is a matter of a further research.