Uke 9 - Multitasking og Linux-VMer

Oppgaver til mandag 24. - fredag 28. feb

(Oblig)

#include <algorithm> #include <iostream> using namespace std; int main() { // Lager et data-array int i,c; int arraySize = 32768; int data[arraySize]; for (c = 0; c < arraySize; ++c) { data[c] = rand() % 256; } // Gir tilfeldig tall mellom 0 og 255 // Gir samme array med tall for hver kjøring // sort(data, data + arraySize); // sorterter data-arrayet // Skriver ut de 10 første verdiene for (c = 0; c < 10; c++) cout << data[c] << "\n"; // Legger sammen alle tall større enn 127 long sum = 0; // Ytre løkke for at det skal ta litt tid... for (i = 0; i < 50000; ++i) { // Indre løkke for (c = 0; c < arraySize; ++c) { if (data[c] > 127) sum += data[c]; } } cout << "sum = " << sum << "\n"; }

(Oblig)
(Oblig)
```
$ (time regn) > res.txt 2> err.txt&
```
Parentesene gjør at også time kjører før output blir omdirigert. Uten parenteser utføres kommandoen time på regn > res.txt 2> err.txt& og output fra time blir ikke omdirigert (time printer default til stderr).
data2500 har 4 CPUer. Men det kan være andre som kjører samtidig og om alle 4 CPUene er belastet, kan det bli mindre enn 100% på hver prosess.
Prosessen får ca 100% CPU-tid når ingen andre CPU-krevende prosesser kjører. Når to CPU-krevende jobber kjøres samtidig blir de satt på hver sin CPU og bruker 100% hver av hver sin CPU. Når 5 prosesser kjører fordeles de på 4 CPUer, flyttes fortløpende rundt på de 4 CPUene og får ca 80% CPU-tid hver. Til enhver tid er det to prosesser på samme CPU, men hvilken det er endres. Siden 5 prosesser fordeles på 4 CPUer, vil det ta 5/4 ganger tiden det tar for en prosess å bli ferdig på en CPU. Hvis en prosess er ferdig på 40 sekunder, vil 5 prosesser bli ferdig på (5/4)*40 = 50 sekunder. Totalt trenger prosessene 5*40 "CPU-sekunder" og 200 CPU-sekunder/4CPUer = 50 sekunder.
(Oblig)
Svaret for 4 CPUer er galt, fordi scheduleren fordeler CPU-tid jevnt mellom alle prosessene som kjøres. De kjøres ikke i to grupper med 4 og to prosesser som ChatGPT mener. Alle 6 kjører samtidig, men to vil da tii en hver tid vente. Og generelt er fremgangsmåten feil, prosessene kjører samtidig, ikke sekvensielt. Men for de andre tilfellene blir svaret likevel riktig. Prosessene scheduleres til å bytte på å bruke de tilgjengelige CPUene slik at alle får like mye CPU-tid. Totalt behøves 6 CPU * 10 miutter = 60 CPU*minutter. Med for eksempel 4 CPUer tilgjengelig tar det da 60 CPU*minutter/4 CPU = 15 minutter å få alle prosessene ferdig.

CPUer beregning minutter

1 60/1 60

2 60/2 30

4 60/4 15

6 60/6 10

8 60/6 10

Hvis det ikke er flere CPUer enn prosesser, kan man altså dele antall CPU-minutter som må utføres på antall CPUer. Når det er flere CPUer enn prosesser, blir ikke disse utnyttet. Med 8 CPUer vil bare 6 av CPUene brukes og det vil totalt ta 10 minutter å bli ferdig.
```
for i in {1..6}; do time ./a.out& done
```
vil vise ca 27 sekunder med litt variasjon for hver av prosessene, der en prosess bruker ca 9 sekunder.
(Oblig)

CPUer	beregning	minutter
1	60/1	60
2	60/2	30
4	60/4	15
6	60/6	10
8	60/6	10

$ sudo adduser groupXX os
$ chgrp -R os ~/felles 
$ chmod -R 770 ~/felles

Ja, filens eier endres til den siste som lagret den.

Med chmod 007 ~/fil.txt er det kun alle andre som får lov til å se på filen. Men s123456 er med i gruppen os som filen tilhører og får derfor ikke se den.
(Oblig)
(Oblig)
(Oblig)
#! /bin/bash # Run every night /usr/bin/rsync --delete -a group60@os60.vlab.cs.oslomet.no:/home/group60 /home/s123456/home echo "Backup ble tatt $(date)" >> sync.log
```
# m h  do# m h  dom mon dow   command
0 3 * * * /home/haugerud/sync.sh > /dev/null 2&>1
```
#! /bin/bash # Run every night # Tillegg for root: /usr/bin/rsync --delete -a root@os60.vlab.cs.hioa.no:/etc /iu/cube/u0/s123456/home
Ja, det er mulig å legge id_rsa i .ssh og så lage en id_rsa.pub med
```
ssh-keygen -f ~/.ssh/id_rsa -y
```
og så logge inn på data2500.
(Oblig)