From 9bcc74a73393db0740c034191ed5125c0195f96e Mon Sep 17 00:00:00 2001 From: mjkwiatkowski Date: Sat, 27 Jun 2026 16:37:00 +0200 Subject: fix: ordered the notes and removed the datasets dir --- notes/03_06_2026.txt | 6 ++ notes/1.txt | 69 ------------ notes/10_06_2026.txt | 49 +++++++++ notes/11_05_2026.txt | 63 +++++++++++ notes/12_05_2026.txt | 32 ++++++ notes/13_05_2026.txt | 69 ++++++++++++ notes/16_06_2026.txt | 42 ++++++++ notes/17-06-2026-jd.txt | 55 ---------- notes/17_06_2026.txt | 59 +++++++++++ notes/19_06_2026.txt | 118 +++++++++++++++++++++ notes/2026-06-10-jd.txt | 49 --------- notes/20260513_133444.png | Bin 365862 -> 0 bytes notes/20260513_135756.png | Bin 371318 -> 0 bytes notes/20260513_140254.png | Bin 328776 -> 0 bytes notes/20260513_140457.png | Bin 142702 -> 0 bytes notes/23_06_2026.txt | 19 ++++ notes/24_06_2026.txt | 66 ++++++++++++ ...lides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf | Bin 2195066 -> 0 bytes notes/auto-scaling.txt | 43 -------- notes/dante.txt | 20 ---- notes/image (1).png | Bin 401512 -> 0 bytes notes/image (2).png | Bin 401512 -> 0 bytes notes/image.png | Bin 626586 -> 0 bytes notes/meetin2.txt | 6 -- notes/meeting.txt | 42 -------- notes/meeting_19_06_2026.txt | 118 --------------------- notes/notes.txt | 32 ------ notes/screenshots/common_pitfalls.png | Bin 0 -> 328776 bytes notes/screenshots/good_figure_from_dante.png | Bin 0 -> 401512 bytes notes/screenshots/good_figure_from_dante_2.png | Bin 0 -> 626586 bytes notes/screenshots/introduction_timeline.png | Bin 0 -> 365862 bytes notes/screenshots/map_of_thesis.png | Bin 0 -> 371318 bytes notes/vu_thesis_template_advice.pdf | Bin 384126 -> 0 bytes 33 files changed, 523 insertions(+), 434 deletions(-) create mode 100644 notes/03_06_2026.txt delete mode 100644 notes/1.txt create mode 100644 notes/10_06_2026.txt create mode 100644 notes/11_05_2026.txt create mode 100644 notes/12_05_2026.txt create mode 100644 notes/13_05_2026.txt create mode 100644 notes/16_06_2026.txt delete mode 100644 notes/17-06-2026-jd.txt create mode 100644 notes/17_06_2026.txt create mode 100644 notes/19_06_2026.txt delete mode 100644 notes/2026-06-10-jd.txt delete mode 100644 notes/20260513_133444.png delete mode 100644 notes/20260513_135756.png delete mode 100644 notes/20260513_140254.png delete mode 100644 notes/20260513_140457.png create mode 100644 notes/23_06_2026.txt create mode 100644 notes/24_06_2026.txt delete mode 100644 notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf delete mode 100644 notes/auto-scaling.txt delete mode 100644 notes/dante.txt delete mode 100644 notes/image (1).png delete mode 100644 notes/image (2).png delete mode 100644 notes/image.png delete mode 100644 notes/meetin2.txt delete mode 100644 notes/meeting.txt delete mode 100644 notes/meeting_19_06_2026.txt delete mode 100644 notes/notes.txt create mode 100644 notes/screenshots/common_pitfalls.png create mode 100644 notes/screenshots/good_figure_from_dante.png create mode 100644 notes/screenshots/good_figure_from_dante_2.png create mode 100644 notes/screenshots/introduction_timeline.png create mode 100644 notes/screenshots/map_of_thesis.png delete mode 100644 notes/vu_thesis_template_advice.pdf (limited to 'notes') diff --git a/notes/03_06_2026.txt b/notes/03_06_2026.txt new file mode 100644 index 0000000..6ed2515 --- /dev/null +++ b/notes/03_06_2026.txt @@ -0,0 +1,6 @@ +Servo paper: this is the kind of system model you have to do. +A reference architecture. +The design is more specific than the reference architecture. +The contribution of RQ1 should be a system model. +The abstraction level goes: system model/reference architecture -> system design -> prototype implementation +There is also taxonomy: Procedural Content Generation for Games -> taxonomy of different types of content. diff --git a/notes/1.txt b/notes/1.txt deleted file mode 100644 index 4a11803..0000000 --- a/notes/1.txt +++ /dev/null @@ -1,69 +0,0 @@ -==13-05-2026== -Introduction: -Make a compelling story about what the adventure is upon you and what problem you set out to solve. -You can think of it as a classical novel. -Make a protagonist; there is a protagonist, he encounters and issue and overcomes it. -Except it's just more technical. - -Status update template: -Since last meeting, I changed ___ in the thesis text. -I changed ___ in the artifact / experiments. -My next concrete deliverable is ___. -My main blocker is ___. - -Try to find good references in the CompSys manifesto. -This should contain ``good'' references. -Paralysis analysis. -You should write your thesis at the same time as your coding. -DO NOT leave out the thesis as the last part, after all coding is done. -Do both in parallel. - -The `gap` in the presentation slides is `...and this has not yet been done before.` or `we are the first to do...` etc. -`Gap` => nobody did this before (or a knowledge gap). -E.g., a system does not exist. The key is that it is missing worldwide from the scientific community. -Nobody has done yet => part of a `scientific` project. -Why is my project scientific? Because nobody did it yet. - -How to backup that something does not exist? -You cannot cite work that does not exist. -You cannot cite non existing thing, because it's not there. -Typically, you show instead how existing falls short. -1/ State the problem, why it's important. -2/ Refer to recent and impactful work on datacenter simulation or digital twinning. -2a/ Write in a few sentences that this other work did `xyz` and say why `xyz` is NOT ENOUGH to advance the problem you introduce earlier. -You can just say that `this is missing from their work, or I think that this is missing`. -Now YOU need to make a claim, `this is true`, or `nobody did this`. -Making such a claim is bold and YOU could be wrong, but STILL make that claim, but then cite the related work, make the claim `they don't do x`, and then go to your supervisor and tell him `in my mind this is the key issue with my thesis, do you agree with this? Is there any work I Should have cited? Am I misinterpreting anything those other projects did?`Bring this up with a conversation with your supervisor. - -Answer to each research questions is one of your main contributions. -They are the main way the reader can understand what you have done. -System design => contribution to question on ``How to design a ...?'' -Each contribution => a section in your thesis. Core content of the thesis. 3-4 sections. -Each section corresponds directly to a research question. - -Make a skeleton of the thesis first. Very important! -This way you can plan your own work much better => do this. -Map the thesis before writing text. -Put the skeleton in the shared folder. - -Each RQ should be enumerated, you want every question to be not just a nice isolated question,but add a bit of context below: 1) describe why it's important 2) say why it's challenging 3) say what makes it scientific. - -You can take whatever structure you want from any report, no plagiarism nor declarations needed. - -==20-05-2026== -You should explain in your background section background on datacenters and datacenter simulations. -The background is NOT an extensive discussion of extensive and related work. It is NOT that. -It gives the necessary context for the rest of the thesis. - -You can include a figure in the introduction from a different paper. -You can adapt it from a different paper. -Do not copy figures directly. - -Background: -a) Concept A -b) Concept B -c) Merge A + B, why we need both - -2.1 Datacenter -Part of 2.1, or separate as 2.2 if large: Failures -Part 2.2/2.3 Digital Twins diff --git a/notes/10_06_2026.txt b/notes/10_06_2026.txt new file mode 100644 index 0000000..f058da1 --- /dev/null +++ b/notes/10_06_2026.txt @@ -0,0 +1,49 @@ +Jesse -- Latex slides are OK! +1 slides is 1 to 2 minutes - 5 to 10 slides can work. +Slide 4: mention the contributions; In the thesis we answer these RQs, for time limitation, we only focus on RQs 1 and 2. For RQ we do a design and then you can ask me about this after the presentation. +You can skip explaining a RQ. +Skip material instead of cramming material. +As you know and as you've seen in the previous presentations today. + +**Mention societal impact at least verbally. In slide 2.** +Avoid audience members thinking ``he forgot that''. +If you are skipping something -- at least mention that you are skipping it. +Or that there is an extra slide explaining this. + +Before slide 4, the audience must know what predictive analytics is and why is it important to have. +In the `Problem Statement` slide, say `What is predictive analytics`, `Why is it crucial`. +Key for you to explain `What is predictive analytics?` + +Digital Twins -- a lot of elements are shifting about, there are a lot of ways to model these things, and there seems to not be a fully functioning digital twin out there. +There does not exist a system that contains the entire feedback loop. +1) Digital Twins are NOT DONE -- they are actively being developed. +2) Part of being developed is they lack crucial features, e.g., predictive analytics +3) Predictive analytics is this and that... +4) This is important because ... + +You may have to remove the table. + +Slide 2 -- the idea of complex / extremely complex is too bad. +The idea might be a bit too high -- throw in some numbers, the scale of modern datacenters. +Put in some number of different number CPU's, or focus on the number of PETAFLOPS (compute steps per second). + +Change the narrative from Moore's law to something else. +Focus more on the fact that the infrastructure is incredibly large. +DO NOT SHOW THE DENNARD's scaling graph. + +``A single CPU is very complex. (Show ARM Architecture of APPLE MAC) Look, in that something there is this bigger thing, and there is this and there is this bigger thing, and how are we going to simulate this big datacenter, that has so many __layers of complexity__``. A single ARM Architecture Image -- ``This is a complex object''. +In datacenters, there are hundreds of thousands of them. +How do we manage this?'' + +Connect motivation to problem statement via societal context. +``We cannot let these systems go down, we CANNOT Experience failures, we cannot experience performance related issues`'' and that bridges to the need of digital twins to be better able to detect and solve issues in this critical infrastructure. +And that also bridges nicely to predictive analytics. +``What if we can solve problems before they actually occur?`` + +You have to be able to explain something well on a graph with dc <-> dt. +Give a strong motivation for predictive analytics. +Give a strong motivation for failures, or that Digital Twins are just IoT sensors without Digital Twinning. + +Slide 4 add animations to show the research questions. +``Take home message'' instead of Discussion. +Add animations -- to the system model for things appearing. diff --git a/notes/11_05_2026.txt b/notes/11_05_2026.txt new file mode 100644 index 0000000..6a74ff9 --- /dev/null +++ b/notes/11_05_2026.txt @@ -0,0 +1,63 @@ +==AutoScaling== +To get it to run --? look at how failures are implemented. +The moment your pool of usable hosts becomes too tight then you activate new ones. +1) I want to implement which allows me to put hosts inactive and activate it again. +2) During the workload the operator should be able to close and open the workloads. +i) then you build a policy as to when you activate new hosts and when you want to stop hosts. +ii) have many policies to do this +iii) add booting time --> cold start. A host becomes available but it takes still more time to make it workable because you need to boot everything. +iv) cold starts use zero power or very minimal --> idle power of a node that is turned off. Inactive have minimal power draw, but the downsides is that nodes may not be available immediately. +Inactive takes more time to boot e.g., 5 minutes. +The more you can predict how many nodes you will need to more you can save power without impacting the performance. + +The bachelor focus -- the primary focus should be on the design of the digital twin. +Be careful that you do not make implementing the main topic of the bachelor thesis. +The main topic should still be digital twinning. + +The digital twin is activated in 2 ways: either the operators prompt the digital twin when they run a workload or the digital twin sends a notification to the datacenter. + +IBM Dublin := you have metrics being managed and policies can decide to do actions. +And these actions can be many different things. +Currently does not matter what it would -- this could be auto-scaling, scheduling, routing. +What is the difference between routing and scheduling? + +Great success == we do not include AI inference in the bachelor thesis! +Policy decisions can be made using different heuristics --> AI inference. +Do not work too much on the policies. + +The focus of the thesis is the digital twinning part. + +Autoscaling vs. failures vs. scheduling. +MVP soon. + +Why can't we port a digital twin from other domains? +Show that a digital twin can react. + +Show the readers what would the perfect experiment look like in the perfect. + +What a digital twin is --> give the answer in the background somehow. +What do you think a digital twin is? Make it clear. +Why is a specific datacenter digital twin different from what there already is. + +Versen Thesis Awards they are promoted at ICTO today and tomorrow. + +Create a model in draw.io +Look at OpenTelemetry (read up - is this a lot of work?) +https://github.com/atlarge-research/opendc/tree/radice-paper +Make sure you the fields you specify in the schema itself are automatically exported. +Measure Kafka latency of exporting. +Also ensure whether the user wants to export to database or not. +Add multiple export functions. +Make sure specify the config files in the command line. +The prediction should be about auto-scaling. +BUT -> there is no auto-scaling. +Do auto-scaling. +Idle power takes a lot of energy. +Predicting when to turn nodes on and off would be nice. +Datacenters are heavily underutilized. +Predict when to turn the hosts on and when to turn them off. +Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. +With auto-scaling you can do it a bit smarter or not. +Do auto-scaling in OpenDC. +Rescheduling. + diff --git a/notes/12_05_2026.txt b/notes/12_05_2026.txt new file mode 100644 index 0000000..d5394cf --- /dev/null +++ b/notes/12_05_2026.txt @@ -0,0 +1,32 @@ +The presentation is in practice 30% of grade. +The actual grading goes on during the presentation. +Alex will only ask questions during the presentation. +You are getting a proof from the university that you are going to graduate. +The moment you get the information that your thesis went right, you get the document from the university saying that you are going to graduate. + +Alex assumes that you are going to do an 18EC honors project. +Text Alex again often. +You do a continuation of the bachelor thesis as an honors project. +Ana did spatial shifting as an honours thesis, and then on top of that she combined spatial and temporal shifting on top of her bachelor thesis. + +Dante's vision on the structure: +1. Introduction, background -- do a literature survey. + * you should add besides the model of digital twinning. +2. Design, how do you design +3. Experiments, + * add the methodology of running experiments. + * using the Datacenter simulator as a "real" Datacenter is in itself is a really interesting. +4. For a normal bachelor thesis you show the effect -- the failures. +5. Digital twin scheduling vs. Scheduling. +--BACHELOR thesis ends here-- +--HP Project here-- +Here we do the same thing with failures AND auto-scaling. +We add auto-scaling as the extra component. +We are looking at how this component interacts with all the other components. +Not just only an experiment but a bit more of an extra layer. +-- HP project adding -- +Adding an extra layer of complexity and check how it acts together with the rest of the systems. + +Write down: these are the base things we want to do for sure, and then make a list of things we'd like the extra's. +A use case can be specific metrics you want to measure or actions you want to take (akin to auto-scaling). + diff --git a/notes/13_05_2026.txt b/notes/13_05_2026.txt new file mode 100644 index 0000000..4a11803 --- /dev/null +++ b/notes/13_05_2026.txt @@ -0,0 +1,69 @@ +==13-05-2026== +Introduction: +Make a compelling story about what the adventure is upon you and what problem you set out to solve. +You can think of it as a classical novel. +Make a protagonist; there is a protagonist, he encounters and issue and overcomes it. +Except it's just more technical. + +Status update template: +Since last meeting, I changed ___ in the thesis text. +I changed ___ in the artifact / experiments. +My next concrete deliverable is ___. +My main blocker is ___. + +Try to find good references in the CompSys manifesto. +This should contain ``good'' references. +Paralysis analysis. +You should write your thesis at the same time as your coding. +DO NOT leave out the thesis as the last part, after all coding is done. +Do both in parallel. + +The `gap` in the presentation slides is `...and this has not yet been done before.` or `we are the first to do...` etc. +`Gap` => nobody did this before (or a knowledge gap). +E.g., a system does not exist. The key is that it is missing worldwide from the scientific community. +Nobody has done yet => part of a `scientific` project. +Why is my project scientific? Because nobody did it yet. + +How to backup that something does not exist? +You cannot cite work that does not exist. +You cannot cite non existing thing, because it's not there. +Typically, you show instead how existing falls short. +1/ State the problem, why it's important. +2/ Refer to recent and impactful work on datacenter simulation or digital twinning. +2a/ Write in a few sentences that this other work did `xyz` and say why `xyz` is NOT ENOUGH to advance the problem you introduce earlier. +You can just say that `this is missing from their work, or I think that this is missing`. +Now YOU need to make a claim, `this is true`, or `nobody did this`. +Making such a claim is bold and YOU could be wrong, but STILL make that claim, but then cite the related work, make the claim `they don't do x`, and then go to your supervisor and tell him `in my mind this is the key issue with my thesis, do you agree with this? Is there any work I Should have cited? Am I misinterpreting anything those other projects did?`Bring this up with a conversation with your supervisor. + +Answer to each research questions is one of your main contributions. +They are the main way the reader can understand what you have done. +System design => contribution to question on ``How to design a ...?'' +Each contribution => a section in your thesis. Core content of the thesis. 3-4 sections. +Each section corresponds directly to a research question. + +Make a skeleton of the thesis first. Very important! +This way you can plan your own work much better => do this. +Map the thesis before writing text. +Put the skeleton in the shared folder. + +Each RQ should be enumerated, you want every question to be not just a nice isolated question,but add a bit of context below: 1) describe why it's important 2) say why it's challenging 3) say what makes it scientific. + +You can take whatever structure you want from any report, no plagiarism nor declarations needed. + +==20-05-2026== +You should explain in your background section background on datacenters and datacenter simulations. +The background is NOT an extensive discussion of extensive and related work. It is NOT that. +It gives the necessary context for the rest of the thesis. + +You can include a figure in the introduction from a different paper. +You can adapt it from a different paper. +Do not copy figures directly. + +Background: +a) Concept A +b) Concept B +c) Merge A + B, why we need both + +2.1 Datacenter +Part of 2.1, or separate as 2.2 if large: Failures +Part 2.2/2.3 Digital Twins diff --git a/notes/16_06_2026.txt b/notes/16_06_2026.txt new file mode 100644 index 0000000..788ca85 --- /dev/null +++ b/notes/16_06_2026.txt @@ -0,0 +1,42 @@ +Find experiments or standard operation that might utilize simulation a bit is not enough. +Look at the idea of cascading failures. +A single failure can propagate. +It makes it difficult simulate to completely. + +Why is it difficult with failures to use naive simulation. +And then your thesis proposal is that a digital twin would help out these failures. + +The use case that you are specifically looking at is failures. +Then of course you need to introduce failures. +You are not focusing enough on digital twinning. +You should focus more on this than predictive analytics. +Digital twinning is the key -- argumentation and whatnot, not yet faults or predictive analysis. + +Opendc-web-server. +All the interesting endpoints are defined in `rests/resources` +Do not use Javalin, use Quarkus, because we use Quarkus in the web module. +To find the documentation and find the web module, find `localhost:8080/q/dev-ui/extensions` or `localhost:8080/q/dev`. + +The API models the API everything can do. +We need to bridge the experiment runner to the API. +Some small fixes to the API have to be done. +The API has some schemas defined in the schemas. + +Read the documentation of quarkus to add your own endpoints. +Here add your endpoints `opendc-web/opendc-web-server/src/main/java/org/opendc/web/server/rest` +What gets stored in the databse: +- aggregate results are stored there. +- detailed results are in the development tree (the thing that you did with PostgreSQL). +Have a look at the website graphs of OpenDC. + +Failure traces are needed to demonstrate failures. + +Have a look at Jure's experiments and the cost impact of failures as this might be nice to show in your own work. +Failures tap well into what he is doing. +The degradation model of CPU. +Shows how much money is being lost due to failures. + +Daniel cannot model some experiments in the web module. +He would not get results. +There are two different runners for the web module that are different from the generic `ExperimentRunner`. + diff --git a/notes/17-06-2026-jd.txt b/notes/17-06-2026-jd.txt deleted file mode 100644 index dc2c9f0..0000000 --- a/notes/17-06-2026-jd.txt +++ /dev/null @@ -1,55 +0,0 @@ -==Presentation__Meeting== -1) Use the recipe. -If you deviate from that, then what it's at your own risk. -Hard limit on the number of slides is 10. -Each slide is 1-2 minutes. -You can have between 5-10 slides. ->10 slides -> very good change you won't have the time to talk about what's on the slides. -You _can_ have extra slides. -The QnA is the questions by everybody in the room. -You can also ask questions/should ask questions. -The last couple of minutes the _supervisors_ ask questions. - -2) Make sure your slides are numbered. -First slide has to have the title plus your name. -The slides can be posted online, so the first slide might be the business card. -You can use the first slide for a little bit more than just title -- add an _abstract_. -Add a short text. -"At a top level, my project is ..." -Have a bit of an introduction on the very first slide. - -3) The second slide: this is societal context of your work. -How does this work affect society at large? - -4) After comes the problem statement OR the research question. -You can KEEP the problem statement. -You can also show the contributions. - -5) Design to present --> USE Animations to make things appear one by one. -A lot of material all at once is BAD. -Make colored boxes appear one by one in the order you talk about them. -OR include red highlight boxes. -If you look at the component in the red boxes --> steer the attention in the audience, if you want to show something that has so many components as something like Ana Maria's slide 5. - -Focus on the most _innovative_ part of the design. -Design has a lot of elements --> focus on what made _this_ design special. -Focus on the most interesting thing that you have added. - -Show what is important, highlight some boxes, tell them the `cool stuff of the thesis.` - -6) It's not given which contributions are worth more and which aren't. -At the level of the bachelor, it is typically easiest to make an impression with the experiments. -The design and implementation are unlikely the most groundbreaking part of the thesis. -Most bachelor thesis are experiment heavy, so most presentations are experiment heavy. - -7) Are we given a clicker or do we plug in our own laptop? -We are plugging in our own laptop. - -8) Replicate a result from a previous study to show that the system works. -Replicate an experiment!!!!!! -You can show this to the audience to show you can demonstrate your capability in the presentation. - -9) Jesse strongly recommends: there should be something you are really excited about. -Whatevery you found the most enjoyable or challenging --> try to incorporate this in the presentation. -"Now we go to my favourite part". -"Now we go to the most difficult part, and I am really proud I can show you these experimental results today" diff --git a/notes/17_06_2026.txt b/notes/17_06_2026.txt new file mode 100644 index 0000000..1f2423d --- /dev/null +++ b/notes/17_06_2026.txt @@ -0,0 +1,59 @@ +==Presentation__Meeting== +1) Use the recipe. +If you deviate from that, then what it's at your own risk. +Hard limit on the number of slides is 10. +Each slide is 1-2 minutes. +You can have between 5-10 slides. +>10 slides -> very good change you won't have the time to talk about what's on the slides. +You _can_ have extra slides. +The QnA is the questions by everybody in the room. +You can also ask questions/should ask questions. +The last couple of minutes the _supervisors_ ask questions. + +2) Make sure your slides are numbered. +First slide has to have the title plus your name. +The slides can be posted online, so the first slide might be the business card. +You can use the first slide for a little bit more than just title -- add an _abstract_. +Add a short text. +"At a top level, my project is ..." +Have a bit of an introduction on the very first slide. + +3) The second slide: this is societal context of your work. +How does this work affect society at large? + +4) After comes the problem statement OR the research question. +You can KEEP the problem statement.We used +AIP, DBLP, and Google Scholar as the main +digital libraries for querying the literature +sources, amongst which Google Scholar re- +ferred to +You can also show the contributions. + +5) Design to present --> USE Animations to make things appear one by one. +A lot of material all at once is BAD. +Make colored boxes appear one by one in the order you talk about them. +OR include red highlight boxes. +If you look at the component in the red boxes --> steer the attention in the audience, if you want to show something that has so many components as something like Ana Maria's slide 5. + +Focus on the most _innovative_ part of the design. +Design has a lot of elements --> focus on what made _this_ design special. +Focus on the most interesting thing that you have added. + +Show what is important, highlight some boxes, tell them the `cool stuff of the thesis.` + +6) It's not given which contributions are worth more and which aren't. +At the level of the bachelor, it is typically easiest to make an impression with the experiments. +The design and implementation are unlikely the most groundbreaking part of the thesis. +Most bachelor thesis are experiment heavy, so most presentations are experiment heavy. + +7) Are we given a clicker or do we plug in our own laptop? +We are plugging in our own laptop. + +8) Replicate a result from a previous study to show that the system works. +Replicate an experiment!!!!!! +You can show this to the audience to show you can demonstrate your capability in the presentation. + +9) Jesse strongly recommends: there should be something you are really excited about. +Whatevery you found the most enjoyable or challenging --> try to incorporate this in the presentation. +"Now we go to my favourite part". +"Now we go to the most difficult part, and I am really proud I can show you these experimental results today" diff --git a/notes/19_06_2026.txt b/notes/19_06_2026.txt new file mode 100644 index 0000000..cdd1838 --- /dev/null +++ b/notes/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 and say "Many researchers do not have access to this". +Instead we replace with a . +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. diff --git a/notes/2026-06-10-jd.txt b/notes/2026-06-10-jd.txt deleted file mode 100644 index f058da1..0000000 --- a/notes/2026-06-10-jd.txt +++ /dev/null @@ -1,49 +0,0 @@ -Jesse -- Latex slides are OK! -1 slides is 1 to 2 minutes - 5 to 10 slides can work. -Slide 4: mention the contributions; In the thesis we answer these RQs, for time limitation, we only focus on RQs 1 and 2. For RQ we do a design and then you can ask me about this after the presentation. -You can skip explaining a RQ. -Skip material instead of cramming material. -As you know and as you've seen in the previous presentations today. - -**Mention societal impact at least verbally. In slide 2.** -Avoid audience members thinking ``he forgot that''. -If you are skipping something -- at least mention that you are skipping it. -Or that there is an extra slide explaining this. - -Before slide 4, the audience must know what predictive analytics is and why is it important to have. -In the `Problem Statement` slide, say `What is predictive analytics`, `Why is it crucial`. -Key for you to explain `What is predictive analytics?` - -Digital Twins -- a lot of elements are shifting about, there are a lot of ways to model these things, and there seems to not be a fully functioning digital twin out there. -There does not exist a system that contains the entire feedback loop. -1) Digital Twins are NOT DONE -- they are actively being developed. -2) Part of being developed is they lack crucial features, e.g., predictive analytics -3) Predictive analytics is this and that... -4) This is important because ... - -You may have to remove the table. - -Slide 2 -- the idea of complex / extremely complex is too bad. -The idea might be a bit too high -- throw in some numbers, the scale of modern datacenters. -Put in some number of different number CPU's, or focus on the number of PETAFLOPS (compute steps per second). - -Change the narrative from Moore's law to something else. -Focus more on the fact that the infrastructure is incredibly large. -DO NOT SHOW THE DENNARD's scaling graph. - -``A single CPU is very complex. (Show ARM Architecture of APPLE MAC) Look, in that something there is this bigger thing, and there is this and there is this bigger thing, and how are we going to simulate this big datacenter, that has so many __layers of complexity__``. A single ARM Architecture Image -- ``This is a complex object''. -In datacenters, there are hundreds of thousands of them. -How do we manage this?'' - -Connect motivation to problem statement via societal context. -``We cannot let these systems go down, we CANNOT Experience failures, we cannot experience performance related issues`'' and that bridges to the need of digital twins to be better able to detect and solve issues in this critical infrastructure. -And that also bridges nicely to predictive analytics. -``What if we can solve problems before they actually occur?`` - -You have to be able to explain something well on a graph with dc <-> dt. -Give a strong motivation for predictive analytics. -Give a strong motivation for failures, or that Digital Twins are just IoT sensors without Digital Twinning. - -Slide 4 add animations to show the research questions. -``Take home message'' instead of Discussion. -Add animations -- to the system model for things appearing. diff --git a/notes/20260513_133444.png b/notes/20260513_133444.png deleted file mode 100644 index ed2124d..0000000 Binary files a/notes/20260513_133444.png and /dev/null differ diff --git a/notes/20260513_135756.png b/notes/20260513_135756.png deleted file mode 100644 index a0729d8..0000000 Binary files a/notes/20260513_135756.png and /dev/null differ diff --git a/notes/20260513_140254.png b/notes/20260513_140254.png deleted file mode 100644 index 3ebc53a..0000000 Binary files a/notes/20260513_140254.png and /dev/null differ diff --git a/notes/20260513_140457.png b/notes/20260513_140457.png deleted file mode 100644 index 15f29c1..0000000 Binary files a/notes/20260513_140457.png and /dev/null differ diff --git a/notes/23_06_2026.txt b/notes/23_06_2026.txt new file mode 100644 index 0000000..b5b8075 --- /dev/null +++ b/notes/23_06_2026.txt @@ -0,0 +1,19 @@ +Try to make the demo after slide 7 so that it shows Kafka and Postgres receive data from the real datacenter. +Just to show things are connected. +Consider showing the experiment with alarms live. +Figure 1.5 is fine. +Change the caption to figure 1.5, it cannot be just another text-box i.e., make it _less_ informative overall. +Caption 1.5 -> visualisation of the digital twin. +Currently the caption 1.5 is NOT the description of the figure. +TODO("Change caption 1.5. Captions should be shorter, figure descriptions should be in captions, at most one line description if you _really_ want to have it in the caption.") + +Make the "Solution - use a 2nd simulator" green instead. +Change the "how did you solve the problem" into green. +Keep the upper cloud ("the problem") red. + +Align figure 1.5 better --> do not make the lower part of the figure moved to the left. +Change the figure 1.5 so that it is aligned vertically. + +In your figure it is not clear that what you see on the top is the problem. +The second thing is too similar to the first thing in the figure. +If you align that perfectly (the first thing and the second thing), align everything, AND you add some clear some arrow, it becomes more clear that "this is an implementation of that". diff --git a/notes/24_06_2026.txt b/notes/24_06_2026.txt new file mode 100644 index 0000000..8bede01 --- /dev/null +++ b/notes/24_06_2026.txt @@ -0,0 +1,66 @@ +==__== +Typically atLarge is a bit more lenient when it comes to deadlines. +You can submit your thesis until 15 of July by the faculty, but by atLarge you can submit it even later. +Make sure you tell your supervisor when you plan to hand in your thesis. + +For the findings and the experiment section really try to follow the format that we have tried to teach you: +1) Show what the main findings are +2) Show the main setup +3) Have multiple plots or tables to show your finding + +Recipe to explain experiments: +How to evaluate something? +Real world setting, simulation, mathematical analysis etc. +Argue that --> "We do simulation based experiments". +For experimental approach -- checklist: +1) Workload --> I should explain what I run on my system and why that makes sense. +You have a simulator run something, or you will inject failures, or you will expose the system to something. +Is it realistic to expose the system to this workload? +Does it make sense? + +2) Environment --> For a simulator: on what machine do you run the simulator, does it make sense to run this kind of experiment on the machine. + +3) (System-under-test) -> How did you configure OpenDC? What settings did you configured to run it? How did you configure redis? +How did you configure the Kafka filters? Why does these settings make sense? + +4) Metrics --> why are you measuring these metrics? Why does this make sense? +Why are the metrics representative. + +If the experiment setup is standard --> you can skip over it. +You can say that you did a look through the literature about the kinds of use-cases your work can be beneficial for. +One of the use-cases is an experiment that this related work, (DyTwin) did. +Through my work I designed and Implemented this to be something that you can experiment with easily instead, not one-off. +DyTwin was a one-off system. My system allows experimentation like this much more convenient, and NOT one-off. +DyTwin was one-off system, now using our system can do this much more easily and not one-off. +We IMPROVE on the work of DyTwin. + +We replicate their experiment, we get practically the same results, that validates THEIR work and YOUR OWN work.COMPARE on the same slide THEIR results, and OUR results. + +A lot of questions will be about the soundness of your approach. +There will NOT be a lot of questions about the technical details. +The more senior people in the room will ask more questions about the methodological approach. +You DESIGN-ed a system: "what method did you follow for system design?" +"Why did you choose that method? How did you follow it?" +"How do you argue that you answers for research questions are good?" +"Are your research questions good? Why are they good? Why do they align with the rest of the thesis?" +"Argue why your research questions are challenging, why are they scientific?" + +Approach, research questions, methodology, the analysis of experiments. +Frequent experiment analysis questions: "Why just the mean?" "Is there performance variability?" "Do you always get the same results?" "What can we learn if we look at the distribution?" "How many times did you repeat your experiments?" "What is the standard deviation?" + +SHOW IN YOUR ANSWERS YOU HAVE A JUSTIFICATION FOR THESE QUESTIONS. +Explain that you have though about things. + +If you do not know the answer say: "Let me speculate..." +Indicate honestly that you do not know, and then try to answer. + +As a presenter: be there just that day. +Ask questions during other presentations. +Support your team. +Be there for the entire day or your slot perhaps. +The rest of the day is appreciated, the entire slot is mandatory. +Agree with the supervisor whether you passed or failed the presentation. +It never happened that we let someone present and THEN fail. +Usually they tell them that they have to do on more or two more things. +Once you have some answer to your research questions, it is heavily unlikely you will fail. + diff --git a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf b/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf deleted file mode 100644 index 4e51e3d..0000000 Binary files a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf and /dev/null differ diff --git a/notes/auto-scaling.txt b/notes/auto-scaling.txt deleted file mode 100644 index a6b009f..0000000 --- a/notes/auto-scaling.txt +++ /dev/null @@ -1,43 +0,0 @@ -==AutoScaling== -To get it to run --? look at how failures are implemented. -The moment your pool of usable hosts becomes too tight then you activate new ones. -1) I want to implement which allows me to put hosts inactive and activate it again. -2) During the workload the operator should be able to close and open the workloads. -i) then you build a policy as to when you activate new hosts and when you want to stop hosts. -ii) have many policies to do this -iii) add booting time --> cold start. A host becomes available but it takes still more time to make it workable because you need to boot everything. -iv) cold starts use zero power or very minimal --> idle power of a node that is turned off. Inactive have minimal power draw, but the downsides is that nodes may not be available immediately. -Inactive takes more time to boot e.g., 5 minutes. -The more you can predict how many nodes you will need to more you can save power without impacting the performance. - -The bachelor focus -- the primary focus should be on the design of the digital twin. -Be careful that you do not make implementing the main topic of the bachelor thesis. -The main topic should still be digital twinning. - -The digital twin is activated in 2 ways: either the operators prompt the digital twin when they run a workload or the digital twin sends a notification to the datacenter. - -IBM Dublin := you have metrics being managed and policies can decide to do actions. -And these actions can be many different things. -Currently does not matter what it would -- this could be auto-scaling, scheduling, routing. -What is the difference between routing and scheduling? - -Great success == we do not include AI inference in the bachelor thesis! -Policy decisions can be made using different heuristics --> AI inference. -Do not work too much on the policies. - -The focus of the thesis is the digital twinning part. - -Autoscaling vs. failures vs. scheduling. -MVP soon. - -Why can't we port a digital twin from other domains? -Show that a digital twin can react. - -Show the readers what would the perfect experiment look like in the perfect. - -What a digital twin is --> give the answer in the background somehow. -What do you think a digital twin is? Make it clear. -Why is a specific datacenter digital twin different from what there already is. - -Versen Thesis Awards they are promoted at ICTO today and tomorrow. - diff --git a/notes/dante.txt b/notes/dante.txt deleted file mode 100644 index 6c55eb3..0000000 --- a/notes/dante.txt +++ /dev/null @@ -1,20 +0,0 @@ -Create a model in draw.io -Look at OpenTelemetry (read up - is this a lot of work?) -https://github.com/atlarge-research/opendc/tree/radice-paper -Make sure you the fields you specify in the schema itself are automatically exported. -Measure Kafka latency of exporting. -Also ensure whether the user wants to export to database or not. -Add multiple export functions. -Make sure specify the config files in the command line. -The prediction should be about auto-scaling. -BUT -> there is no auto-scaling. -Do auto-scaling. -Idle power takes a lot of energy. -Predicting when to turn nodes on and off would be nice. -Datacenters are heavily underutilized. -Predict when to turn the hosts on and when to turn them off. -Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. -With auto-scaling you can do it a bit smarter or not. -Do auto-scaling in OpenDC. -Rescheduling. - diff --git a/notes/image (1).png b/notes/image (1).png deleted file mode 100644 index be41833..0000000 Binary files a/notes/image (1).png and /dev/null differ diff --git a/notes/image (2).png b/notes/image (2).png deleted file mode 100644 index be41833..0000000 Binary files a/notes/image (2).png and /dev/null differ diff --git a/notes/image.png b/notes/image.png deleted file mode 100644 index 09c7043..0000000 Binary files a/notes/image.png and /dev/null differ diff --git a/notes/meetin2.txt b/notes/meetin2.txt deleted file mode 100644 index 6ed2515..0000000 --- a/notes/meetin2.txt +++ /dev/null @@ -1,6 +0,0 @@ -Servo paper: this is the kind of system model you have to do. -A reference architecture. -The design is more specific than the reference architecture. -The contribution of RQ1 should be a system model. -The abstraction level goes: system model/reference architecture -> system design -> prototype implementation -There is also taxonomy: Procedural Content Generation for Games -> taxonomy of different types of content. diff --git a/notes/meeting.txt b/notes/meeting.txt deleted file mode 100644 index 788ca85..0000000 --- a/notes/meeting.txt +++ /dev/null @@ -1,42 +0,0 @@ -Find experiments or standard operation that might utilize simulation a bit is not enough. -Look at the idea of cascading failures. -A single failure can propagate. -It makes it difficult simulate to completely. - -Why is it difficult with failures to use naive simulation. -And then your thesis proposal is that a digital twin would help out these failures. - -The use case that you are specifically looking at is failures. -Then of course you need to introduce failures. -You are not focusing enough on digital twinning. -You should focus more on this than predictive analytics. -Digital twinning is the key -- argumentation and whatnot, not yet faults or predictive analysis. - -Opendc-web-server. -All the interesting endpoints are defined in `rests/resources` -Do not use Javalin, use Quarkus, because we use Quarkus in the web module. -To find the documentation and find the web module, find `localhost:8080/q/dev-ui/extensions` or `localhost:8080/q/dev`. - -The API models the API everything can do. -We need to bridge the experiment runner to the API. -Some small fixes to the API have to be done. -The API has some schemas defined in the schemas. - -Read the documentation of quarkus to add your own endpoints. -Here add your endpoints `opendc-web/opendc-web-server/src/main/java/org/opendc/web/server/rest` -What gets stored in the databse: -- aggregate results are stored there. -- detailed results are in the development tree (the thing that you did with PostgreSQL). -Have a look at the website graphs of OpenDC. - -Failure traces are needed to demonstrate failures. - -Have a look at Jure's experiments and the cost impact of failures as this might be nice to show in your own work. -Failures tap well into what he is doing. -The degradation model of CPU. -Shows how much money is being lost due to failures. - -Daniel cannot model some experiments in the web module. -He would not get results. -There are two different runners for the web module that are different from the generic `ExperimentRunner`. - 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 and say "Many researchers do not have access to this". -Instead we replace with a . -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. diff --git a/notes/notes.txt b/notes/notes.txt deleted file mode 100644 index d5394cf..0000000 --- a/notes/notes.txt +++ /dev/null @@ -1,32 +0,0 @@ -The presentation is in practice 30% of grade. -The actual grading goes on during the presentation. -Alex will only ask questions during the presentation. -You are getting a proof from the university that you are going to graduate. -The moment you get the information that your thesis went right, you get the document from the university saying that you are going to graduate. - -Alex assumes that you are going to do an 18EC honors project. -Text Alex again often. -You do a continuation of the bachelor thesis as an honors project. -Ana did spatial shifting as an honours thesis, and then on top of that she combined spatial and temporal shifting on top of her bachelor thesis. - -Dante's vision on the structure: -1. Introduction, background -- do a literature survey. - * you should add besides the model of digital twinning. -2. Design, how do you design -3. Experiments, - * add the methodology of running experiments. - * using the Datacenter simulator as a "real" Datacenter is in itself is a really interesting. -4. For a normal bachelor thesis you show the effect -- the failures. -5. Digital twin scheduling vs. Scheduling. ---BACHELOR thesis ends here-- ---HP Project here-- -Here we do the same thing with failures AND auto-scaling. -We add auto-scaling as the extra component. -We are looking at how this component interacts with all the other components. -Not just only an experiment but a bit more of an extra layer. --- HP project adding -- -Adding an extra layer of complexity and check how it acts together with the rest of the systems. - -Write down: these are the base things we want to do for sure, and then make a list of things we'd like the extra's. -A use case can be specific metrics you want to measure or actions you want to take (akin to auto-scaling). - diff --git a/notes/screenshots/common_pitfalls.png b/notes/screenshots/common_pitfalls.png new file mode 100644 index 0000000..3ebc53a Binary files /dev/null and b/notes/screenshots/common_pitfalls.png differ diff --git a/notes/screenshots/good_figure_from_dante.png b/notes/screenshots/good_figure_from_dante.png new file mode 100644 index 0000000..be41833 Binary files /dev/null and b/notes/screenshots/good_figure_from_dante.png differ diff --git a/notes/screenshots/good_figure_from_dante_2.png b/notes/screenshots/good_figure_from_dante_2.png new file mode 100644 index 0000000..09c7043 Binary files /dev/null and b/notes/screenshots/good_figure_from_dante_2.png differ diff --git a/notes/screenshots/introduction_timeline.png b/notes/screenshots/introduction_timeline.png new file mode 100644 index 0000000..ed2124d Binary files /dev/null and b/notes/screenshots/introduction_timeline.png differ diff --git a/notes/screenshots/map_of_thesis.png b/notes/screenshots/map_of_thesis.png new file mode 100644 index 0000000..a0729d8 Binary files /dev/null and b/notes/screenshots/map_of_thesis.png differ diff --git a/notes/vu_thesis_template_advice.pdf b/notes/vu_thesis_template_advice.pdf deleted file mode 100644 index 8eb63fe..0000000 Binary files a/notes/vu_thesis_template_advice.pdf and /dev/null differ -- cgit v1.2.3