diff options
| -rw-r--r-- | notes/meeting_19_06_2026.txt | 118 |
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. |