This shows you the differences between two versions of the page.
isrm:laboratoare:new:09 [2020/04/11 15:51] vlad.traista [[00b] Rulare script] |
isrm:laboratoare:new:09 [2022/05/09 09:16] (current) mbarbulescu [[Bonus] Analiza] |
||
---|---|---|---|
Line 3: | Line 3: | ||
===== Bibliografie recomandată ===== | ===== Bibliografie recomandată ===== | ||
- | TODO | + | * [[https://www.cse.wustl.edu/~jain/atmf/ftp/af_fair.pdf|Throughput Fairness Index: An Explaination (slides)]] |
+ | * {{:isrm:laboratoare:new:a_quantitative_measure_of_fairness_and_d.pdf|A quantitative measure of fairness and discrimination for resource allocation in shared computer systems - R. Jain, D. Chiu, W. Hawe, 1984}} | ||
===== Echitate(Fairness) ===== | ===== Echitate(Fairness) ===== | ||
Line 38: | Line 39: | ||
==== [00a] Pregătirea laboratorului ==== | ==== [00a] Pregătirea laboratorului ==== | ||
- | Dacă vreți să creați folder nou pe calculatoarele voastre: | + | <note important> |
+ | Pe [[:isrm:mv|mașina virtuală]] aveți tot ce trebuie în ''/home/student/ns-3-dev''. | ||
+ | |||
+ | Dacă lucrați pe alt dispozitiv trebuie să rulați comenzile: | ||
<code bash> | <code bash> | ||
- | git clone https://gitlab.com/b12mihai1/ns-3-dev.git ~/ns-3-dev | + | student@isrm-vm-2020:~$ git clone https://gitlab.com/nsnam/ns-3-dev.git |
- | cd ~/ns-3-dev | + | student@isrm-vm-2020:~$ cd ~/ns-3-dev |
- | git checkout -b isrm_2020 remotes/origin/isrm_2020 | + | student@isrm-vm-2020:~/ns-3-dev$ git checkout -b ns-332-rel ns-3.32 |
- | git submodule init | + | student@isrm-vm-2020:~$ cd ~/ns-3-dev/examples |
- | git submodule update --remote --merge | + | student@isrm-vm-2020:~/ns-3-dev/examples$ git clone https://github.com/isrm-lab/ns3-labs.git |
- | git submodule foreach git pull origin master | + | student@isrm-vm-2020:~$ cd ~/ns-3-dev |
- | ./waf configure --build-profile=debug --enable-examples --enable-tests && ./waf build -j4 | + | student@isrm-vm-2020:~$ ./waf configure --build-profile=debug --enable-examples --enable-tests |
+ | student@isrm-vm-2020:~$ ./waf build -j4 | ||
</code> | </code> | ||
+ | </note> | ||
- | Dacă folosiți [[:isrm:mv|mașina virtuală]]: | + | Pentru a lansa aplicatia de Jupyter Notebook, rulati urmatoarea comanda: |
<code bash> | <code bash> | ||
- | student@isrm-vm:~$ cd ~/ns-3-dev | + | student@isrm-vm-2020:~$ jupyter-notebook |
</code> | </code> | ||
- | Verificați că sunteți pe branch-ul ''isrm_2020'' din remote-ul https://gitlab.com/b12mihai1/ns-3-dev.git: | + | ==== [00b] Rulare script ==== |
- | <code bash> | + | Topologia din script contine ''n'' noduri dintre care ''n-1'' sunt statii, iar ultimul nod este reprezentat de catre access point. Statiile sunt dispuse concentric in jurul access point-ului. Spre exemplu, pentru o topologie cu 4 noduri (3 statii si un access point), CW minim 15, CW maxim 1023, parametrii default de 802.11g, fără PCAP tracing si o durata simulării de 10 secunde, scriptul se ruleaza astfel: |
- | student@isrm-vm:~/ns-3-dev$ git remote -v | + | |
- | origin https://gitlab.com/b12mihai1/ns-3-dev.git (fetch) | + | |
- | origin https://gitlab.com/b12mihai1/ns-3-dev.git (push) | + | |
- | student@isrm-vm:~/ns-3-dev$ git branch -vv | + | <code bash> |
- | * isrm_2020 5993ca379 [origin/isrm_2020] fix submodules to have https instead of ssh | + | ./waf --run "lab9 --minCw=15 --maxCw=1023 --nn=4 --pcap=false --simulationTime=10" |
- | master da1b41ed1 [origin/master] tcp: Ensure that congestion state is set after every notification | + | |
</code> | </code> | ||
- | Rulați următoarele comenzi pentru update-ul submodului din ''examples/ns3-labs'': | + | In urma rularii, ultimele 2 linii sunt de interes: |
<code bash> | <code bash> | ||
- | student@isrm-vm:~/ns-3-dev$ git submodule update --remote --merge | + | rlen jain eps |
+ | 3 1 0.999515 | ||
</code> | </code> | ||
- | Dacă cea de mai sus nu merge alternativ puteți încerca: | + | ''rlen'' reprezinta numarul de statii, ''jain'' reprezinta indexul de echitate Jain, iar ''eps'' reprezinta indexul de echitate Epsilon. |
+ | ==== [01] Echitatea cu CW fix ==== | ||
- | <code bash> | + | Rulati scriptul pentru 10 noduri si observati valorile celor 2 indecsi de echitate pentru ferestre CW fixe de 7 vs 4095. Comentați rezultatul. |
- | student@isrm-vm:~/ns-3-dev$ git submodule foreach git pull origin master | + | |
- | </code> | + | |
- | ==== [00b] Rulare script ==== | + | Comparați echitatea pe termen scurt (5s), mediu(20s), lung (50s) pentru ferestrele CW fixe de 7 vs 4095. Simularea primește parametrul ''simulationTime'' pe care îl puteți ajusta. |
- | Topologia din script este oarecum similara cu cea din laboratorul 8. Spre exemplu, pentru o topologie cu 4 noduri, CW minim 15, CW maxim 1023, parametrii default de 802.11g, fără PCAP tracing si o durata simulării de 10 secunde, scriptul se ruleaza astfel: | + | Pentru ferestre fixe CW = 7, 31, 511, 4095, realizați patru grafice care indică echitatea în funcție de numărul de clienți ''2..20''. Fiecare grafic conține 3 curbe pentru duratele de rulare (5s, 20s, 50s). |
- | <code bash> | + | Cum explicați tendințele de creștere/scădere a echității cu: numărul de clienți, dimensiunea ferestrei, scara de timp considerată? |
- | ./waf --run "lab9 --minCw=15 --maxCw=1023 --nn=4 --pcap=false --simulationTime=10" | + | |
- | </code> | + | |
- | ==== [01] Echitatea cu CW fix ==== | + | <note> |
+ | Echitatea este determinată de urmatorii factori: | ||
+ | * coliziuni | ||
+ | * populație: mai mulți vorbitori înseamnă mai multe șanse de coliziune | ||
+ | * fereastra prea mică duce la mai multe coliziuni | ||
+ | * timp: pe termen lung, toți participanții au relativ aceleași șanse de a obține mediul sau de a intra în coliziune | ||
+ | </note> | ||
+ | |||
+ | ==== [02] Echitatea cu CW variabil (802.11 standard) ==== | ||
+ | |||
+ | Pentru 802.11 standard cu dimensiunea ferestrei CW variabila ''minCW=15, maxCW=1023'', realizați un grafic care indică echitatea în funcție de numărul de clienți ''2..20''. Graficul conține 3 curbe pentru duratele de rulare (5s, 20s, 50s). | ||
+ | |||
+ | Cum este echitatea față de cazurile cu fereastră fixă? De ce? ((o exprimare folclorica dinn 802.11, "Rich get richer, poor get poorer")) | ||
+ | |||
+ | Cum se poate îmbunătăți echitatea pentru configurația dată? ((Renunțăm la capacitate pt echitate)) Modificați si rulați. | ||
+ | |||
+ | ==== [03] Echitatea cu CW variabil (802.11 standard) cu RTS/CTS ==== | ||
+ | |||
+ | Pentru 802.11 standard cu dimensiunea ferestrei CW variabila ''minCW=15, maxCW=1023'' si cu RTS/CTS activat, realizați un grafic care indică echitatea în funcție de numărul de clienți ''2..20''. Graficul conține 3 curbe pentru duratele de rulare (5s, 20s, 50s). | ||
+ | |||
+ | Utilizarea RTS/CTS duce la creșterea echității? De ce? | ||
+ | |||
+ | ==== [Bonus 1] Analiza mix downlink/uplink ==== | ||
- | * pentru 10 noduri, estimați rulând manual echitatea cu ferestre CW fixe de 7 vs 4095. Comentați rezultatul | + | Ce se schimbă atunci când în loc de N fluxuri upstream, avem de exemplu 2 fluxuri downlink și N-2 uplink? (( WiFi produce o oarecare echitate între vorbitori, deci cele 2 fluxuri downlink pentru care AP este vorbitor vor primi împreună cât un flux uplink)) |
- | * comparați echitatea pe termen scurt (1s), mediu(5s), lung (50s). Simularea primește parametrul ''simulationTime'' pe care îl puteți ajusta. | + | |
- | * pentru ferestre fixe CW = 7, 31, 511 realizați trei grafice care indică echitatea în funcție de numărul de clienți ''2..20''. Fiecare grafic conține 3 curbe pentru duratele pe care se face medierea (1s, 5s, 50s) | + | |
- | * cum explicați tendințele de creștere/scădere a echității cu: numărul de clienți, dimensiunea ferestrei, scara de timp considerată? (( Echitatea este determinată (și) de coliziuni. Populație: mai mulți vorbitori înseamnă mai multe șanse de coliziune; Fereastra prea mică duce la mai multe coliziuni; Timp: pe termen lung, toți participanții au relativ aceleași șanse de a obține mediul, sau de a intra în coliziune. )) | + | |
- | * 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 este echitatea față de cazurile cu fereastră fixă? De ce? (( în 802.11, pe termen scurt "Rich get richer, poor get poorer")) | + | |
- | * cum se poate îmbunătăți echitatea pentru configurația dată? (modificați, rulați, plotați) (( Hint: renunțăm la capacitate pt echitate...)) | + | |
- | * 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? (( WiFi produce o oarecare echitate între vorbitori, deci cele 2 fluxuri downstream pentru care AP este vorbitor vor primi împreună cât un flux upstream)) | + | |
* Rezultate | * Rezultate | ||
* Echitatea Jain pentru CW = 31 | * Echitatea Jain pentru CW = 31 | ||
Line 105: | Line 119: | ||
* Echitatea Jain pentru 802.11 cu RTS | * Echitatea Jain pentru 802.11 cu RTS | ||
+ | <note>Acest exercitiu presupune modificari in scriptul de ns3.</note> | ||
+ | |||
+ | ==== [Bonus 2] TCP traffic ==== | ||
+ | |||
+ | Realizați exercițiul 2 cu trafic TCP (se înlocuiește ''ns3::UdpSocketFactory'' în codul simulării cu ''ns3::TcpSocketFactory'' sau puteți urmări funcția ''setup_tcp_flow'' din ''lab5.cc'' |