Differences
This shows you the differences between two versions of the page.
|
isrm:laboratoare:colocviu [2017/11/02 16:20] dragos.niculescu |
isrm:laboratoare:colocviu [2020/05/08 10:28] (current) vlad.traista [Colocviu 1 - model rezolvat complet] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ===== Colocviu 1 ===== | ||
| + | |||
| //Răspunsurile se dau în scris, nu mai mult de un paragraf pentru punctele a,b,d. Graficele pentru c se fac în gnuplot (sau altceva) și se reproduc cu aproximație pe hârtie. Nu demarați punctul e) decât dacă sunteti sigur că ați obținut deja 100%.// | //Răspunsurile se dau în scris, nu mai mult de un paragraf pentru punctele a,b,d. Graficele pentru c se fac în gnuplot (sau altceva) și se reproduc cu aproximație pe hârtie. Nu demarați punctul e) decât dacă sunteti sigur că ați obținut deja 100%.// | ||
| + | |||
| + | Într-un setup de tip infrastructură **''802.11b''** cu **''dataRate''** (sau **''MCS''**) egal cu **''11Mbps''**, fiecare | ||
| + | client rulează două fluxuri **''UDP (CBR)''** cu AP-ul - unul uplink, apoi imediat/concomitent altul downlink. În ambele fluxuri de trafic rata de transmisie (''sendingRate'') reglată de AP dar și de clienți este cât mai apropiată de capacitatea maximă a canalului (ei își doresc să trimită la 11 Mbps). | ||
| + | |||
| + | Ne propunem să se investigheze relația dintre debitele cumulative uplink și downlink ale fiecărui client în funcție de populația de clienți. | ||
| + | |||
| + | {{:isrm:laboratoare:colocviu_1_updn.png?nolink&300|}} | ||
| + | |||
| + | a) Ipoteza de la care vom porni analiza (estimare): throughput-ul uplink și throughput-ul downlink rămân echilibrate pentru fiecare client odată cu creșterea numărului de clienți în rețea? (10%). | ||
| + | |||
| + | b) Descrierea în pseudocod a setup-ului de simulare și a procedurii de colectare a datelor: de la ce script pornim, ce modifcări efectuăm asupra lui, ce output avem nevoie etc. (20%) | ||
| + | |||
| + | c) Realizarea graficului: pe axa ''Ox'': numărul de clienți, pe axa ''Oy'': curba y1: uplink total throughput, curba y2: downlink total throughput (30%) | ||
| + | |||
| + | d) Explicarea/interpretarea curbelor y1 și y2 obținute. Puncte care trebuie atinse (40%): | ||
| + | * throughput minim obținut | ||
| + | * throughput maxim obținut - și dacă nu e egal cu MCS-ul de ce? | ||
| + | * monotonia funcțiilor (crescătoare/descrescătoare/constante) | ||
| + | * comparație între curbe | ||
| + | |||
| + | e) (bonus) punctele a-d pentru TCP, doar dacă a-d sunt complete (20%) | ||
| + | |||
| + | <solution> | ||
| + | Rezolvarea (și graficul) se găsesc pe [[https://github.com/isrm-lab/isrm-lab-sol/tree/master/col-1|github]] | ||
| + | </solution> | ||
| + | |||
| + | <hidden> | ||
| + | ===== Colocviu 1 - model rezolvat complet ===== | ||
| - | == Colocviu 1 == | ||
| Folosind un model de propagare probabilistic (probabilitatea de | Folosind un model de propagare probabilistic (probabilitatea de | ||
| livrare la nivel fizic depinde de distanță), se dorește explorarea | livrare la nivel fizic depinde de distanță), se dorește explorarea | ||
| Line 19: | Line 48: | ||
| **e)** 20% o ipoteză similară pentru TCP, punctele a-d, (doar dacă a-d sunt complete) | **e)** 20% o ipoteză similară pentru TCP, punctele a-d, (doar dacă a-d sunt complete) | ||
| + | |||
| + | |||
| + | == Soluție == | ||
| + | |||
| + | **a)** 10% ipoteza NU este adevărată | ||
| + | |||
| + | **b)** | ||
| + | Se folosește nemodificat scriptul din laborator 4. | ||
| + | Se creează fișierele text cu coloana 1 = tries, coloana 2 = throughput(bps) astfel: | ||
| + | <code> | ||
| + | for t in $(seq 1 1 20); do | ||
| + | echo -n "$t "; | ||
| + | ns ./shadow2.tcl -tries $t -dist 10| grep "Throughput 0" | awk '{print $3}'; | ||
| + | done | tee u10 | ||
| + | </code> | ||
| + | Este acceptabilă și rularea manuala în 4-5 puncte și plotarea doar în aceste puncte, fără gnuplot. | ||
| + | În mod similar se produc fisierele u10, u120, u150 pentru UDP la 10m, 120m, 150m si se plotează: | ||
| + | |||
| + | **c)** {{:isrm:laboratoare:colocviu:udp-tries.png?nolink|}} | ||
| + | |||
| + | **d)** La distanța de 10m reîncercările nu contează, deoarece canalul este deja foarte bun (vezi si simulările din lab 4). | ||
| + | Pentru linkuri cu pierderi (120m si 150m), pierderile duc la creșterea CW, deci așteptare suplimentară în care nu se face nimic, deci debitul obtinut scade. Cu o singură încercare se trece la următorul pachet făra a se mări fereastra de contenție și în final numărul de pachete sosite pe secunda va fi mai mare. | ||
| + | |||
| + | **e)** | ||
| + | |||
| + | {{:isrm:laboratoare:colocviu:tcp-tries.png?nolink|}} | ||
| + | |||
| + | Se folosește aceeași procedură de colectare, dar cu parametrul run_tcp=1. Ipoteza este adevărata pentru TCP, cel puțin pentru număr mic de încercări. | ||
| + | TCP are rezultate mai modeste când se pierd pachete, deoarece își reduce agresiv fereastra. Dacă aceste pierderi sunt acoperite performanța este consistentă. Pierderile sunt complet acoperile cu 3 încercări la 120m si cu 5 încercări la 150m. Conform rezultatelor din lab 4, la 120m pierderile sunt cam de 30%, iar la 150m de 75%. | ||
| + | </hidden> | ||
| + | |||
