D12398: Logs, and reworking job count update and repeated jobs estimation

Eric Dejouhanet noreply at phabricator.kde.org
Sat Apr 21 12:53:08 UTC 2018


TallFurryMan created this revision.
TallFurryMan added a reviewer: mutlaqja.
Restricted Application added a subscriber: KDE Edu.
Restricted Application added a project: KDE Edu.
TallFurryMan requested review of this revision.

REVISION SUMMARY
  Homogeneized scheduler log strings for clarity when reviewing test
  results. Warning, all these logs are using i18n, so those changes
  obviously have an impact on translation, if they are indeed translated.
  
  Reworked job estimation to check the number of light frames for each
  sequence job in the schedule, in order to consolidate the total number
  of frames effectively captured without dropping a sequence job by
  mistake.
  
  Reworked job time estimation to properly account for progress when using
  repeats. Now repeats-required field is expectedly 1 by default.
  
  Reworked capture count algorithm to rely on the state of the job to execute the
  search, and reuse previous results whenever possible. This reduces the
  directory parsing to storages of job which actually changed. Also, this does
  not handle the duplicate scheduler job situation, only the duplicate sequence
  job. But possibly we don't care about the duplicate scheduler job situation,
  that's completely acceptable and so much simpler for the end-user to have two
  duplicated jobs update to an identical status. BUT the case that is not covered
  is the situation where the end-user would like to capture a target multiple
  times, at different times. I believe the option "Remember Job Progress" might
  provide a solution there, but this is to be tested.
  
  There is still work to be done as jobs won't update their capture count in all
  situations. This should be fixed with better control of the job's state, not in
  this function.
  
  I believe this is still quite slow, less than before but still slow. Perhaps
  remove all logs from getCompletedFiles.
  
  This change also re-evaluates job in different situations, to get a more reactive
  and always up-to-date interface. The objective is to never use the "evaluate"
  button except for really resetting jobs.
  
  Also, added mitigation in the case findNextJob can't decide which job to
  select.
  
  This change also works around issue with job definitely abandoned although they
  could be rescheduled later, eventually on another night. This also mitigates
  the issue with altitude cutoff, which apparently can't reliably determine when
  the target is rising instead of falling.
  
  Also, removed scattered return instructions to clarify the algorithm. When a
  capture says "Complete", changed the state to "Evaluation" so that job properly
  recounts its captures and properly considers the work left to be done.
  
  Fixed a few uses of QString::arg(). One call to QString::arg will replace all
  "%X" in the string. Next call to QString::arg will replace all "%X+1", etc.
  
  A few additional fixes for scheduler jobs logs to use job's date format.
  
  FIXME on attempting to request the local server (vs. client) for the number of captures.
  FIXME on refactoring the signature path, which is duplicated at several places.
  FIXME on fixing an issue with filter name, which doesn't get included in the capture path when there is no filter wheel, but still gets included in the signature (workaround: use a filter wheel sim).
  FIXME on finishedFramesCount variable, which is part of an unfinished mechanism and should be removed.
  FIXME on files counted in signature path, because all files are counted, not just captures.
  FIXME on duplicate scheduler jobs vs. duplicate sequence jobs.
  FIXME on altitude cutoff, which might cause jobs to loop over themselves until altitude is properly either allowing startup, or causing effective abort (3 degrees sidereal delay).

TEST PLAN
  - Logs: most of scheduler logs are now homogeneized to start with "Job 'xx'", for ease of reading. However, while they help on understanding what the scheduler is doing, there are probably too many of them.
  - Counting captures: sequences containing multiple jobs with the same signature should properly count their captures ; e.g. 2xLPR, 3xR, 4xLPR with 3xLPR done should properly count 3xR+1xLPR remaining.
  - Repeated scheduler jobs: capture count should display properly, accounting for the number of repeats, even if the job is set to run to sequence completion only for instance ; also, completion should check repeats too.
  - Capture enumeration: jobs should properly count the number of captures for a complex sequence, BUT ONLY if there is a filter wheel available, else will never find any capture.
  - Duplicate scheduler jobs: while duplicate sequence jobs are now behaving properly, duplicate scheduler jobs are clones and evaluate as if they were one single job ; that's not a change/regression, it's just clearer now.
  - Job evaluation: evaluation will now occur in various situations, adding a job for instance ; evaluation is still not stable (in the sense "same user visible input" => "same output"), but better than before.
  - Aborting jobs: aborted jobs will now be often re-evaluated, so that transitory errors are discarded to retry the job ; does not work as well as it could.

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D12398

AFFECTED FILES
  kstars/ekos/scheduler/scheduler.cpp
  kstars/ekos/scheduler/scheduler.ui
  kstars/ekos/scheduler/schedulerjob.cpp
  kstars/ekos/scheduler/schedulerjob.h

To: TallFurryMan, mutlaqja
Cc: #kde_edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20180421/5b11af1b/attachment.html>


More information about the kde-edu mailing list