diff options
| author | mjkwiatkowski <mati.rewa@gmail.com> | 2026-06-27 16:37:00 +0200 |
|---|---|---|
| committer | mjkwiatkowski <mati.rewa@gmail.com> | 2026-06-27 16:37:00 +0200 |
| commit | 9bcc74a73393db0740c034191ed5125c0195f96e (patch) | |
| tree | 797720bde28efca7cbb5278b760fb491a1c7a02d /notes/meeting_19_06_2026.txt | |
| parent | 9b4a014a948eb0dbe0a2c1c78fbd5ffe2b915f3d (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.txt | 118 |
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. |
