This is an old revision of the document!
TODO
Î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 modelează diferit în funcție de următoarele aspecte:
În cazul în care toate cererile sunt egale, iar $x_i$ este cantitatea obținută de participantul $i$:
\[ 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:
Dacă vreți să creați folder nou pe calculatoarele voastre:
git clone https://gitlab.com/b12mihai1/ns-3-dev.git ~/ns-3-dev cd ~/ns-3-dev git checkout -b isrm_2020 remotes/origin/isrm_2020 git submodule init git submodule update --remote --merge git submodule foreach git pull origin master ./waf configure --build-profile=debug --enable-examples --enable-tests && ./waf build -j4
Dacă folosiți mașina virtuală:
student@isrm-vm:~$ cd ~/ns-3-dev
Verificați că sunteți pe branch-ul isrm_2020
din remote-ul https://gitlab.com/b12mihai1/ns-3-dev.git:
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 * isrm_2020 5993ca379 [origin/isrm_2020] fix submodules to have https instead of ssh master da1b41ed1 [origin/master] tcp: Ensure that congestion state is set after every notification
Rulați următoarele comenzi pentru update-ul submodului din examples/ns3-labs
:
student@isrm-vm:~/ns-3-dev$ git submodule update --remote --merge
Dacă cea de mai sus nu merge alternativ puteți încerca:
student@isrm-vm:~/ns-3-dev$ git submodule foreach git pull origin master
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:
./waf --run "lab9 --minCw=15 --maxCw=1023 --nn=4 --pcap=false --simulationTime=10"
In urma rularii, ultimele 2 linii sunt de interes:
rlen jain eps 3 1 0.999515
rlen
reprezinta numarul de statii, jain
reprezinta indexul de echitate Jain, iar eps
reprezinta indexul de echitate Epsilon.
Rulati scriptul pentru 10 noduri si observati valorile celor 2 indecsi de echitate pentru ferestre CW fixe de 7 vs 4095. Comentați rezultatul.
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.
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).
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ă?
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? 1)
Cum se poate îmbunătăți echitatea pentru configurația dată? 2) Modificați si rulați.
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?
Ce se schimbă atunci când în loc de N fluxuri upstream, avem de exemplu 2 fluxuri downstream și N-2 upstream? 3)