1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
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.
|
