uzh / vm-mad

Dynamically grow or shrink GridEngine clusters using cloud-based nodes
https://arxiv.org/abs/1302.2529
Apache License 2.0
3 stars 2 forks source link

Passing of time in `simul.py` and `orchestrator.py` #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We must ensure that the generated output file contains timestamp
records (1st column) in strictly increasing order.

A possible roadmap about this bug:

1. Use `assert` in the code to ensure that this condition holds: each
   time we output a record, it must have a timestamp > the timestamp
   of the last record.

2. Unify time passing in `simul.py` and `orchestrator.py`: both codes
   apparently do their own, separate timekkeping: `simul.py` uses
   `self._step` and `orchestrator.py` uses `self.time_step`.  

   They should be unified into a single attribute of the
   `Orchestrator` class.  

   My suggestion is to use a `self.cycles` attribute in the
   `Orchestrator` class, which counts the number of cycles since the
   object was created: i.e., at the end of every cycle in
   `Orchestrator.run()`, the counter is incremented by 1.  Then the
   simulator can compute the "current time in the simulation" by
   `self.starting_time + self.cycles * self.interval`.

After this, it should be fairly clear what's going wrong with the time
handling.

Original issue reported on code.google.com by riccardo.murri@gmail.com on 16 Feb 2012 at 6:12

GoogleCodeExporter commented 9 years ago
On second thought, I think the output CSV file is not sorted on the
"submission time" column because the input is not.

Indeed, the input comes from the SGE accounting file (as translated by
`distil.py` or `awk`), but the SGE accounting is sorted on *end* time:
a record is written to the accounting file when a job *finishes*, not
when it is submitted.

Hence, the reordering according to the "submission time" column must
happen in `distil.py` or in `simul.py`; the latter probably makes the
simulator easier and more robust, at the cost of increased memory
usage. 

(Still, I'd like to see `assert`'s in the code to make this kind of
assumptions explicit...)

Original comment by riccardo.murri@gmail.com on 17 Feb 2012 at 9:06

GoogleCodeExporter commented 9 years ago
Riccardo, you've already fixed the ordering issue, right? lines: 108:118. 
About unifying time: self.cycle variable has been set in the orchestrator class 
and incremented at each iteration of the Orchestrator.run() method. Used for 
replacing time._step and self.time_step in the simulator class. 

Original comment by tyanko.a...@gmail.com on 21 Feb 2012 at 9:20