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%.

Î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.

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%)

Colocviu 1 - model rezolvat complet

Folosind un model de propagare probabilistic (probabilitatea de livrare la nivel fizic depinde de distanță), se dorește explorarea următoarei ipoteze: “creșterea numărului de încercări duce la creșterea bps la destinație pentru un flux UDP”.

a) 10% ipoteza este adevărată sau nu

b) 20% descrierea în pseudocod a setup-ului de simulare și a colectării datelor

c) 30% Pentru a testa ipoteza, se va realiza un grafic care conține pe axa x numărul de încercări între 1 și 20, și pe axa y debitul obținut de UDP la distanța de 10m, 120m, 150m (3 curbe).

d) 40% explicarea curbelor obținute (minim, maxim, tendința, comparație între curbe)

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:

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

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)

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)

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%.

isrm/laboratoare/colocviu.txt · Last modified: 2019/03/30 20:49 by mbarbulescu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0