Differences
This shows you the differences between two versions of the page.
|
isrm:laboratoare:05 [2013/10/16 10:07] dragos.niculescu |
isrm:laboratoare:05 [2014/10/29 20:12] (current) dragos.niculescu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== Laboratorul 5 ==== | ==== Laboratorul 5 ==== | ||
| - | === Echitate(Fairness) === | ||
| - | În calculatoare și comunicații sunt folosite diverse metrici ale echității pentru a determina împărțirea "echitabilă" a resurselor. Am folosit ghilimelele deoarece există mai multe modele conceptuale de echitate, cu alte cuvinte, dreptatea nu este numai una! Problema echității se modulează diferit în funcție de următoarele aspecte: | + | Se pornește de același {{isrm:laboratoare:src:infra.tcl| script infra.tcl}} de la 3 și 4. Varianta nemodificată trimite trafic downlink către ''nn-1'' clienți. Vom evalua capacitatea în condiții noi: **client unic vs. multipli, uplink vs downlink.** Topologia este una specifică modului infrastructură, cu un AP și mai mulți clienți asociați, dar cadrele de beacon, autentificare, și asociere sunt omise pentru simplitate. |
| - | * utilizatorii cer părți egale, diferite, sau maximul disponibil | + | |
| - | * utilizatorii pot utiliza efectiv părți egale sau diferite (e.g: wireless aproape/departe de BS) | + | |
| - | * dependența între resursa primită și QoE nu e liniară (e.g: MPEG frames) | + | |
| - | * eficiența globală nu este sacrificată prea mult pentru o echitate dorită (e.g: comunism) | + | |
| - | * echitatea se obține doar pe termen lung (e.g: WiFi) | + | |
| - | + | ||
| - | == Jain's Fairness Index === | + | |
| - | În cazul în care toate cererile sunt egale, iar $x_i$ este cantitatea obținută de participantul $i$: | + | |
| - | <html> | + | |
| - | <script type="text/javascript" | + | |
| - | src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"> | + | |
| - | </script> | + | |
| - | </html> | + | |
| - | \[ Jain(x_i)=\frac{(\sum_{i=1}^{n}{x_i})^2}{n \sum_{i=1}^{n}{x_i^2}} \] | + | |
| - | \[ Jain(x_i) \in [0,1] \] | + | |
| - | + | ||
| - | Proprietăți: | + | |
| - | * $x_i$ egale, $ => Jain(x_i)=1$ | + | |
| - | * $x_1..x_k$ egale și $x_(k+1)..x_n=0 =>$ $Jain(x_i)=\frac{k}{n}$ | + | |
| - | * $x_1$ ia totul, iar ceilalți nimic '$ => Jain(x_i)=\frac{1}{n}$ - inechitatea cea mai gravă | + | |
| - | * independent de populație | + | |
| - | * independent de scara $x_i$ | + | |
| - | * continuă în [0..1] | + | |
| - | + | ||
| - | == Echitatea ε == | + | |
| - | * capturează inechitatea cea mai gravă | + | |
| - | * $ \varepsilon(x) = \frac{\min_i x_i}{\max_i x_i} $ | + | |
| - | * 0 = starving, 1 = echitate perfecta | + | |
| - | + | ||
| - | + | ||
| - | Descărcați scriptul {{isrm:laboratoare:05:cw-fair.tcl}} care folosește parametrii: -rlen -cwmin -cwmax. În script este definită durata simulării simtime. Topologia folosită este cu un AP în mijloc, și rlen-1 stații dispuse circular la distanță egală care transmit UDP __către__ AP. | + | |
| - | + | ||
| - | * pentru 6 noduri, estimați (vizual) echitatea cu ferestre CW fixe de 7, 15, 63, 511, 1023, 4095 | + | |
| - | * pentru 6 noduri plotați un graf cu capacitatea totală obținută pentru cazurile de mai sus. Comentați. | + | |
| - | * comparați echitatea pe termen scurt (1s), mediu(5s), lung (50s) | + | |
| - | * Pentru 802.11 standard, calculați echitatea pe termen scurt (5s) și pe termen lung (50s). Realizați grafice care să ilustreze variația echității cu numărul de clienți. | + | |
| - | * Cum se poate îmbunătăți echitatea pentru configurația dată? (modificați, rulați, plotați) | + | |
| - | * Utilizarea RTS/CTS duce la creșterea echității? De ce? | + | |
| - | * Ce se schimbă atunci când în loc de N fluxuri upstream, avem de exemplu 2 fluxuri downstream și N-2 upstream? | + | |
| - | + | ||
| - | == Max-min Fairness (facultativ) == | + | |
| - | Pentru fluxurile care au cereri diferite, echitatea Max-min alocă gradual pentru fiecare conexiune până este satisfăcută cea mai mică, apoi se continuă cu cele rămase. | + | |
| - | * Modificați rata pachetelor cerute de unele stații, și determinați dacă accesul la aer 802.11 este echitabil în sens Max-min. | + | |
| + | * realizați grafice doar pentru 11b, packetSize 1460, MCS=11Mbps | ||
| + | * se variază doar numărul de clienți, și se plotează debitul cumulativ pentru toate fluxurile | ||
| + | * pe baza scriptului original, creați câte un script pentru fiecare experiment mai jos. | ||
| + | * comentați și explicați fiecare curbă din fiecare grafic | ||
| + | - //downlink// - sursa: AP, destinații: 1..30 clienți (scriptul original) | ||
| + | - //uplink// - surse: 1..30 clienți, destinație: AP | ||
| + | - //mixed// - surse: 1..15, destinații: 16..30 | ||
| + | - //1up// - sursă: client 1, destinații: clienți 2..30 | ||
| + | - //1down// - surse: clienți 2..30, destinație: client 1 | ||
| + | - plotați pe același grafic cele 5 curbe pentru UDP - **grafic 1**(( {{:isrm:laboratoare:05:udp.norts.png|grafic 1}} )) | ||
| + | - plotați pe același grafic cele 5 curbe pentru TCP - **grafic 2**(( {{:isrm:laboratoare:05:tcp.norts.png|grafic 2}} )) | ||
| + | - se repetă experimentele cu RTS/CTS activat - **grafic 3** (( {{:isrm:laboratoare:05:rts.udp.png|grafic 1}} )) și **grafic 4** (( {{:isrm:laboratoare:05:rts.tcp.png|grafic 1}} )) | ||
| + | - (acest caz e mai simplu după ce interpretați și comentați rezultatele precedente) Cum e posibil ca //mixed// să obțină rezultate bune și la populații mari? Care este optimul pe care-l poate obține? | ||
| + | * <color red>**comentați și explicați fiecare rezultat**</color>, comparați cu rezultatele de la [[isrm:laboratoare:03|]], Client unic | ||
| + | * cum explicați diferențele //uplink - downlink//? (( pentru nn=2 e același lucru. Pentru mai mulți emițători, crește probabilitatea de coliziune)) | ||
| + | * cum explicați diferenta //uplink - 1up//? (( la uplink 'vorbitorii' sunt simetrici ca rol. La 1up tot traficul trece prin AP, deci capacitatea se înjumătățește. AP este deasemenea 'vorbitor', dar primește parte egală cu ceilalți, deși trebuie să transporte pentru alții )) | ||
| + | * cum explicați comportarea în cazul //mixed//? Comparați cu //1down//? (( deasemenea crește numărul de vorbitori. Curba este diferită, deoarece nn stații semnifică nn/2 vorbitori)) | ||
| + | * cum explicați diferențele TCP - UDP? (( TCP are ack-uri la nivelul 4; pe uplink TCP nu este agresiv, nu tolerează dropuri în coada AP-ului, deci reduce fereastra încât migrează către un optim global: 50% din aer pentru clienți și 50% pentru AP )) | ||
| + | * cum explicați diferențele RTS - simplu? | ||
| + | * up vs down (( coliziunile sunt mai puțin costisitoare - 1 RTS )) | ||
| + | * 1down vs mix (( am plotat mix după numărul de 'vorbitori'; coliziunile sunt mai puțin costisitoare )) | ||
| + | * care este valoarea până la care coboară cazul UDP///mixed//, și cum poate fi îmbunătățită? | ||
| + | * HINT: de ce la TCP //mixed// este similar cu //1up//? (( UDP trimite prea mult, dacă l-am forța să trimită mai puțin de la clienți, atunci AP-ul ar avea loc mai mult. )) | ||
| + | * modificați scriptul pentru a rezolva punctul 7 | ||
| + | SOLUȚII | ||
