summaryrefslogtreecommitdiff
path: root/notes/meeting_19_06_2026.txt
diff options
context:
space:
mode:
authormjkwiatkowski <mati.rewa@gmail.com>2026-06-27 16:37:00 +0200
committermjkwiatkowski <mati.rewa@gmail.com>2026-06-27 16:37:00 +0200
commit9bcc74a73393db0740c034191ed5125c0195f96e (patch)
tree797720bde28efca7cbb5278b760fb491a1c7a02d /notes/meeting_19_06_2026.txt
parent9b4a014a948eb0dbe0a2c1c78fbd5ffe2b915f3d (diff)
fix: ordered the notes and removed the datasets dir
Diffstat (limited to 'notes/meeting_19_06_2026.txt')
-rw-r--r--notes/meeting_19_06_2026.txt118
1 files changed, 0 insertions, 118 deletions
diff --git a/notes/meeting_19_06_2026.txt b/notes/meeting_19_06_2026.txt
deleted file mode 100644
index cdd1838..0000000
--- a/notes/meeting_19_06_2026.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-You do not know which failure trace it is going on.
-Using my system we could utilize a model that.
-Make this a hypothetical setting.
-Make this very clear that its hypothetical.
-
-1) Make it clear why this experiment shows what we are doing?
-2) Why is this significant?
-3) Just need to show that this is NOT some trivial experiment because the setup is simple.
-
-4) Make the experiment not look fake based on the numbers that there are.
- -- This experiment shows that our system works; make the experiment look realistic.
-
-"If we had a model that could perfectly predict our system"
-
-Have a look at the ``Victim Selector''.
-Alter it somehow! Make this based on metric.
-Use some CPU or Host Age metric.
-The more tasks are running on a host the more likely it is to fail.
-
-``Host B has 20\% chance of failing''
-``Host C has 30\% chance of failing''
-
-Explain why these results are significant and why are they important.
-
-You have some model, and this can be based on multiple traces.
-Get insight from CINECA --> you get a probability of certain hosts failing.
-You run a simulation/multiple in the digital twin knowing which failures are going to happen.
-
-
-You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
-=====TO_DO====
-Run different ways of scheduling.
-I want to schedule these tasks, find me the best way to schedule them.
--> Send to the digital twin, the DT can run different scheduling algorithms.
-Run the same experiment with different random seeds. Run it 20 times, on average, this order of scheduling is the best.
-===========
-
-**Make the simulator run multiple failure traces and pick the most likely hosts to fail.**.
-
-Anomaly detection --> CINECA, how good their detection is?
-If you incorporate that? If you can make the case that because of our new digital twin we can incorporate such models, anomaly/failure detection, from CINECA.
-If we had that in, we can reach these kinds of gains.
-
-You can have some weights to each host: "What is the chance of this host failing?"
-Be careful with spending too much time on this.
-
-1) First: think about a way you want to explain this experiment.
-Couple this experiment with real world simulation -- how this connect to a real simulation that might happen in the future.
-What are the assumptions that I could make?
-I need to make the victim selector have some probability to select a victim.
-Explain why the experiment makes sense.
-Say in the future work: this is more of a proof of concept, there are some caveats.
-It is more important to work on the explain-ability.
-Why did we make certain design.
-
-
-CONSIDER SUPPORT VECTOR REGRESSION within VICTIM SELECTOR.
-
-2) Presentation:
-Add highlights --> to show you are going through the system in slide 7.
-
-DO THIS: Show a slide with a video showing the system is working.
-Make a video --> things are moving, there are communications, they are working.
-
-One slide briefly: what is this experiment, what is the setup why is it important.
-Add this slide before slide 7 --> show this experiment.
-
-Slide 7 -- why these requirements are not filled by the digital twins in the industry.
-Slide 8 -- show the video/pictures of some terminals: "We have a simulation running here, a Kafka broker running here".
-Show a video --> short but precise.
-Things being sent to each other.
-Slide 9 -- this is an example of what you could do.
-You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
-''There is a model designed to achieve certain requirements, we can show that it works, we can show that this is happening here.''
-
-There experiment is a result of WHAT YOU COULD DO.
-Then the precise numeric values are less important.
-Then this is OK to show that the setup is not fully realistic.
-
-FOR SURE HAVE AN INTRODUCTION WHERE YOU EXPLAIN THE EXPERIMENTS.
-SHOW THE SETUP IN A SLIDE.
-
-Slide 6 -- think how you are going to introduce this slide.
-Argument the `Digital Thread` well.
-All the sort of, orchestrator layer or managing layer which makes it so these 2 can work together is the Digital Thread.
-Say ``We introduce the Digital Thread'', if this is something you introduce, try to say "This is the important thing in the graph".
-
-Slide 7 --> make it named datacenter, NOT digital twin.
-DO datacenter (physical twin).
-You still establish the connection between the digital twin and the datacenter.
-
-Change KV Cache -- to Cache. Or Caching Subsystem.
-
-Make sure slides 6, 7 and new 8 are very strong.
-
-Make it very clear why we need this new model, model in slide 7.
-
-One of the original contributions -> the idea of introducing a way to evaluate digital twin architecture.
-
-The 3rd contribution is how you experiment.
-You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
-They way we test this, is by using multiple simulators.
-We use an additional simulator to run these experiments.
-
-Do NOT go above 10 slides.
-What you could do is say "this is my dt diagram" in slide 6 -- make this more abstract.
-Because we had this image (dt <-> dc) and circle <dc> and say "Many researchers do not have access to this".
-Instead we replace <dc> with a <simulator>.
-We do not have access to a cluster.
-
-Slides look OK.
-AtLarge style : what things we think are important to introduce in the slide.
-
-Figure 1.5 is too much text for a presentation.
-
-Be careful with not having too much text: too much text is too bad.
-
-Add animations at the end.