summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormjkwiatkowski <mati.rewa@gmail.com>2026-06-23 16:46:54 +0200
committermjkwiatkowski <mati.rewa@gmail.com>2026-06-23 16:46:54 +0200
commit9b4a014a948eb0dbe0a2c1c78fbd5ffe2b915f3d (patch)
treeb9a73dcfb82a2d05aae5fd28e0011a299253409d
parent5cc6a5e14abac655e938e686773cb85c8558b8b7 (diff)
feat: added experiment2
-rw-r--r--notes/meeting_19_06_2026.txt118
1 files changed, 118 insertions, 0 deletions
diff --git a/notes/meeting_19_06_2026.txt b/notes/meeting_19_06_2026.txt
new file mode 100644
index 0000000..cdd1838
--- /dev/null
+++ b/notes/meeting_19_06_2026.txt
@@ -0,0 +1,118 @@
+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.