Differences
This shows you the differences between two versions of the page.
|
isrm:laboratoare:10 [2014/12/15 07:24] dragos.niculescu |
isrm:laboratoare:10 [2016/01/06 15:41] (current) dragos.niculescu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== Laboratorul 11 ==== | + | ==== Laboratorul 10 ==== |
| - | === Multihop, autointerferență === | + | === MCS multiple === |
| - | Se folosește un singur canal pentru toate hopurile din rețea. O topologie simplă este string: un șir de noduri care poate transporta trafic de la un capăt la altul. În general o rețea adhoc poate avea forma unui graf, dar două noduri care comunică vor folosi un șir de alte noduri pentru a transporta traficul. O particularitate a acestei topologii este aceea că pachetele aceluiași flux concurează pentru accesul la mediu. De fapt, un șir este o colecție de terminale expuse și ascunse. | ||
| - | === Experiment 1 === | + | Se dă scriptul {{isrm:laboratoare:src:multirate.tcl}} care definește |
| - | Se dă topologia A - B - C, nodurile fiind plasate la interval de 20m. CSThresh=550m, RXThresh=250m. Scriptul {{isrm:laboratoare:src:string_bidir.tcl}} primește parametrii -sendingRate0 [R0] -sendingRate1 [R1] care descriu ratele în bps oferite fluxurilor UDP0 A->B->C și UDP1 C->B->A (-sendingRate0 nu poate fi 0, dar se pot folosi valori foarte mici 0.01Kbps). Scriptul afișează debitul obținut, și produce fișierul trace ".tr" în formatul cunoscut. | + | nodurile WiFi 0,1,2,3,4 astfel: |
| + | <code> | ||
| + | 3 | ||
| - | - să se determine capacitatea mediului în bps, și în pps. | + | 4 0 2 |
| - | - atunci când fluxurile au cereri egale, să se examineze performanța obținută de fiecare flux în funcție de debitul oferit. Care sunt regiunile importante ale graficului? | + | |
| - | - Cum se justifică logic/numeric valoarea maximă și valoarea de saturație? | + | 1 |
| - | - Ce se schimbă la 2. și 3. când avem o topologie de 4 noduri spațiate la 20m: A - B - C - D? -sendingRate0 se transmite de la A, iar -sendingRate1 se transmite de la D, -nn 4 rulează cu 4 noduri. | + | </code> |
| - | - Ce valoare obține TCP în cele două situații? | + | Nodul 0 funcționează ca AP și emite la 11Mbps, iar celelalte noduri sunt clienți, cu legături uplink de 1Mbps. Sunt definite patru fluxuri UDP 1->3, 2->4, 4->0, 0->4, toate cu pachete de 1460 de octeți. |
| - | * de ce este mai mică decât ..., și mai mare decât...? | + | Distanțele de la clienți la AP sunt de 20m, RTS este dezactivat, RxThresh=250m, iar acești parametri nu vor fi modificați. |
| + | Scriptul **necesită** următorii | ||
| + | parametri pe linia de comandă: | ||
| + | * rate0 <rate> indică rata oferită pentru fluxul 1->3 | ||
| + | * rate1 <rate> indică rata oferită pentru fluxul 2->4 | ||
| + | * rate2 <rate> indică rata oferită pentru fluxul 4->0 | ||
| + | * rate3 <rate> indică rata oferită pentru fluxul 0->4 | ||
| - | === Experiment 2 === | + | La sfârșitul simulării de 100 secunde se afișează throughputul în bps |
| - | Folosindu-se același script, se evaluează capacitatea pentru un șir de 20 noduri spațiate fie la 20m, fie la 200m (variabila hopDistance în script). | + | pentru fiecare flux, și numărul total de pachete transferat pe durata |
| + | întregii simulări. Scriptul cere ca parametrii rate să fie diferiți de | ||
| + | zero, dar pentru a dezactiva un flux, trebuie furnizată o rată | ||
| + | neglijabilă, de exemplu 0.01bps. Unitatea de măsură nu se separă cu | ||
| + | spațiu: 11Mbps, 360Kbps, etc. | ||
| + | |||
| + | - Să se calculeze capacitatea maximă a aerului în pps si bps pentru fiecare emițător luat în izolare. Cât durează transmiterea unui cadru de la stații? Dar de la AP? | ||
| + | - Dacă doar fluxul 0 (1->3) este activ, ce throughput se obține end to end? | ||
| + | - Care este rata coliziunilor (cps)? Cât durează o coliziune? | ||
| + | - Cum se justifică valoarea obținută? Care este compoziția cadrelor din aer? | ||
| + | - Dacă doar fluxurile 0 (1->3) și 1 (2->4) sunt active, ce throughput se obține end to end? | ||
| + | - Cum se justifică valoarea obținută? | ||
| + | - Cum puteți obține o valoare mai mare? | ||
| + | |||
| + | |||
| + | === Rezolvare === | ||
| + | - Se dezactivează toate fluxurile în afară de unul pentru a studia un transmițător în izolare: <code> | ||
| + | ns ./multirate.tcl -rate0 0.01bps -rate1 0.01bps -rate2 0.01bps -rate3 11Mbps </code> Se obțin 511pps, sau 5.97Mbps pentru AP. Un cadru durează \( \frac{1000}{511} = 1.95ms \) <code> | ||
| + | ns ./multirate.tcl -rate0 0.01bps -rate1 0.01bps -rate2 11Mbps -rate3 0.01bps </code> Se obțin 77pps, sau 902Kbps pentru statii. Un cadru durează \( \frac{1000}{77} = 12.98ms \). E mai greu de folosit fluxurile 1->3 și 2->4 deoarece un pachet trece de două ori prin aer pentru aceste cazuri. Pentru acest setup, cele două treceri sunt la MCS diferite. | ||
| + | - Se activează doar fluxul 0 (1->3): <code> | ||
| + | ns ./multirate.tcl -rate0 902Kbps -rate1 0.01bps -rate2 0.1bps -rate3 0.1bps </code> Se obțin 755Kbps, sau 64pps. În aer se află cadre scurte, la 11Mbps, și cadre lungi, emise la 1Mbps, cel puțin câte 64 din fiecare, deoarece 64pps sunt livrate la destinație. Este posibil să mai fie și cadre în coliziune. | ||
| + | - <code> cat ./multirate.tr | grep cbr | grep COL | wc -l </code> Rezultă 4cps coliziuni pe secundă. Deoarece toate dispozitive sunt în CS, nu avem terminale ascunse, și coliziunile sunt datorate ferestrei de contenție. Avem 2 transmițători: AP și stația 1, ce emit cadre de lungimi diferite. O coliziune durează până la sfârșitul cadrului cel mai lung (802.11 nu are CSMA/CD), adică 12.98ms. 4*12.98ms = 52ms = 5.2% din timp. | ||
| + | - Trebuie să aflăm câte cadre din fiecare tip se află în aer într-o secundă. Fiecare emițător câștigă aceleași oportunități de transmisie pe termen lung((De ce? Explicați folosind algoritmul de acces la mediu 802.11, sau prin rulare: -rate0 0.1bps -rate1 0.1bps -rate2 11Mbps -rate3 11Mbps)), x cadre pe secundă, dar fiecare îl ține ocupat în funcție de MCS folosit: (1Mbps, 11Mbps) \( R_1 = 77pps, R_2 = 511pps\). În plus mai avem și C coliziuni pe secundă. $$ \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$ $$ x = (1-\frac{C}{R_1})\frac{R_1R_2}{R_1+R_2} = 63pps$$ adică 63*1480*8 = 751Kbps, consistent cu ce am obținut în simulare. | ||
| + | * Stația 1 ocupă 64*12.98 = 823ms = 82% din timp. | ||
| + | * AP ocupă 64*1.95=123ms = 12% din timp | ||
| + | * coliziuni, restul de 5% din timp | ||
| + | * Coada de pachete este probabil mereu goală în AP, și în creștere la stație, deoarece se generează mai mult decât se poate emite. | ||
| + | - Activăm fluxurile 0 și 1, oferind maximul precedent: <code> | ||
| + | ns ./multirate.tcl -rate0 755Kbps -rate1 755Kbps -rate2 0.1bps -rate3 0.1bps | ||
| + | cat ./multirate.tr | grep cbr | grep COL | wc -l | ||
| + | </code> Se obțin câte 199Kbps pentru fiecare flux, adică 17pps. Coliziuni 8.2cps. | ||
| + | - Dacă se transmite un maximum de la fiecare sursă (1 și 2), AP-ul va avea de retransmis pentru ambele, dar nu câștigă mediul decât în 1/3 din arbitrări, deși cadrele lui sunt mai scurte. $$ \frac{x}{R_1} + \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$ Ce este diferit față de cazul precedent este că toți cei trei emițători sunt saturați, AP-ul însă nu dirijează decât \( \frac{x}{2} \) pentru fiecare flux, iar restul este pierdut. $$ x = (1 - \frac{C}{R_1})\frac{R_1 R_2}{R_1+2 R_2} = 32pps$$ Dar debitul obținut pentru fiecare flux este doar \(x/2\) = 16pps, adică 190Kbps. | ||
| + | * Stația 1 ocupă 32*12.98ms = 42% din timp | ||
| + | * Stația 2 ocupă 32*12.98ms = 42% din timp | ||
| + | * AP ocupă 32*1.95ms = 6% din timp | ||
| + | * Coliziuni 8.2*12.98ms = 10% din timp | ||
| + | * Adică 42% din timp este irosit pentru a transmite prin aer cadre care vor fi aruncate la AP! | ||
| + | - Ar trebui ca fiecare cadru emis de o sursă să fie dirijat de către AP, si nu aruncat, deci împărțirea prin contenție nu se dorește echitabilă, ci AP-ul ar trebui să obțină dublu față de fiecare stație. \(x\) este acum debitul per flux: $$ \frac{x}{R_1} + \frac{x}{R_1} + \frac{2x}{R_2} + \frac{C}{R_1} = 1 $$ Din păcte C și x sunt interdependente, și o proporție de coliziuni este inevitabilă chiar dacă AP-ul este nesaturat. Cu 0 coliziuni am obține $$ x = \frac{0.5 R_1 R_2}{R_1 + R_2} = 33.5pps = 396Kbps $$ Dacă rulăm, obținem 214Kbps și 7.9cps, ceea ce este departe de formulă, dar totuși crește debitul și scad coliziunile, deci este clar că trebuie trimis mai puțin de la surse. Un alt indiciu este că nu se pot emite mai mult de 755Kbps pentru un flux, deci 755Kbps/2 = 377Kbps de la fiecare stație 0 și 1, deoarece mediul este comun. <code> ns ./multirate.tcl -rate0 377Kbps -rate1 377Kbps -rate2 0.1bps -rate3 0.1bps | ||
| + | </code> Se obțin câte 337Kbps pentru fiecare flux, adică 29pps. Coliziuni C = 5.9cps. Folosind acest ultim C, obținem: $$ x = (1 - \frac{C}{R_1})\frac{0.5 R_1 R_2}{R_1+R_2} = 31pps = 365Kbps $$ Dacă oferim doar 365K, se obțin 362K, si doar 4cps (similar cu 2., 3.), probabil optimul pentru această configurație. | ||
| - | * trasați un grafic care arată capacitatea unui șir de noduri în funcție de lungimea lui (1-19 hopuri) | ||
| - | * ce cantitate de trafic injectați în rețea pentru a obține graficul? | ||
| - | * repetați graficul pentru UDP bidirecțional. | ||
| - | * rulați manual pentru diverse valori de trafic injectat | ||
| - | * repetați graficul pentru TCP. Opțiunea -run_tcp 1 generează trafic TCP unidirecțional. | ||
| - | * Explicați asemănările și diferențele pentru cele 2 tipuri de transfer (UDP/TCP) | ||
| - | * repetați graficul pentru TCP bidirecțional. | ||
| - | * comparați | ||
| - | * TCP vs UDP | ||
| - | * 20m vs 200m | ||
| - | * unidirecțional vs. bidirecțional | ||
| - | | ||
| - | === Experiment 3 === | ||
| - | TCP, 10 noduri, distanța 20m: | ||
| - | * Cum se comportă fereastra de congestie TCP? (cwnd_ în fișierul trace), RTT(srtt_ și rttvar_) | ||
| - | * care este valoarea BDP (bandwidth-delay product) pentru legătura obținută? | ||
| - | * unde se aruncă pachete din cozile ruterelor și unde se pierd în coliziuni? | ||
| - | * Ce dimensiune are coada unei interfețe wireless? | ||
| - | * Se poate obține throughput mai bun mărind coada? | ||
