This is an old revision of the document!


Laborator 09 - Echitate

Bibliografie recomandată

TODO

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 modelează diferit în funcție de următoarele aspecte:

  • 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$:

\[ 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$ echitate perfectă
  • $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 dimensiunea $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 perfectă

Task-uri

[00a] Pregătirea laboratorului

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

[00b] Rulare script

Topologia din script este oarecum similara cu cea din laboratorul 8. 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"

[01] Echitatea Jain cu CW fix

  • pentru 10 noduri, estimați rulând manual echitatea cu ferestre CW fixe de 7 vs 4095. Comentați rezultatul
  • 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ă? 1)
  • 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? 2)
    • cum se poate îmbunătăți echitatea pentru configurația dată? (modificați, rulați, plotați) 3)
    • 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? 4)
  • Rezultate
  • Echitatea Jain pentru CW = 31
  • Echitatea Jain pentru CW = 511
  • Echitatea Jain pentru 802.11(CW=31..1023)
  • Echitatea Jain pentru 802.11 cu RTS
1) 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.
2) în 802.11, pe termen scurt “Rich get richer, poor get poorer”
3) Hint: renunțăm la capacitate pt echitate…
4) 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
isrm/laboratoare/new/09.1586610163.txt.gz · Last modified: 2020/04/11 16:02 by vlad.traista
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