https://bugs.kde.org/show_bug.cgi?id=404868
Bug ID: 404868
Summary: Scheduler delays subsequent jobs when hitting a
restriction violation
Product: kstars
Version: 3.0.1
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mutla...@ikarustech.com
Reporter: eric.dejouha...@gmail.com
Target Milestone: ---
SUMMARY
Scheduler properly reschedules a job that crossed its altitude limit to the
next acceptable startup time and waits for its rescheduled startup time.
However, this prevents further jobs in the list from executing at that moment:
following the ordering rule, they are rescheduled after the restricted job.
This can be worked around by automatically reordering jobs each time the list
is evaluated, but that feature is often disregarded because it doesn't (yet)
address obstructed horizon.
STEPS TO REPRODUCE
1. Schedule two asap jobs, first of which has an altitude restriction, second
of which has none (warning: there is a minimal altitude limit hard-coded
whatever the value of the restriction box).
2. Execute the plan so that while running, the first job violates the altitude
restriction, but not the second job.
3. Observe behavior
OBSERVED RESULT
First job is aborted, and rescheduled hours later when the altitude restriction
can be complied with. Second job is shifted to start after first job, often on
the next night and doesn't execute right now although no restriction would
prevent that. If happening on the beginning of the night, this wastes the whole
night.
EXPECTED RESULT
The behavior is compliant with the algorithm. However, it would seem more
natural that the violating job is aborted, and the next is processed.
SOFTWARE/OS VERSIONS
Windows:
MacOS:
Linux/KDE Plasma: Ubuntu 18.04 - KStars 2019-02-21T21:29:33Z built from git
state ~3h before that time.
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
This is not a bug, this is how the algorithm was designed. Changing the
behavior to address this issue would be an improvement.
First, if currently running, Scheduler could avoid updating the current
schedule of subsequent jobs after such violation, unless there are no jobs left
to run. Scheduler would then continue with the next job that is ready to run.
What is the job that is ready to run? Restriction violations are detected while
scheduling and marked with a warning icon in the list, so the end-user is aware
of possible issues in that case. Violations may also appear because of a
runtime delay (customizing how long accessory steps take is not implemented as
of now). Well, in order to manage those two situations, when running, Scheduler
should decide to abort subsequent jobs that are too late based on their startup
time (this is already in the code), without changing the schedule (this is
not).
To relax the situation (but this is a further improvement, not needed right
now) and avoid delaying the whole schedule too much, Scheduler could abort jobs
which have less than 50% of their duration remaining based on their startup
time.
--
You are receiving this mail because:
You are watching all bug changes.
