Changes between Version 12 and Version 13 of Diario/SoujaK
- Timestamp:
- Jun 22, 2007, 12:47:35 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Diario/SoujaK
v12 v13 3 3 4 4 == 4 Giugno 2007 == 5 Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion (2h). 5 (2.00h)[[BR]] 6 Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion. 6 7 7 8 == 5 Giugno 2007 == 8 Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web (1h). 9 (1.00h)[[BR]] 10 Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web. 9 11 10 12 == 11 Giugno 2007 == 11 Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico. (0.4h) 12 13 (0.40h)[[BR]] 14 Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico. 15 16 __1400-1740__[[BR]] 13 17 00: l'articolo propone l'identificazione di una bandwidth potenziale ottenibile da un determinato AP a partire dalle condizioni di carico che un client è in grado di rilevare in esso. 14 18 Lo studio prende in considerazione uno scenario privo di disturbi ambientali, senza coordinamento centralizzato. 15 19 Assumendo che i frame beacon non abbiano priorità sugli altri, è possibile stimare il tempo medio di attesa di trasmissione osservando il ritardo dei frame beacon (si ricordi la presenza del "Beacon Interval" e del "Target Beacon Transmission Time"). 16 20 Inoltre fornisce spunti perché una stazione possa inferire una probabilità di perdita di trasmissioni, sfruttando i numeri di sequenza ("Sequence number") dei frame che cattura e il "Retry Bit". 17 La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate (1400-1740). 18 21 La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate. 22 23 __1800-1820__[[BR]] 24 __1900-1920__[[BR]] 19 25 01: La selezione ottimale dell'Access Point è strettamente legata a politiche di allocazione del traffico in grado di gestire in maniera ottimizzata le risorse disponibili. Il problema viene affrontato da un punto di vista piuttosto teorico, oltre che distante dai nostri scopi, rendendolo quasi per nulla interessante. 20 (1800-1820, 1900-1920) 21 22 02: L'articolo propone parametri concreti per la valutazione della bontà degli AP, che prevede essere calcolati direttamente dal loro ''firmware''(testato con IPW 2915) e periodicamente comunicati alle STA tramite i ''frame beacon''. Nonostante la forte dipendenza da modifiche ai ''firmware'' presumo che i calcoli dei parametri, di davvero grande rilevanza, effettuati dagli AP possano essere eseguiti anche lato ''client''. (1920-2000, 0910-0930) 26 27 __1920-2000__[[BR]] 28 __0910-0930__[[BR]] 29 02: L'articolo propone parametri concreti per la valutazione della bontà degli AP, che prevede essere calcolati direttamente dal loro ''firmware''(testato con IPW 2915) e periodicamente comunicati alle STA tramite i ''frame beacon''. Nonostante la forte dipendenza da modifiche ai ''firmware'' presumo che i calcoli dei parametri, di davvero grande rilevanza, effettuati dagli AP possano essere eseguiti anche lato ''client''. 23 30 24 31 == 12 Giugno 2007 == 25 1000-1020(0.33h)[[BR]]26 Sincronizzazione del diario. 27 28 1030-1100(0.50h)[[BR]]32 __1000-1020__ (0.33h)[[BR]] 33 Sincronizzazione del diario. 34 35 __1030-1100__ (0.50h)[[BR]] 29 36 Punto della situazione assieme a gnappo. 30 37 31 1120-1155(0.58h)[[BR]]38 __1120-1155__ (0.58h)[[BR]] 32 39 03: In appendice è presente un'interessante calcolo dell'impatto degli errori di trasmissione sulle prestazioni, calcolando diligentemente i dettagli relativi ai backoff incrementali. 33 40 34 1210-1310(1.00h)[[BR]]41 __1210-1310__ (1.00h)[[BR]] 35 42 04: Lo studio effettua una stima dell'effettiva ''bandwitdth'' disponibile, in base al tempo che intercorre fra la richiesta di invio del frame e la notifica di avvenuta trasmissione. 36 43 In questo calcolo vengono a sommarsi i tempi di attesa per l'accesso al mezzo (rilevazione di mezzo disponibile e successiva contesa), la procedura RTS/CTS, l'effettiva trasmissione dei dati e del'ACK, IFS relativi. … … 39 46 I concetti appena descritti appaiono come spunti piuttosto rilevanti ai nostri fini. 40 47 41 1450-1617(0.45h)[[BR]]48 __1450-1617__ (0.45h)[[BR]] 42 49 Ricerche ulteriori. 43 50 44 1650-1720 (0.33h)[[BR]]51 __1650-1720__ (0.33h)[[BR]] 45 52 05: L'articolo propone una algoritmo di controllo della associazione (lato client) che si configura come erede degli algoritmi precedentemente proposti da altri studi. 46 53 47 54 == 13 Giugno 2007 == 48 0900-0910(0.16h)[[BR]]55 __0900-0910__ (0.16h)[[BR]] 49 56 Approfondimento di 04. 50 57 51 1000-1025(0.41h)[[BR]]52 Sincronizzazione del diario. 53 54 1025-1140(1.25h)[[BR]]58 __1000-1025__ (0.41h)[[BR]] 59 Sincronizzazione del diario. 60 61 __1025-1140__ (1.25h)[[BR]] 55 62 05: Lo studio ha come fine l'ottimizzazione delle risorse, intese in senso globale e propone un algoritmo per la gestione delle associazioni basato sul rilevamento del carico degli AP. 56 Il concetto di carico totale di un AP viene definito come la somma dei carichi di ogni singolo client, i.e. il tempo che un AP impiega per fornire ad ognuno degli utenti una unità di traffico mentre.63 Il concetto di carico totale di un AP viene definito come la somma dei carichi di ogni singolo client, i.e. il tempo che un AP impiega a fornire ad ognuno degli utenti una unità di traffico. 57 64 Questa definizione, in realtà scopiazzata da 06, viene successivamente arriccchita, definendola piuttosto come sommatoria degli inversi dei tassi di trasmissione di ogni client associato ad un determinato AP. 58 65 In pratica si calcola il tempo necessario affinché ognuna delle stazioni associate con l'AP in questione trasmettano una unità di dati, supponendo che esse abbiano sempre dati in attesa di invio. 59 66 Così facendo si definisce il concetto di tasso di trasmissione ottenibile (''attainable data rate''), parametro fondamentale per l'algoritmo di associazione che viene proposto. 60 67 61 1220-1330[[BR]]68 __1220-1330__[[BR]] 62 69 ~~Amministrazione su argon.~~ 63 70 64 71 65 1500-1520(0.33h)[[BR]]72 __1500-1520__ (0.33h)[[BR]] 66 73 Punto della situazione con gnappo. 67 74 68 1520-1605(0.75h)[[BR]]69 05: L'algoritmo per il controllo dell'associazione che viene proposto tiene conto della presenza di congestioni, dal momento che il massimo tasso trasmissivo ottenibile non può che essere influenzato da questa eventualità. Propone inoltre che il client effettui rilevazioni sui carichi degli AP disponibili non solo nei momenti di necessità (non ancora associato), ma anche a intervalli regolari (già associato) per individuare alternative sempre migliori. Questo tipo di approccio risulta quantomai interessante nella prospettiva di avere a disposizione, come nel nostro caso, una molteplicità di dispositivi 802.11 .70 71 1605-1715(1.16h))[[BR]]75 __1520-1605__ (0.75h)[[BR]] 76 05: L'algoritmo per il controllo dell'associazione che viene proposto tiene conto della presenza di congestioni, dal momento che il massimo tasso trasmissivo ottenibile non può che essere influenzato da questa eventualità. Propone inoltre che il client effettui rilevazioni sui carichi degli AP disponibili non solo nei momenti di necessità (non ancora associato), ma anche a intervalli regolari (già associato) per individuare alternative sempre migliori. Questo tipo di approccio risulta quantomai interessante nella prospettiva di avere a disposizione, come nel nostro caso, una molteplicità di dispositivi 802.11 su ogni singola STA. 77 78 __1605-1715__ (1.16h))[[BR]] 72 79 06: Lo studio si propone quantomeno come la fondazione teorica di una politica di allocazione delle risorse equa min-max (''min-max fairness'') e bilanciata che intende essere la più vicina all'ottimo (perché il problema sarebbe NP-hard). 73 80 Per equità max-min si intende una situazione nella quale non vi è modo per fornire ''bandwidth'' addizionale ad un client senza doverne togliere almeno altrettanta a qualche altro. … … 75 82 76 83 == 14 Giugno 2007 == 77 1110-1235 (1.41h)[[BR]] 84 85 __1110-1235__ (1.41h)[[BR]] 78 86 06: La definizione di equità max-min è stata approfondita in tutta la sua complessità che la definizione formale esprime, facendo emergere spunti utili non alla [milestone:"Rilevamento del carico" milestone attuale] ma a possibili politiche di bilanciamento del carico, eventualmente rilevanti per la scelta dell'AP a cui associarsi. 79 87 80 1300-1330(0.50h)[[BR]]88 __1300-1330__ (0.50h)[[BR]] 81 89 06: La definizione di carico che l'articolo propone è allineata al resto dalla letteratura informatica. 82 90 Informalmente il carico dell'AP ''a'' indotto da una STA ''s'' è l'inverso del ''bitrate'' effettivo che ''s'' rileva, normalizzato rispetto allo specifico peso della STA. 83 91 Il carico di ''a'' è poi il massimo fra le due sommatorie di tutti i carichi indotti da tutte le associazioni effettive (che, cioé, producono un ''bitrate'' non nullo), la prima sui ''bitrate'' dei collegamenti AP-STA, la seconda sui ''bitrate'' del collegamento AP-!ReteEsterna. 84 92 85 1330-1347(0.28h) [[BR]]93 __1330-1347__ (0.28h) [[BR]] 86 94 Aggiornamenti su Trac: scritta la descrizione della [milestone:"Rilevamento del carico" milestone] e gli appunti sul lavoro della mattinata. 87 95 88 1420-1511(0.88h)[[BR]]96 __1420-1511__ (0.88h)[[BR]] 89 97 06: Lo studio spende energie non indifferenti (considera infatti anche situazioni che tengano presente il carico su un insieme di AP) per dimostrare con rigore teoremi e proprietà che sono indispensabili alla dimostrazione dello stretto legame che intercorre fra una scelta di associazioni bilanciate min-max e una scelta di allocazione della ''bandwidth'' che sia equa max-min. 90 98 Quest'ultimo teorema, oltre che essere sprovvisto di una dimostrazione completa, è non soddisfatto nel caso di associazioni singole. … … 94 102 Terrei quindi presente la possibiltà di riprendere in mano il documento per comprendere meglio l'algoritmo di bilanciamento (che, spaventato dalla complessità, non ho analizzato) o per mettere in dubbio l'attendibilità dei risultati delle simulazioni. 95 103 96 1511-1519(0.13h)[[BR]]97 Sincronizzazione del diario. 98 99 1519-1600(0.68h)[[BR]]104 __1511-1519__ (0.13h)[[BR]] 105 Sincronizzazione del diario. 106 107 __1519-1600__ (0.68h)[[BR]] 100 108 Ricerca e cernita di altri documenti: si aggiungono alla lista 07, 08, 09.[[BR]] 101 109 102 1620-1800(1.67h)[[BR]]110 __1620-1800__ (1.67h)[[BR]] 103 111 07: L'articolo riprende i concetti formali di 06 per elaborare una strategia ottimale per gestire le associazioni fra stazioni e i punti di accesso, astraendo completamente dalle possibili implementazioni e dai relativi problemi (reperimento delle informazioni, localizzazione del gestore ...). 104 112 [[BR]] … … 148 156 __2010-2030__ (0.33h)[[BR]] 149 157 Sincronizzazione del diario. 158 159 == 20 Giugno == 160 161 10: Si propone un modello matematico semplice ma accurato (e per questo così utilizzato) che permette di calcolare il ''throghput'' in una rete 802.11 saturata (nella quale, cioé le code di invio di ogni STA siano sempre non vuote). Partendo da un modello probabilistico che rappresenta la gestione dei periodi di ''backoff'' si procede per via analitica andando a ricavare il ''throughput'' massimo. Dato l'alto grado difficoltà del documento non mi è chiaro se il fine del documento risiede nel modello stesso o se esso sia strumento per calcoli realmente utili. A patto che le informazioni di partenza siano ricavabili o stimabili dall'ascolto sul canale, mi azzardo a dire che questo modello non sia così distante dai nostri obiettivi. 162 Una serie di simulazioni sperimentali confermano validità del modello proposto e mettono in luce come le prestazioni dipendano in misura tutt'altro che marginale dalle impostazioni della rete, in particolare dall'ampiezza iniziale della finestra di contesa (`CWmin`). 163 164 In aggiunta a questo non mi sono ben definite nemmeno le informazioni iniziali da cui il ''throughput'' sia ricavabile. 165 166 Lettura di 11 e 12: appunti cartacei. 167 168 == 21 Giugno == 169 __0905-0925__ [[BR]] 170 11: L'articolo propone 2 nuove metriche per la valutazione del carico a fini di bilanciamento di generiche reti wireless a pacchetti che siano gestite da coordinatori centrali quali bluetooth, UMTS o l'amato IEEE 802.11 (nella sua variante con PCF). 171 La prima, chiamata ''Gross Load'' intende calcolare il numero medio di trasmissioni in una cella in un dato periodi di tempo; la seconda, chiamata ''Packet Loss'' stima invece le ''performance'' a partire dal carico di ogni pacchetto, ricavato dalle probabilità di perdite di trasmissioni. 172 [[BR]] 173 12: Lo studio mira ad esprimere il numero ''n'' di stazioni concorrenti presenti in una rete 802.11 in regime DCF come funzione della probabilità di collisione. 174 Il fine è quello di riuscire a stimare ''n'' per poter adeguare intelligentemente il parametro `RTS-Treshold` per massimizzare le prestazioni. 175 176 __1002-1337__ [[BR]] 177 Punto della situazione e analisi sviluppi futuri assieme a gnappo: stesura di una lista delle informazioni elementari che potranno essere alla base delle metriche di valutazione legate al carico degli AP. 178 179 __1500-1640__ [[BR]] 180 Meeting dell'intera squadra: condivisione delle conoscenze fra i due gruppi di lavoro e revitalizzazione degli obiettivi legati alla milestone:"Roaming". 181 182 __1720-1735__ [[BR]] 183 Condivisione conoscenze con gnappo riguardo lo studio di Bianchi (10). 184 185 __1929-2002__ [[BR]] 186 Rilettura di 02 con l'individuazione di alcune sezioni interessanti. 187 188 == 22 Giugno 2007 == 189 190 __1021-1055__ [[BR]] 191 02: Come [wiki:Diario/Soujak#a11Giugno2007 precedentemente] accennato il documento propone una serie di metriche per la valutazione della qualità degli AP: anzitutto, nonostante si palesi ancora una volta l'insufficienza del solo RSSI, il parametro rientra fra i parametri considerati a causa della sua grande rilevanza. ''In secondis''propone una metrica che trovo significativa: il ritardo di trasmissione aggregaato, cioé il tempo medio che intercorre fra l'accodamento di un pacchetto e la ricezione della conferma di trasmissione a livello MAC (si suppone che sia il ''driver'' a ricevere periodicamente questa informazione direttamente dal ''firmware''). In questo modo questa misura del ritardo tiene in considerazione non solo il tasso trasmissivo nominale utilizzato per la trasmissione, ma anche i ritardi dovuti a collisioni ed errori. 192 193 __1140-__ [[BR]] 194 Sincronizzazione degli ultimi tre giorni di diario. 150 195 151 196 ---- … … 163 208 * 09 [http://ieeexplore.ieee.org/iel5/9179/29132/01313270.pdf?tp=&isnumber=&arnumber=1313270 Load Balancing in Overlapping Wireless LAN Cells] 164 209 * 10 [http://dcg.ethz.ch/members/pascal/refs/mac_2000_bianchi.pdf Performance Analysis of the IEEE 802.11 Distributed Coordination Function] 165 * 11 [http://ieeexplore.i eee.org/iel5/7828/21515/00996984.pdf Improving Load Balancing mechanisms in Wireless Packet Networks]210 * 11 [http://ieeexplore.i eee.org/iel5/7828/21515/00996984.pdf Improving Load Balancing mechanisms in Wireless Packet Networks] 166 211 * 12 [http://www.ieee-infocom.org/2003/papers/21_02.PDF Kalman Filter Estimation of the Number of Competing Terminals in an IEEE 802.11 network] 167 212
