| 4 | | == Giugno 2007 == |
| 5 | | |
| 6 | | === 4 Giugno === |
| 7 | | (2.00h)[[BR]] |
| 8 | | Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion. |
| 9 | | |
| 10 | | === 5 Giugno === |
| 11 | | (1.00h)[[BR]] |
| 12 | | Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web. |
| 13 | | |
| 14 | | === 11 Giugno === |
| 15 | | (0.40h)[[BR]] |
| 16 | | Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico. |
| 17 | | |
| 18 | | __1400-1740__[[BR]] |
| 19 | | 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. |
| 20 | | Lo studio prende in considerazione uno scenario privo di disturbi ambientali, senza coordinamento centralizzato. |
| 21 | | 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"). |
| 22 | | 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". |
| 23 | | La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate. |
| 24 | | |
| 25 | | __1800-1820__[[BR]] |
| 26 | | __1900-1920__[[BR]] |
| 27 | | 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. |
| 28 | | |
| 29 | | __1920-2000__[[BR]] |
| 30 | | __0910-0930__[[BR]] |
| 31 | | 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''. |
| 32 | | |
| 33 | | === 12 Giugno === |
| 34 | | __1000-1020__ (0.33h)[[BR]] |
| 35 | | Sincronizzazione del diario. |
| 36 | | |
| 37 | | __1030-1100__ (0.50h)[[BR]] |
| 38 | | Punto della situazione assieme a gnappo. |
| 39 | | |
| 40 | | __1120-1155__ (0.58h)[[BR]] |
| 41 | | 03: In appendice è presente un'interessante calcolo dell'impatto degli errori di trasmissione sulle prestazioni, calcolando diligentemente i dettagli relativi ai backoff incrementali. |
| 42 | | |
| 43 | | __1210-1310__ (1.00h)[[BR]] |
| 44 | | 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. |
| 45 | | 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. |
| 46 | | Questa ''bandwidth'' e` fortemente influenzata dalla dimensione dei ''frame'' e viene quindi normalizzata rispetto ad un frame di riferimento per avere una misura da essa indipendente. |
| 47 | | Lo studio proseguirebbe su politiche di ammissione di una STA in un BSS, formalizzando il concetto di proporzione del tempo del canale (CTP, ''Channel Time Proportion'') di un determinato flusso dati, ottenibile dal rapporto fra la ''bandwitdth'' direttamente richiesta dal flusso e la ''bandwitdth'' disponibile appena citata. |
| 48 | | I concetti appena descritti appaiono come spunti piuttosto rilevanti ai nostri fini. |
| 49 | | |
| 50 | | __1450-1617__ (0.45h)[[BR]] |
| 51 | | Ricerche ulteriori. |
| 52 | | |
| 53 | | __1650-1720__ (0.33h)[[BR]] |
| 54 | | 05: L'articolo propone una algoritmo di controllo della associazione (lato client) che si configura come erede degli algoritmi precedentemente proposti da altri studi. |
| 55 | | |
| 56 | | === 13 Giugno === |
| 57 | | __0900-0910__ (0.16h)[[BR]] |
| 58 | | Approfondimento di 04. |
| 59 | | |
| 60 | | __1000-1025__ (0.41h)[[BR]] |
| 61 | | Sincronizzazione del diario. |
| 62 | | |
| 63 | | __1025-1140__ (1.25h)[[BR]] |
| 64 | | 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. |
| 65 | | 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. |
| 66 | | 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. |
| 67 | | 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. |
| 68 | | Così facendo si definisce il concetto di tasso di trasmissione ottenibile (''attainable data rate''), parametro fondamentale per l'algoritmo di associazione che viene proposto. |
| 69 | | |
| 70 | | __1220-1330__[[BR]] |
| 71 | | ~~Amministrazione su argon.~~ |
| 72 | | |
| 73 | | |
| 74 | | __1500-1520__ (0.33h)[[BR]] |
| 75 | | Punto della situazione con gnappo. |
| 76 | | |
| 77 | | __1520-1605__ (0.75h)[[BR]] |
| 78 | | 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à. |
| 79 | | 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. |
| 80 | | 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. |
| 81 | | |
| 82 | | __1605-1715__ (1.16h))[[BR]] |
| 83 | | 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). |
| 84 | | 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. |
| 85 | | Lo studio formalizza in maniera rigorosa il concetto di carico di un AP. |
| 86 | | |
| 87 | | === 14 Giugno === |
| 88 | | |
| 89 | | __1110-1235__ (1.41h)[[BR]] |
| 90 | | 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. |
| 91 | | |
| 92 | | __1300-1330__ (0.50h)[[BR]] |
| 93 | | 06: La definizione di carico che l'articolo propone è allineata al resto dalla letteratura informatica. |
| 94 | | 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. |
| 95 | | 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. |
| 96 | | |
| 97 | | __1330-1347__ (0.28h) [[BR]] |
| 98 | | Aggiornamenti su Trac: scritta la descrizione della [milestone:"Rilevamento del carico" milestone] e gli appunti sul lavoro della mattinata. |
| 99 | | |
| 100 | | __1420-1511__ (0.88h)[[BR]] |
| 101 | | 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. |
| 102 | | Quest'ultimo teorema, oltre che essere sprovvisto di una dimostrazione completa, è non soddisfatto nel caso di associazioni singole. |
| 103 | | [[BR]] |
| 104 | | L'articolo prosegue per strade che mi sono parse allontanarsi sempre più dai nostri interessi, ma tengo a sottolineare i risultati che gli autori hanno ottenuto durante una simulazione di confronto fra le più note politiche di gestione dell'associazione. |
| 105 | | Lo schema proposto non solo supera di un 20% il ''throughput'' del metodo SSF (''Strongest Signal First''), intuitivamente lontano dall'ottimo, ma arriva al __triplo__ di quello di LLF (''Least Loaded First'')! |
| 106 | | 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. |
| 107 | | |
| 108 | | __1511-1519__ (0.13h)[[BR]] |
| 109 | | Sincronizzazione del diario. |
| 110 | | |
| 111 | | __1519-1600__ (0.68h)[[BR]] |
| 112 | | Ricerca e cernita di altri documenti: si aggiungono alla lista 07, 08, 09.[[BR]] |
| 113 | | |
| 114 | | __1620-1800__ (1.67h)[[BR]] |
| 115 | | 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 ...). |
| 116 | | [[BR]] |
| 117 | | 08: L'articolo propone un algoritmo dinamico di bilanciamento di carico che si fonda, a differenza di tutti gli altri studi finora analizzati, proprio sul valore di RSSI. |
| 118 | | Il problema viene definito informalmente come l'individuazione di uno schema di associazioni tali che l'RSSI medio sia massimizzato e le variazioni nel RSSI medio di ogni AP e nel numero di STA associate ad ogni AP siano minimizzate. |
| 119 | | Dal momento che si propongono cambiamenti al comportamento degli AP, questo studio resta interessante per la sua originalità nei parametri considerati nella gestione delle associazioni. |
| 120 | | [[BR]] |
| 121 | | Una riflessione che mi sorge spontanea è sul legame che intercorre fra l'RSSI di una STA presso un AP e la banda effettivamente resa disponibile al medesimo AP. Credo che solo sviscerando questa relazione ci sarà possibile individuare dei parametri di valutazione che siano un buon compromesso fra effittività e non-invasività. |
| 122 | | [[BR]] |
| 123 | | 09: Lo studio propone una strategia di bilanciamento del carico implementata a livello di AP, tramite frequenti comunicazioni fra di essi attraverso una dorsale Ethernet che si suppone li colleghi. |
| 124 | | Al di là della specificità delle ipotesi, ciò che colgo come interessante è il fatto che anche qui si sia scelto come metrica del carico degli AP il ''throughput'' (invece del numero di utenti, G. Bianchi, I. Tinnirello, "Kalman Filter Estimation of the Number of Cometing Terminals in an IEEE 802.11 Network", o della quantità di traffico, G. Bianchi, I. Tinnirello, "Improving Load Balancing mechanisms in Wireless Packet Networks"). |
| 125 | | |
| 126 | | === 16 giugno === |
| 127 | | |
| 128 | | __1250-1411__ (1.35h) [[BR]] |
| 129 | | Revisione, formalizzazione e stesura dei pensieri di ieri. |
| 130 | | Prescindendo dalle modalità con le quali questo parametro venga valutato nella effettiva scelta di associazione (sto pensando a politiche di bilanciamento del |
| 131 | | carico in maniera equa), il carico del BSS rimane l'oggetto del[milestone:"Bilanciamento del carico" la milestone di cui mi occupo]. |
| 132 | | La definizione che più mi è parsa corretta e indicativa è quella contenuta in 05 e 06: il carico è inversamente proporzionale al ''datarate''. |
| 133 | | Purtroppo però questa informazione non è direttamente disponibile a meno che non si prendano in considerazione BSS che aderiscano a 802.11e (peraltro non ancora analizzato né da me, né da [wiki:Diario/Gnappo gnappo]) o a meno che non si effettuino dei test effettivi di comunicazione, rinunciando molto probabilmente alla scalabilità che si intravede fra gli obiettivi della soluzione ricercata. |
| 134 | | Ciò detto risulta evidente la necessità di andare a ricercare elementi che siano calcolabili da ogni STA grazie ad azioni di sniffing sui vari canali per poi andare a calcolare una stima del ''datarate'' (e quindi del carico). |
| 135 | | L'adeguatezza di questi fattori e dei calcoli che conducono alla stima può essere verificata per via sperimentale con uno sforzo che rimane considerevole. |
| 136 | | |
| 137 | | Riporto quindi di seguito un elenco di tutte quelle pratiche che risultano |
| 138 | | essere interessanti. |
| 139 | | * Misurazione del tempo di accodamento dei ''beacon'' da parte dell'AP (00). |
| 140 | | * Calcolo dell' ''error rate'' delle trasmissioni su un determinato canale (00). |
| 141 | | * Misurazione del ''throughput'' medio della STA associate all'AP che si sta analizzando. |
| 142 | | * ''Bit-rate'' nominale delle STA associate all'AP che si sta analizzando. |
| 143 | | * Misurazione del ''datarate'' effettivo tramite invii diretti (ed invasivi). |
| 144 | | * Reperimento di informazioni dai campi aggiuntivi di 802.11e. |
| 145 | | |
| 146 | | __1411-1512__ (1.01h)[[BR]] |
| 147 | | Punto della situazione con gnappo: aggiornamenti, chiarimenti e sviluppi futuri. |
| 148 | | |
| 149 | | __1700-1800__ (1.00h) [[BR]] |
| 150 | | Ricerca di ulteriore documentazione e suddivisione dei nuovi documenti. |
| 151 | | |
| 152 | | === 19 Giugno === |
| 153 | | |
| 154 | | __1230-1300__ (0.50h)[[BR]] |
| 155 | | Individuazione e sistemazione errori nei permessi del portale Trac. |
| 156 | | |
| 157 | | __1300-1336__ (0.60h)[[BR]] |
| 158 | | Punto della situazione e inizio lettura di 10. |
| 159 | | |
| 160 | | __2010-2030__ (0.33h)[[BR]] |
| 161 | | Sincronizzazione del diario. |
| 162 | | |
| 163 | | === 20 Giugno === |
| 164 | | |
| 165 | | 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). |
| 166 | | Partendo da un modello probabilistico che rappresenta la gestione dei periodi di ''backoff'' si procede per via analitica andando a ricavare il ''throughput'' massimo. |
| 167 | | 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. |
| 168 | | 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. |
| 169 | | 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`). |
| 170 | | |
| 171 | | In aggiunta a questo non mi sono ben definite nemmeno le informazioni iniziali da cui il ''throughput'' sia ricavabile. |
| 172 | | |
| 173 | | Lettura di 11 e 12: appunti cartacei. |
| 174 | | |
| 175 | | === 21 Giugno === |
| 176 | | __0905-0925__ [[BR]] |
| 177 | | 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). |
| 178 | | 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. |
| 179 | | [[BR]] |
| 180 | | 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. |
| 181 | | Il fine è quello di riuscire a stimare ''n'' per poter adeguare intelligentemente il parametro `RTS-Treshold` per massimizzare le prestazioni. |
| 182 | | |
| 183 | | __1002-1337__ [[BR]] |
| 184 | | 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. |
| 185 | | |
| 186 | | __1500-1640__ [[BR]] |
| 187 | | Meeting dell'intera squadra: condivisione delle conoscenze fra i due gruppi di lavoro e revitalizzazione degli obiettivi legati alla milestone:"Roaming". |
| 188 | | |
| 189 | | __1720-1735__ [[BR]] |
| 190 | | Condivisione conoscenze con gnappo riguardo lo studio di Bianchi (10). |
| 191 | | |
| 192 | | __1929-2002__ [[BR]] |
| 193 | | Rilettura di 02 con l'individuazione di alcune sezioni interessanti. |
| 194 | | |
| 195 | | === 22 Giugno === |
| 196 | | |
| 197 | | __1021-1055__ [[BR]] |
| 198 | | 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. |
| 199 | | ''In secundis''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''). |
| 200 | | 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. |
| 201 | | |
| 202 | | __1140-1248__[[BR]] |
| 203 | | Sincronizzazione degli ultimi tre giorni di diario. |
| 204 | | |
| 205 | | __1250-1320__[[BR]] |
| 206 | | Installazione locale di KDissert. |
| 207 | | |
| 208 | | === 25 Giugno === |
| 209 | | __1023-1350__ [[BR]] |
| 210 | | Punto della situazione con gnappo: confronto, chiarimento e decisione della |
| 211 | | prima sostanziosa parte della soluzione. |
| 212 | | |
| 213 | | __1501-1610__ [[BR]] |
| 214 | | Lavoro con gnappo: formalizzazione della soluzione della mattinata (e della |
| 215 | | precedente settimana) e in generale delle idee che la riguardano. |
| 216 | | |
| 217 | | __1610-1813__ [[BR]] |
| 218 | | Ancora con gnappo: sviluppi futuri riguardo la presenza della STA all'interno |
| 219 | | dello scenario finora considerato. |
| 220 | | |
| 221 | | __1955-2020__ [[BR]] |
| 222 | | Rilettura dei documenti {06, 07, 09} alla luce della distinzione fra gli obiettivi di individuazione del throughput ottenibile e di bilanciamento del carico. |
| 223 | | Nell'eventualità di una milestone dedicata a politiche di bilanciamento, mi pare che tutte le considerazioni finora fatte per definire una stima della bandwidth ottenibile siano riutilizzabili, dal momento che passano per una stima del carico dei BSS. |
| 224 | | |
| 225 | | === 26 Giugno === |
| 226 | | __1005-1035__[[BR]] |
| 227 | | Rilettura del [wiki:Diario/Gnappo diario di gnappo] e della seconda mezza dozzina dei miei documenti alla ricerca di nuovi spunti. |
| 228 | | Sorge una domanda ancora non presa in considerazione: quanto sono le conclusioni sinora tratte dipendenti dalla presenza del solo DCF?[[BR]] |
| 229 | | Viaggi mentali su una modalità lasca per innescare il cambio di BSS (secondo i parametri di valutazione in oggetto del presente studio) al fine di scongiurare un eterno e continuo ''handoff''. |
| 230 | | |
| 231 | | __1114-1126__[[BR]] |
| 232 | | Aggiornamento e sincronizzazione del diario. |
| 233 | | |
| 234 | | __1126-1400__ __1600-1654__ [[BR]] |
| 235 | | Con gnappo: |
| 236 | | * caricamento della [source:CaricoBSS/caricobss.kdi mappa mentale] che sta guidando le nostre attività; |
| 237 | | * ulteriori chiarimenti riguardo le modalità di considerazione della presenza della STA associanda; |
| 238 | | * abbozzo di metrica per la aggregazione del carico teorico ed effettivo all'interno della stima; |
| 239 | | * formalizzazione delle questioni aperte e del sottoinsieme da proporre a Ghini; |
| 240 | | * aggiornamento della [source:CaricoBSS/caricobss.kdi mappa mentale]; |
| 241 | | * stesura del diario della giornata. |
| 242 | | |
| 243 | | === 27 Giugno === |
| 244 | | |
| 245 | | __1320-1510__ [[BR]] |
| 246 | | Con gnappo: affinamento del modello teorico approfondendo le cause di calo prestazionale in termini di throughput rispetto ai valori nominali (ritrasmissioni e attese di backoff), individuandone successivamente fonti per la loro stima. |
| 247 | | |
| 248 | | __1820-2000__ [[BR]] |
| 249 | | Incontro con il professor Ghini: chiarimento di alcuni dettagli riguardo lo scenario d'opera. |
| 250 | | |
| 251 | | === 28 Giugno === |
| 252 | | __1120-1240__[[BR]] |
| 253 | | Meeting squadra: condivisione delle conoscenze (in particolar modo riguardanti la milestone:"Rilevamento del carico"), consigli e suggerimenti utili al proseguimento della milestone:Roaming, chiarimenti riguardo gli sviluppi futuri dell'intero tirocinio e i relativi tempi. |
| 254 | | |
| 255 | | __1740-1811__ [[BR]] |
| 256 | | Con gnappo: chiarimenti riguardo le prossime raffinazioni del modello teorico. |
| 257 | | |
| 258 | | __1958-2020__[[BR]] |
| 259 | | Appunti nella mappa mentale sulle ultime parole scambiate con gnappo, per timore di dimenticare. |
| 260 | | |
| 261 | | === 29 Giugno === |
| 262 | | __1430-1500__[[BR]] |
| 263 | | Rilettura di (e riflessioni su) alcuni documenti, in particolare 06, 07, 09. |
| 264 | | |
| 265 | | __1620-1835__[[BR]] |
| 266 | | Aggiornamento del diario.[[BR]] |
| 267 | | Con gnappo: analisi del nodo ancora da sciogliere (determinazione accurata del throughput teorico delle STA già associate). |
| 268 | | Lettura accurata delle parti ancora poco chiare di gnp02, qualche questione rimane insoluta. |
| 269 | | Conseguente individuazione dei nuovi obiettivi a breve termine (#1, #2, #3). |
| 270 | | Breve indagine riguardo il significato di RSSI e SNR (#2).[[BR]] |
| 271 | | Apertura dei ticket e aggiornamento del diario. |
| 272 | | |
| 273 | | === 30 Giugno === |
| 274 | | __1316-1340__[[BR]] |
| 275 | | Rapida occhiata alla tesi di Benatti e Borsari (Ghn00). |
| 276 | | |
| 277 | | == Luglio 2007 == |
| 278 | | |
| 279 | | === 2 Luglio === |
| 280 | | __1830-1940__[[BR]] |
| 281 | | Ghn00: la sezione riguardante le politiche di valutazione della qualità dei BSS mette in luce un approccio quantomai approssimativo e pragmatico al calcolo del punteggio di qualità, apparentemente senza alcuna base teorica. |
| 282 | | Un primo particolare interessante, seppur marginalmente, è che gli autori, consci della grande portabilità a cui mira il progetto MEW (Ghn01), tengono in considerazione la possibilità di utilizzare dispositivi sprovvisti della modalità monitor, adottando in quel caso una politica differente.[[BR]] |
| 283 | | Una altra questione sollevata dagli autori che vale la pena menzionare è l'instabilità di uno dei parametri da loro utlizzati, RXQ. |
| 284 | | Si tratta dell'indice più importante utilizzato per le valutazioni eseguite con il supporto del ''monitor mode'' ed è il rapporto fra il numero dei frame catturati e il numero dei frame transitati sul canale (frame catturati + frame persi). |
| 285 | | Questo valore, la cui accuratezza ci si aspetterebbe essere direttamente proporzionale rispetto al tempo di ascolto sul canale, risulta invece essere parecchio instabile per cause che mi sono ancora ignote. |
| 286 | | Dal momento che un simile calcolo dei frame transitati è alla base del calcolo del ''throughput'' effettivo che intendiamo effetuare, mi occuperò quanto prima di ricercare le motivazioni di questa anomalia. |
| 287 | | |
| 288 | | __2144-2208__[[BR]] |
| 289 | | Lettura della prima parte dell'articolo su MEW (Ghn01). |
| 290 | | |
| 291 | | === 3 Luglio === |
| 292 | | __1130-1216__[[BR]] |
| 293 | | Formalizzazione e digitalizzazione degli appunti cartacei presi negli ultimi giorni (con rilettura di alcuni passaggi chiave di Ghn00). |
| 294 | | |
| 295 | | __1216-1220__[[BR]] |
| 296 | | Aggiunta di due macro in fondo alla presente. |
| 297 | | |
| 298 | | __1220-1255__[[BR]] |
| 299 | | Aggiornamento riguardo i ticket in consegna:[[BR]] |
| 300 | | #3: Gli ''wireless tools'' offrono tre informazioni legate alla qualità della connessione: qualità, livello del segnale, livello del rumore. Dalla differenza degli ultimi due è possibile ricavare il famoso SNR (''Signal to Noise Ratio''), mentre il primo esprime due valori (graficamente separati da una barra nel caso si interroghi `iwlist`): l'RSSI e il rumore di fondo (''noise floor'').[[BR]] |
| 301 | | #2: Mentre il significato di RSN mi appare piuttosto chiaro, RSSI rimane piuttosto fumoso. Quest'ultimo viene inoltre segnalato dal driver del dispositivo con valori in scale diverse a seconda del produttore (così riporta [http://en.wikipedia.org/wiki/RSSI wikipedia:RSSI] ma anche Ghn00). |
| 302 | | |
| 303 | | === 4 Luglio === |
| 304 | | __1530-1600__[[BR]] |
| 305 | | con gnappo: punto della situazione intorno alla calcolabilità del ''bitrate'' della stazione associanda in maniera portabile e quantomeno accurata. |
| 306 | | |
| 307 | | __1630-1635__[[BR]] |
| 308 | | Aggiornamento del diario. |
| 309 | | |
| 310 | | __1700-1720__[[BR]] |
| 311 | | Con gnappo: altri chiarimenti per migliorare la padronanza degli obiettivi da raggiungere. |
| 312 | | |
| 313 | | __1720-1900__[[BR]] |
| 314 | | Riflessioni ad alto livello[[BR]] |
| 315 | | Anzitutto credo che la stima della ''bandwidth'' ottenibile che intendiamo effettuare non possa limitarsi al livello MAC proprio di 802.11 come si era esplicitato giorni fa. Il motivo è duplice: da un lato condurrebbe ad errori poiché nei calcoli che prospettiamo di fare si sta tenendo conto di fattori propri del protocollo, da un altro questo non sembra condurre molto lontano dal datarate nominale del collegamento. Questa considerazione conduce alla serie di fattori (in buona parte già affrontati assieme a gnappo in maniera meno organica) che intervengono nel generare il carico addizionale implicabile al protocollo. Creazione di una nuova mappa mentale contenente una parziale formalizzazione di tutti gli ''overhead'' dovuti allo strato MAC, sperabilemente utile alle successive indagini. |
| 316 | | |
| 317 | | __1853-1900__[[BR]] |
| 318 | | Aggiornamento del diario. |
| 319 | | |
| 320 | | === 5 Luglio === |
| 321 | | |
| 322 | | __1300-1715__[[BR]] |
| 323 | | Gnappo |
| 324 | | |
| 325 | | === 6 Luglio === |
| 326 | | |
| 327 | | __1150-1400__, __1630-1830__[[BR]] |
| 328 | | Gnappo |
| 329 | | |
| 330 | | === 7 Luglio === |
| 331 | | __1048-1345__[[BR]] |
| 332 | | Gnappo |
| 333 | | |
| 334 | | === 9 Luglio === |
| 335 | | __1130-1430__, __1620-1830__[[BR]] |
| 336 | | Gnappo |
| 337 | | |
| 338 | | __2000-2015__[[BR]] |
| 339 | | Approfondimenti e riflessioni. |
| 340 | | |
| 341 | | === 10 Luglio === |
| 342 | | __1025-1035__[[BR]] |
| 343 | | Approfondimenti e riflessioni. |
| 344 | | |
| 345 | | __1120-1400__[[BR]] |
| 346 | | Gnappo |
| 347 | | |
| 348 | | __1735-1845__ [[BR]] |
| 349 | | Gnappo |
| 350 | | |
| 351 | | === 11 Luglio === |
| 352 | | |
| 353 | | __1745-1900__[[BR]] |
| 354 | | Gnappo |
| 355 | | Revisione documentazione sul supporto al roaming (Roma e Zeratul) |
| 356 | | |
| 357 | | === 12 Luglio === |
| 358 | | |
| 359 | | __1130-1300__[[BR]] |
| 360 | | Incontro con l'intero team. |
| 361 | | |
| 362 | | __1430-1640__[[BR]] |
| 363 | | Gnappo |
| 364 | | |
| 365 | | === 13 Luglio === |
| 366 | | __????-1645__[[BR]] |
| 367 | | Gnappo |
| 368 | | |
| 369 | | === 14 Luglio === |
| 370 | | __1058-1120__[[BR]] |
| 371 | | Gnappo |
| 372 | | |
| 373 | | === 16 Luglio === |
| 374 | | |
| 375 | | __1258-????__ |
| 376 | | Con gnappo |
| 377 | | |
| 378 | | === 17 Luglio === |
| 379 | | |
| 380 | | __1235-1605__[[BR]] |
| 381 | | Con gnappo |
| 382 | | |
| 383 | | __1645-1732__[[BR]] |
| 384 | | Con gnappo: impostazione del documento e del pacchetto `algorithmic`o |
| 385 | | |
| 386 | | __1732-1900__[[BR]] |
| 387 | | Con gnappo. |
| 388 | | |
| 389 | | === 19 Luglio === |
| 390 | | __1120-1400__ __1440-????__[[BR]] |
| 391 | | Con gnappo: affrettata conclusione dei lavori in vista della pausa estiva. |
| 392 | | |
| 393 | | === 24 Luglio === |
| 394 | | __1322-1542__[[BR]] |
| 395 | | Approfondimenti e chiarimenti sparsi nella mappa mentale, nell'ottica di produrre un html decente da inviare al Prof. Ghini.[[BR]] |
| 396 | | Invio dell'ultima versione della mappa al deposito SVN.[[BR]] |
| 397 | | Aggiornamento (finalmente!) del diario. |
| 398 | | |
| 399 | | == Ottobre 2007 == |
| 400 | | |
| 401 | | === 5 Ottobre === |
| 402 | | __1715-1945__[[BR]] |
| 403 | | Incontro con il Prof. Ghini: punto della situazione e sviluppi futuri prima della conclusione. |
| 404 | | |
| 405 | | === 9 Ottobre === |
| 406 | | __1445-1710__[[BR]] |
| 407 | | Videoconferenza con gnappo (video e audio su SIP, desktop su VNC). Ripresa dei lavori: riletture della documentazione prodotta in precedenza, riflessioni, considerazioni sul livello di compiutezza del lavoro, accordi sugli incontri successivi. |
| 408 | | |
| 409 | | __1710-1740__[[BR]] |
| 410 | | Formattazione in LaTeX di un paio di formule.[[BR]] |
| 411 | | Aggiornamento deposito SVN.[[BR]] |
| 412 | | Aggiornamento Diario.[[BR]] |
| 413 | | |
| 414 | | === 10 Ottobre === |
| 415 | | |
| 416 | | __1500-1740__[[BR]] |
| 417 | | Incontro con gnappo.[[BR]] |
| 418 | | Considerazioni sulle questioni ancora aperte e sull'eventuale lavoro da svolgere prima della stesura della relazione: si investirà ancora un'oretta per definire meglio il modello matematico. Domande sulla simmetria fra ''datarate'' in trasmissione e ricezione. Aggiornamento del diario. |
| 419 | | |
| 420 | | __1740-1745__[[BR]] |
| 421 | | Aggiornamento del deposito subversion. |
| 422 | | |
| 423 | | === 11 Ottobre === |
| 424 | | __1130-1330__ __1345-1430__[[BR]] |
| 425 | | Lavoro con gnappo.[[BR]] |
| 426 | | Ulteriori chiarimenti sul concetto di carico: |
| 427 | | * rilevanza non solo per il calcolo del ''throughput'' ottenibile, ma anche (in qualche modo) per calcolare la latenza del canale, intesa come ritardo introdotto dalla presenza delle varie STA; filosofie sul significato di ''bandwidth'', di ''troughput'' e di latenza |
| 428 | | * formalizzazione precisa e definitiva del carico (pesato) della stazione s: `l_{s}={\frac{w_{s}}{r_{s}}` |
| 429 | | * analisi della possibilità di inserimento nel modello matematico di un coefficente di attività (da moltiplicare al carico pesato), in grado di descrivere il grado di partecipazione di ogni stazione (rimembranze di conclusioni fatte a Luglio). |
| 430 | | |
| 431 | | __1500-1530__[[BR]] |
| 432 | | Trascrizione di qualche appunto nel diario e successivo aggiornamento. |
| 433 | | |
| 434 | | __1530-1550__[[BR]] |
| 435 | | Aggiornamento del deposito subversion: [7] e [8]. |
| 436 | | |
| 437 | | __1625-1850__[[BR]] |
| 438 | | Con gnappo.[[BR]] |
| 439 | | Analisi del modello matematico chiarendo il concetto di peso del carico: è la quantità di dati inviati in media da una determinata STA in un giro. |
| 440 | | Proprio il concetto di "giro", inteso come tempo medio nel quale tutte le STA che hanno voglia di trasmettere ne hanno occasione, è difficilmente calcolabile. |
| 441 | | Aumentare in questa maniera la complessità del modello rischia, in generale, di allontanarlo dagli obiettivi di stabilità ed affidabilità nel definire un comportamento "di massima" della rete che si sta analizzando. |
| 442 | | Si è sottolineato anche la versatilità del modello, in grado, grazie all'eventuale presenza di parametri configurabili, di descrivere situazioni diverse dalla realtà: definire casi limite o prevedere l'andamento di certe variabili in gioco. |
| 443 | | |
| 444 | | === 12 Ottobre === |
| 445 | | __1240-1347__ __1415-1530__ __1640-1710__ __1740-2010__[[BR]] |
| 446 | | Con gnappo.[[BR]] |
| 447 | | Lavori per la stesura documento di tirocinio: definiti i contenuti del primo terzo del documento.[[BR]] |
| 448 | | Aggiornamento parziale del deposito subversion [9]. |
| 449 | | |
| 450 | | === 15 Ottobre === |
| 451 | | __1050-1315__ |
| 452 | | Con gnappo.[[BR]] |
| 453 | | Lavori per la stesura documento di tirocinio: iniziata la sezione relativa al modello matematico. |
| 454 | | |
| 455 | | __1320-1330__[[BR]] |
| 456 | | Aggiornamento del deposito subversion [10] e del diario. |
| 457 | | |
| 458 | | __1550-1737__[[BR]] |
| 459 | | Con gnappo.[[BR]] |
| 460 | | Lavori per la stesura documento di tirocinio: quasi conclusa la sezione relativa al modello matematico. |
| 461 | | |
| 462 | | __1748-1800__[[BR]] |
| 463 | | Aggiornamento del deposito subversion [11] e aggiornamento del diario. |
| 464 | | |
| 465 | | === 16 Ottobre === |
| 466 | | __1108-1305__[[BR]] |
| 467 | | Lavoro con gnappo per la stesura della relazione: |
| 468 | | * paragrafi sui valori ricavabili dal modello matematico; |
| 469 | | * qualche refactoring nel modello matematico. |
| 470 | | |
| 471 | | __1340-1346__[[BR]] |
| 472 | | Aggiornamento del diario (solo locale). |
| 473 | | |
| 474 | | __1545-1700__[[BR]] |
| 475 | | Lavoro con gnappo per la stesura della relazione: |
| 476 | | * reperimento sorgente LaTeX smarrito; |
| 477 | | * paragrafi sui valori ricavabili dal modello matematico; |
| 478 | | * chiarimenti concettuali qua e là. |
| 479 | | |
| 480 | | __2125-2315__[[BR]] |
| 481 | | Lavoro con gnappo per la stesura della relazione: |
| 482 | | * conclusa la sezione sul modello matematico; |
| 483 | | * iniziata la sezione sul simulatore (necessita di qualche riorganizzazione dei contenuti). |
| 484 | | |
| 485 | | __2320-2325__[[BR]] |
| 486 | | Aggiornamento del deposito subversion [12] e del diario. |
| 487 | | |
| 488 | | === 17 Ottobre === |
| 489 | | __1125-1340__[[BR]] |
| 490 | | Lavoro con gnappo per la stesura della relazione: |
| 491 | | * migliorata e completata l'introduzione al modello matematico; |
| 492 | | * parziale organizzazione dei contenuti sulla simulazione. |
| 493 | | |
| 494 | | __1445-1755__[[BR]] |
| 495 | | Lavoro con gnappo per la stesura della relazione: |
| 496 | | * chiarimenti sui problemi legati alla simulazione; |
| 497 | | * rilevazione della mancanza di un'importante assunzione sulla tipologia di rete considerata: single-hop; |
| 498 | | * ulteriori (quando finiranno?) considerazioni sul concetto di carico: l'AP non ne genera direttamente e le trasmissioni AP->STA producono carico per la STA; conseguentemente: |
| 499 | | * il modello matematico aggiungerà al carico della stazione il carico derivante dalle ricezioni (sotto assunzioni di saturazioni pari ad 1/numero stazioni); |
| 500 | | * la simulazione inserirò anche il traffico in download (AP->STA). Si terrà presente che l'AP ha gli stessi diritti delle altre STA nell'aggiudicarsi gli accessi e che ogni STA ha diritto ad almeno 1/n degli accessi in download (riapplicazione del concetto di giro, usando una coda delle trasmissione gia' effettuate dall'AP). |
| 501 | | * aggiornamento del diario. |
| 502 | | |
| 503 | | __1844-1930__[[BR]] |
| 504 | | Formattazione documento LaTeX: algoritmo per la ripartizione degli accessi. |
| 505 | | |
| 506 | | === 18 Ottobre === |
| 507 | | __0810-0835__[[BR]] |
| 508 | | Formattazione documento LaTeX: algoritmo per la ripartizione degli accessi. |
| 509 | | |
| 510 | | __0925-1200__[[BR]] |
| 511 | | Lavoro con gnappo: |
| 512 | | * aggiornamento del deposito svn [13]; |
| 513 | | * ricerca del Prof. Ghini, spedizione email, accordi per appuntamento. |
| 514 | | * individuazione delle prossime attività; |
| 515 | | * ~~chiacchiere sulla conclusione del tirocinio e altro~~ |
| 516 | | |
| 517 | | __1400-1451__[[BR]] |
| 518 | | Formattazione documento LaTeX: algoritmo per la ripartizione degli accessi. |
| 519 | | |
| 520 | | __1500-1615__[[BR]] |
| 521 | | Incontro assieme a gnappo col Prof. Ghini sulla possibilità di conclusione abbreviata dei lavori: esito negativo; |
| 522 | | |
| 523 | | __1635-1905__[[BR]] |
| 524 | | Lavoro con gnappo: |
| 525 | | * aumento della motivazione di gnappo (3 minuti); |
| 526 | | * programmazione e valutazione carichi delle prossime attività; |
| 527 | | * adeguamento della definizione di carico per il modello matematico. |
| 528 | | |
| 529 | | === 19 Ottobre === |
| 530 | | __0955-1340__[[BR]] |
| 531 | | Lavoro con gnappo: |
| 532 | | * rilevazione della necessità di meglio definire il concetto di latenza: analisi del problema; |
| 533 | | * discussioni sulla gestione del progetto; |
| 534 | | * revisione del concetto di latenza definendo adeguatamente la "downlink latency" e la "uplink latency"; |
| 535 | | |
| 536 | | __1600-1838__[[BR]] |
| 537 | | Lavoro con gnappo: |
| 538 | | * ridefinizione della latenza; |
| 539 | | * revisione della formalizzazione del carico; |
| 540 | | * scelta di un formalismo adeguato per la presentazione del modello matematico. |
| 541 | | |
| 542 | | __1929-2005__[[BR]] |
| 543 | | Iniziata la digitalizzazione degli appunti cartacei presi il 19 Ottobre, direttamente formattati con LaTeX. |
| 544 | | |
| 545 | | === 21 Ottobre === |
| 546 | | __1655-1743__[[BR]] |
| 547 | | Completata la digitalizzazione degli appunti cartacei presi il 19 Ottobre, direttamente formattati con LaTeX. Aggiunta una prova d'uso dell'ambiente `theorem`.[[BR]] |
| 548 | | Aggiornamento del diario e del deposito subversion [14]. |
| 549 | | |
| 550 | | === 22 Ottobre === |
| 551 | | __1000-1145__ __1230-1345__[[BR]] |
| 552 | | Lavoro con gnappo: |
| 553 | | * pianificazione attività della giornata; |
| 554 | | * inizio della stesura della sezione dedicata alla simulazione; |
| 555 | | * aggiornamento locale del diario. |
| 556 | | |
| 557 | | |
| 558 | | |
| 559 | | |
| 560 | | |
| 561 | | |
| 562 | | |
| 563 | | |
| 564 | | |
| 565 | | |
| 566 | | |
| 567 | | |
| 568 | | |
| 569 | | |
| 570 | | |
| 571 | | |
| 572 | | |
| 573 | | |
| 574 | | |
| 575 | | |
| 576 | | |
| 577 | | |
| 578 | | |
| 579 | | |
| 580 | | |
| 581 | | |
| 582 | | |
| 583 | | |
| 584 | | |
| 585 | | |
| 586 | | |
| 587 | | |
| 588 | | |
| 589 | | |
| 590 | | __1545-1832__[[BR]] |
| 591 | | Lavoro con gnappo sulla sezione dedicata alla simulazione: |
| 592 | | * aggiunta di necessari fondamenti teorici; |
| 593 | | * introduzione all'algoritmo (non conclusa). |
| 594 | | Aggiornamento locale del diario. |
| 595 | | |
| 596 | | === 23 Ottobre === |
| 597 | | __0955-1005__[[BR]] |
| 598 | | Aggiornamento del diario e del deposito subversion [15]. |
| 599 | | |
| 600 | | __1005-1400__[[BR]] |
| 601 | | Lavoro con gnappo sulla sezione dedicata alla simulazione: |
| 602 | | * riorganizzazione dei contenuti necessari all'esposizione dell'algoritmo; |
| 603 | | * partizione concettuale dell'algoritmo; |
| 604 | | * revisione e formattazione LaTeX della prima fase dell'algoritmo (una disputa ha allungato i tempi); |
| 605 | | |
| 606 | | __1515-1700__[[BR]] |
| 607 | | Lavoro con gnappo sulla sezione dedicata alla simulazione: |
| 608 | | * revisione e formattazione LaTeX della seconda fase dell'algoritmo; |
| 609 | | * revisione della terza fase dell'algoritmo. |
| 610 | | |
| 611 | | __1710-1825__[[BR]] |
| 612 | | Aggiornamento locale del diario;[[BR]] |
| 613 | | Lavoro sulla sezione dedicata alla simulazione per la formattazione della terza fase dell'algoritmo. |
| 614 | | |
| 615 | | __1925-2008__[[BR]] |
| 616 | | Lavoro sulla sezione dedicata alla simulazione per la formattazione della terza fase dell'algoritmo. |
| 617 | | |
| 618 | | === 24 Ottobre === |
| 619 | | __0950-1100__ __1150-1250__ __1430-1846__[[BR]] |
| 620 | | Lavoro con gnappo sulla sezione dedicata alla simulazione: rilettura, correzione, formalizzazione e formattazione dell'algoritmo. |
| 621 | | |
| 622 | | === 25 Ottobre === |
| 623 | | __1012-1025__[[BR]] |
| 624 | | Aggiornamento del diario e del deposito subversion [16]. |
| 625 | | |
| 626 | | __1030-1810__[[BR]] |
| 627 | | Lavoro con gnappo sulla sezione dedicata alla simulazione: |
| 628 | | * rilettura e correzione definitive dell'algoritmo; |
| 629 | | * ulteriori ed definizioni e interessanti conclusioni teoriche relative al modello di rete necessario al simulatore; |
| 630 | | * aggiornamento locale del diario. |
| 631 | | |
| 632 | | === 26 Ottobre === |
| 633 | | __0940-0950__[[BR]] |
| 634 | | Aggiornamento del diario e del deposito subversion [17]. |
| 635 | | |
| 636 | | __1030-1240__[[BR]] |
| 637 | | Discussioni sulla gestione dei lavori futuri con gnappo, accenni alla futura organizzazione. |
| 638 | | |
| 639 | | === 27 Ottobre === |
| 640 | | __1100-1322__[[BR]] |
| 641 | | Con gnappo: |
| 642 | | * punto della situazione sull'avanzamento dei lavori; |
| 643 | | * discussione e scelta delle metodologie di lavoro: inizio parallelismo; |
| 644 | | * discussione e scelta e degli strumenti d'ausilio: uso di soli sorgenti TeX, meglio gestibili dai software di versionamento; |
| 645 | | * definizione prossime attività da svolgere; |
| 646 | | * decisione monte ore settimanale: circa 15. |
| 647 | | |
| 648 | | __1500-1737__[[BR]] |
| 649 | | Aggiunta documento !ToDo al deposito subversion [18]. |
| 650 | | |
| 651 | | Preconfigurazione di un profilo di unison per la sincronizzazione diretta SoujaK <-> gnappo. |
| 652 | | |
| 653 | | Esportazione della relazione da KDissert a LaTeX: |
| 654 | | * riformattazione di alcune sezioni; |
| 655 | | * riformattazione dei segmenti con simboli matematici; |
| 656 | | * inserimento tag `TODO` per le cose da fare; |
| 657 | | * commentata la sezione "Questioni aperte", che non sarà inclusa nella relazione; |
| 658 | | * inserimento algoritmo del simulatore. |
| 659 | | |
| 660 | | __1740-1800__[[BR]] |
| 661 | | Con gnappo: condivisione reciproca sugli sviluppi dei lavori. |
| 662 | | |
| 663 | | Aggiornamento del diario e del deposito subversion [19]. |
| 664 | | |
| 665 | | __1850-2000__[[BR]] |
| 666 | | Revisione della sezione dedicata al modello teorico: |
| 667 | | * rilettura e riorganizzazione |
| 668 | | * copia formule appartenenti al vecchio documento; |
| 669 | | * formattazione introducendo definizioni. |
| 670 | | |
| 671 | | === 30 Ottobre === |
| 672 | | __1415-1515__[[BR]] |
| 673 | | Con gnappo: |
| 674 | | * punto della situazione; |
| 675 | | * chiacchiere con Bononi; |
| 676 | | * schedulazione attività. |
| 677 | | |
| 678 | | __1610-1655__[[BR]] |
| 679 | | Aggiornamento deposito subversion [20]. |
| 680 | | |
| 681 | | Riorganizzazione dei contenuti della porzione di relazione dedicata alla modellazione teorica: |
| 682 | | * anticipazione della sezione "Ascolto"; |
| 683 | | * rinomina di "Modello di rete" in "Assunzioni"; |
| 684 | | * rinomina di "Modello matematico" in "Modello teorico"; |
| 685 | | |
| 686 | | __1655-1800__[[BR]] |
| 687 | | Con gnappo: discussioni sulle modalità di riorganizzazione dei contenuti della porzione di relazione dedicata alla modellazione teorica, in particolare sulla possibilità di inserimento di un coefficiente d'attività delle stazioni. |
| 688 | | |
| 689 | | __1825-1830__[[BR]] |
| 690 | | Aggiornamento del deposito subversion [21] e del diario. |
| 691 | | |
| 692 | | |
| 693 | | === 31 Ottobre === |
| 694 | | __1600-1740__[[BR]] |
| 695 | | Incontro con il professor Ghini: |
| 696 | | * aggiornamento sullo stato dei lavori; |
| 697 | | * obiettivi futuri in ambito tesi di laurea. |
| 698 | | |
| 699 | | __1821-1854__[[BR]] |
| 700 | | Con gnappo: |
| 701 | | |
| 702 | | * aggiornamento locale del diario; |
| 703 | | * discussioni sull'organicità e chiarezza sia attuali che future. |
| 704 | | |
| 705 | | == Novembre 2007 == |
| 706 | | |
| 707 | | === 2 Novembre === |
| 708 | | __1043-1445__[[BR]] |
| 709 | | Lavoro con gnappo: |
| 710 | | * individuazione delle relazioni che intercorrono tra i concetti principali presenti nello studio; |
| 711 | | * riflessioni sul carico: chiarimenti sulla sua relazione con il concetto di epoca e caratterizzazione del carico di una stazione |
| 712 | | * considerazioni sulla natura del coefficiente di attività: dipende sia dalla necessità trasmissiva della stazione, sia dalla presenza delle altre stazioni. |
| 713 | | * tentativi di soluzione al problema della determinazione del carico di un BSS senza l'utilizzo di tecniche ''round-robin''. |
| 714 | | |
| 715 | | __1640-1900__[[BR]] |
| 716 | | Lavoro con gnappo per la stesura cartacea di un grafo di dipendenze dei concetti, utile per l'organizzazione dei contenuti. |
| 717 | | |
| 718 | | Aggiornamento del deposito subversion [22] [23]. |
| 719 | | |
| 720 | | === 5 Novembre === |
| 721 | | __1515-1815__[[BR]] |
| 722 | | Lavoro con gnappo per la stesura di una nuova scaletta a partire dalle dipendenze chiarite il 2 Novembre. |
| 723 | | |
| 724 | | Aggiornamento del deposito subversion [24]. |
| 725 | | |
| 726 | | === 6 Novembre === |
| 727 | | __1030-1345__[[BR]] |
| 728 | | Lavoro con gnappo per approfondire la scaletta. |
| 729 | | |
| 730 | | __1345-1400__[[BR]] |
| 731 | | Aggiornamento del diario e della scaletta nel deposito subversion. |
| 732 | | |
| 733 | | === 6 Novembre === |
| 734 | | __1030-1345__[[BR]] |
| 735 | | Lavoro con gnappo per approfondire la scaletta. |
| 736 | | |
| 737 | | __1345-1400__[[BR]] |
| 738 | | Aggiornamento del diario e della scaletta nel deposito subversion [25]. |
| 739 | | |
| 740 | | __1525-1750__[[BR]] |
| 741 | | Lavoro con gnappo per concludere l'approfondimento della scaletta. |
| 742 | | |
| 743 | | __1815-1903__[[BR]] |
| 744 | | Aggiornamento della scaletta nel deposito subversion [26]. |
| 745 | | |
| 746 | | Creazione nuovo documento LaTeX (source:CaricoBSS/sorgenti/PoliticheSelezioneAP.tex) pronto per ospitare i nuovi contenuti. Aggiornamento della lista di cose da fare, del diario e del deposito subversion [27]. |
| 747 | | |
| 748 | | === 8 Novembre === |
| 749 | | __1046-1415__[[BR]] |
| 750 | | * Pianificazione dei lavori della giornata con gnappo. |
| 751 | | * Migrazione contenuti nel nuovo documento. |
| 752 | | * Chiarimenti con gnappo sull'algoritmo e relative ottimizzazioni. |
| 753 | | |
| 754 | | __1521-1810__[[BR]] |
| 755 | | * Discussioni chiarificatorie sulla distribuzione delle trasmissioni AP -> STA. |
| 756 | | * Aggiornamento del deposito subversion [28]. |
| 757 | | |
| 758 | | __1910-1934__[[BR]] |
| 759 | | Migrazione contenuti nel nuovo documento (33%). |
| 760 | | |
| 761 | | === 13 Novembre === |
| 762 | | __1110-1126__[[BR]] |
| 763 | | Aggiornamento locale del diario. |
| 764 | | |
| 765 | | __1126-1338__[[BR]] |
| 766 | | Con gnappo ancora sulla distribuzione deglle trasmissioni AP -> STA: sperimentazioni e conclusioni. |
| 767 | | |
| 768 | | __1530-1710__[[BR]] |
| 769 | | * Due chiacchiere con gnappo sulle modalità di realizzazione dell'algoritmo di inserimento della stazione associanda. |
| 770 | | * Migrazione contenuti nel nuovo documento (90%): restano definizioni, teoremi e formule appartenenti al modello. |
| 771 | | |
| 772 | | __1710-1725__[[BR]] |
| 773 | | Pianificazione con gnappo delle attivita` del 14 Novembre. |
| 774 | | |
| 775 | | __1815-1945__[[BR]] |
| 776 | | * Aggiornamento locale del diario e del ToDo; |
| 777 | | * migrazione contenuti nel nuovo documento (100%) e inizio stesura sezione "Modello"; |
| 778 | | * aggiornamento deposito subversion [29]; |
| 779 | | * aggiornamento del diario. |
| 780 | | |
| 781 | | === 14 Novembre === |
| 782 | | __1000-1040__ __1103-1443__[[BR]] |
| 783 | | * Stesura sezione "Modello" (57%); |
| 784 | | * qualche chiacchiera con gnappo; |
| 785 | | * aggiornamento del diario e del deposito subversion [30]. |
| 786 | | |
| 787 | | __1612-1720__[[BR]] |
| 788 | | * Stesura sezione "Modello" (71%); |
| 789 | | * aggiornamento del diario e del deposito subversion [31]. |
| 790 | | |
| 791 | | === 16 Novembre === |
| 792 | | __0810-0839__ __0920-1320__ __1400-1800__[[BR]] |
| 793 | | Qualche chiacchiera con gnappo sull'algoritmo di inserimento della stazione associanda. |
| 794 | | Lavoro per la stesura della sezione "Modello" (87%): |
| 795 | | * chiarimento sull'equità dell'AP; |
| 796 | | * precisazioni nella ripartizione delle assunzioni all'interno del documento; |
| 797 | | * completamento delle definizioni di saturazione; |
| 798 | | * precisazioni e miglioramento della qualità della definizione di epoca; |
| 799 | | * definiti e formalizzati tre teoremi; |
| 800 | | * abbozzate due dimostrazioni dei tre teoremi. |
| 801 | | |
| 802 | | __1800-1809__[[BR]] |
| 803 | | Aggiornamento del deposito subversion [32] e del diario. |
| 804 | | |
| 805 | | __1846-1900__[[BR]] |
| 806 | | Lavoro per la stesura della sezione "Modello" (90%): abbozzata la prima parte della dimostrazione del primo (e più rognoso) dei tre teoremi. |
| 807 | | |
| 808 | | === 17 Novembre === |
| 809 | | |
| 810 | | __1302-1308__[[BR]] |
| 811 | | Aggiornamento del diario e del deposito subversion [33]. |
| 812 | | |
| 813 | | === 19 Novembre === |
| 814 | | __0845-0910__[[BR]] |
| 815 | | Lavoro per la stesura della sezione "Modello" (92%): abbozzata la seconda parte della dimostrazione del primo (e più rognoso) dei tre teoremi. |
| 816 | | |
| 817 | | __0934-0939__[[BR]] |
| 818 | | Aggiornamento del diario e del deposito subversion [34]. |
| 819 | | |
| 820 | | __1030-1843__[[BR]] |
| 821 | | Stesura modello: interrogativi sulla nuova e più generale definizione di epoca e relative chiacchiere con gnappo.[[BR]] |
| 822 | | Definita bozza di un nuovo teorema (diverrà il primo) in grado di collegare la tesi di equità del mezzo alla definizione di epoca. |
| 823 | | |
| 824 | | __1929-2005__[[BR]] |
| 825 | | Scritta la bozza di dimostrazione del primo teorema. |
| 826 | | |
| 827 | | === 21 Novembre === |
| 828 | | __1020-1053__[[BR]] |
| 829 | | Aggiornamento locale del diario.[[BR]] |
| 830 | | Lavoro per la stesura della sezione "Modello" (93%): miglioramento dell'enunciato del primo teorema. |
| 831 | | |
| 832 | | __1210-1217__[[BR]] |
| 833 | | Aggiornamento del diario e del deposito subversion [35]. |
| 834 | | |
| 835 | | === 26 Novembre === |
| 836 | | __1545-1820--[[BR]] |
| 837 | | Lavoro con gnappo: |
| 838 | | * formalizzata discorsivamente una nuova tesi di equità di accesso al mezzo; |
| 839 | | * iniziata la formalizzazione rigorosa. |
| 840 | | |
| 841 | | __ 1844-1909__[[BR]] |
| 842 | | Lavoro per la stesura rigorosa della tesi di equità di accesso al mezzo. |
| 843 | | |
| 844 | | === 28 Novembre === |
| 845 | | __1716-1821__[[BR]] |
| 846 | | [36] |
| 847 | | |
| 848 | | == Gennaio 2008 == |
| 849 | | === 4 Gennaio === |
| 850 | | __1800-1930__[[BR]] |
| 851 | | Lavori sul ticket #6: [41] |
| 852 | | |
| 853 | | === 6 Gennaio === |
| 854 | | __1600-1930__[[BR]] |
| 855 | | Lavori sul ticket #6: [42] |
| 856 | | |
| 857 | | === 7 Gennaio === |
| 858 | | __1140-1300__[[BR]] |
| 859 | | Videoconferenza con Gnappo. |
| 860 | | |
| 861 | | __1525-1825__[[BR]] |
| 862 | | Ideazione algoritmo di analisi del flusso per l'individuazione delle epoche. |
| 863 | | Progettazione struttura dati per la memorizzazione delle informazioni sulle epoche di un flusso. |
| 864 | | |
| 865 | | === 8 Gennaio === |
| 866 | | |
| 867 | | __1350-1445__[[BR]] |
| 868 | | Considerazioni su un possibile algoritmo di inserimento della stazione associanda in grado di sfruttare la struttura dati creata dall'algoritmo di analisi. |
| 869 | | |
| 870 | | __1550-1800__[[BR]] |
| 871 | | Con gnappo: |
| 872 | | * Condivisione di conoscenze riguardo all'algoritmo di inserimento della stazione associanda. |
| 873 | | * Considerazioni sulla possibilità di ripescare trasmissioni successive al tempo d'analisi e precedenti al tempo di simulazione. Il ripescaggio appare come una necessità, in linea con la tesi di equità, ma solo assumendo indipendenza fra le trasmissioni. L'eventualità degli errori compiuti nel riarrangiamento temporale fa pensare alla possibilità di limitare il ripescaggio (non anticipare una trasmissione prima dell'ultima trasmissione a lei diretta). La complessità di gestione della struttura dati durante i ripescaggi è ancora tutta da analizzare. |
| 874 | | |
| 875 | | === 9 Gennaio === |
| 876 | | __1415-1440__[[BR]] |
| 877 | | Aggiornamento del diario. |
| 878 | | |
| 879 | | __1500-1620__[[BR]] |
| 880 | | Esposizione non rigorosa dell'algoritmo di individuazione delle epoche di un flusso. |
| 881 | | |
| 882 | | __1650-1810__[[BR]] |
| 883 | | Revisione teorema di saturazione della stazione e del flusso. Ampliamento della tesi di equità del flusso (rinominabile). |
| 884 | | |
| 885 | | __1845-1927__ __1944-[[BR]] |
| 886 | | Videoconferenza con gnappo: |
| 887 | | * Condivisione progressi dei lavori di SoujaK della giornata. |
| 888 | | * Considerazioni sulla modellazione delle trasmissioni AP -> STA. |
| 889 | | |
| 890 | | === 10 Gennaio === |
| 891 | | Aggiornamento del modello teorico, al fine di renderlo capace di descrivere anche le assunzioni riguardanti le politiche di ripartizione delle trasmissioni dell'AP. |
| 892 | | |
| 893 | | ---- |
| 894 | | |
| 895 | | == Aprile, Maggio e Giugno 2008 == |
| 896 | | |
| 897 | | === Obiettivi === |
| 898 | | |
| 899 | | Il punto di partenza per la revisione degli studi finora condotti è uno sguardo più ampio con il quale analizzare il flusso trasmissivo. Le assunzioni di equità nel locale, benché non abbiano manifestato la loro fallacia nell'analisi semplificata in condizioni di saturazione, sono da dimenticare assieme al concetto di epoca sul quale si fondavano. L'imperativo è guardare al globale: le variazioni locali di cui si vorrà tener conto saranno colte con osservazioni che tengono in maggior conto i periodi più recenti. |
| 900 | | |
| 901 | | L'analisi reale si proponeva però di fornire una valutazione del carico ed una conseguente stima delle prestazioni ottenibili dalla stazione associanda che tengano conto di una ampia serie di dettagli. Si faceva riferimento alle diversità fra stazioni nel datarate, nella lunghezza dei frame o nel throughput. |
| 902 | | |
| 903 | | === Modello teorico === |
| 904 | | |
| 905 | | ''Durata dell'accesso [d=w/r]'' |
| 906 | | Si consideri, fra le caratteristiche delle stazioni la frequenza d'accesso [a], espressa in 1/s. DCF assicura a stazioni con pari desideri trasmissivi una tendenza all'equità nel numero di accessi. Calcolando la frequenza d'accesso per un insieme di stazioni con pari desideri trasmissivi si otterranno valori che tendono ad avvicinarsi. Il parametro [a] può quindi essere utilizzato come chiave per la ripartizione degli accessi durante una simulazione di presenza della stazione associanda. |
| 907 | | ''Tasso d'accesso [a] (hz)'' |
| 908 | | Il grado di partecipazione di una stazione è il numero puro equivalente al prodotto fra la durata dell'accesso e il tasso d'accesso, ed e` indicato con p. |
| 909 | | Vale, ovviamente che 0<=p<=1. La somma dei gradi di partecipazione delle stazioni è uguale al vecchio "tasso d'occupazione del mezzo trasmissivo". |
| 910 | | ''Grado di partecipazione [p=d*a] (n) '' |
| 911 | | |
| 912 | | === Inserimento della stazione associanda === |
| 913 | | |
| 914 | | Un punto fermo di questa sezione della modellazione è che la stazione associanda, che si assume essere caratterizzata come satura, riempirà ogni silenzio rilevato sul canale portando il tasso d'occupazione del mezzo trasmissivo ad 1. |
| 915 | | |
| 916 | | Nell'effettiva formalizzazione dell'idea di equità e nel come essa si concretizzi nel ripartire le possibilità trasmissive alle varie stazioni nella simulazione di presenza della stazione associanda le cose si fanno più complesse. |
| 917 | | |
| 918 | | Una semplice modalità di procedere è quella di tenere invariate le proporzioni fra i tassi d'accesso delle varie stazioni. Così facendo il modello non terrebbe conto dell'effettiva diversa ripartizione dell'impatto dell'entrata della stazione associanda. |
| 919 | | |
| 920 | | Anzitutto alla stazione associanda sarà garantito un tasso d'accesso maggiore o uguale ai tassi d'accesso delle stazioni associate. |
| 921 | | |
| 922 | | Qualora i silenzi siano lunghi a sufficienza i tassi d'accesso delle stazioni associate non vengono diminuiti dal simulato ingresso della stazione associanda. Per verificare questa condizione basta dividere il tasso di partecipazione nullo (ovvero il tasso di non-occupazione del mezzo, 1-"tasso d'occupazione del mezzo) per la durata dell'accesso della stazione associanda. Così facendo si ricaverà il tasso d'accesso (a'_x) della stazione associanda. Se esso è maggiore o uguale di ognuno dei tassi d'accesso delle stazione associate, esse non verranno penalizzate dall'entrata dalla stazione associanda. |
| 923 | | |
| 924 | | === Algoritmo per la ripartizione degli accessi === |
| 925 | | |
| 926 | | ==== Versione semplificata ==== |
| 927 | | Ipotizzando che la durata degli accessi sia d, costante fra le stazioni, si propone il seguente algoritmo. |
| 928 | | {{{ |
| 929 | | 1 i=|S| // contatore delle stazioni da computare |
| 930 | | 2 a_x = 0 |
| 931 | | 3 a = 1/d // accessi al secondo ancora effettuabili |
| 932 | | 4 while (i>0) |
| 933 | | 5 s = indice della stazione tale che a_s e` minimo |
| 934 | | 6 if (a_s > a/i) |
| 935 | | 7 a'_s = a_s |
| 936 | | 8 else |
| 937 | | 9 a'_s = a/i |
| 938 | | 10 a -= a'_s |
| 939 | | 11 i-- |
| 940 | | 12 a_x+=a // ad x tutti gli accessi restanti |
| 941 | | }}} |
| 942 | | Il costo dell'algoritmo è `O(n^2)` se si ricerca il minimo con una scansione semplice della lista. |
| 943 | | |
| 944 | | ==== Versione completa ==== |
| 945 | | Considerare la possibilità che gli accessi possano avere durata variabile da stazione a stazione significa appesantire la computazione di adeguate normalizzazioni rispetto ai d_s delle varie stazioni s. |
| 946 | | |
| 947 | | {{{ |
| 948 | | 1 i=|S| // contatore delle stazioni da computare |
| 949 | | 2 a_x = 0 |
| 950 | | 3 d = somma(d_s per ogni s)/i // durata di un accesso medio fra le sta |
| 951 | | 4 a = 1/d // accessi al secondo ancora effettuabili |
| 952 | | 5 while (i>0) |
| 953 | | 6 s = indice della stazione tale che a_s è minimo |
| 954 | | 7 if (a_s > a/i) |
| 955 | | 8 a'_s = a_s |
| 956 | | 9 else |
| 957 | | 10 a'_s = a/i |
| 958 | | 11 d=(d*i-d_s)/i-1 // aggiornamento della durata dell'accesso medio |
| 959 | | 12 a = 1/d |
| 960 | | 13 i-- |
| 961 | | 14 a'_x+=a // ad x tutti gli accessi restanti |
| 962 | | }}} |
| 963 | | Il costo dell'algoritmo resta `O(n^2)` nel caso di ricerca il minimo con semplice scansione della lista non ordinata. |
| 964 | | |
| 965 | | Il concetto di frequenza di diritto è ben utilizzato dalla versione semplificata, ma la versione completa non e` in grado di normalizzarlo rispetto alla variabilita` nella durata degli accessi. |
| 966 | | |
| 967 | | |
| 968 | | |
| 969 | | Nel caso in cui d sia costante fra le stazioni (quando i loro accessi hanno durata uguale fra loro) è facile calcolare la frequenza d'accesso di diritto come una suddivisione in parti uguali fra le stazioni della frequenza |
| 970 | | massima possibile. Quando i d variano per calcolare la frequenza di diritto e` necessario ... |
| 971 | | |
| 972 | | == Luglio 2008 == |
| 973 | | |
| 974 | | === 13 Luglio === |
| 975 | | |
| 976 | | Il concetto di equità precedentemente perseguito resta fondamento della prosecuzione degli studi: esso si esprime in una tendenza alla parità nel tasso d'accesso di stazioni con identiche esigenze trasmissive. Il più grande errore commesso era appunto il tentativo di imporre equità locale, quando essa è tutt'altro che presente. Nel simulare la presenza della stazione associanda il tasso d'accesso diventa coerentemente il metro con cui misurare i diritti delle stazioni associate. |
| 977 | | Gli algoritmi elaborati a questo fine a metà di Maggio non erano però in grado di simulare una ripartizione degli accessi in grado di non ignorare le diversità delle stazioni nella durata degli accessi (cfr v1 e v2). |
| 978 | | |
| 979 | | L'idea di fondo non è nuova: si tratta di una rivisitazione di un algoritmo ripartitore che comincia ad assegnare accessi dalle stazioni meno esigenti, passando via via alle più "golose". Questa volta non si ripartiscono accessi di una misteriosa epoca, ma si concedono tassi d'accesso via via più altri, fino alla saturazione del tempo del canale. |
| 980 | | |
| 981 | | |
| 982 | | === 14 Luglio === |
| 983 | | |
| 984 | | ==== Algoritmo di ripartizione degli accessi - v4 ==== |
| 985 | | |
| 986 | | {{{ |
| 987 | | 1 a'_s <= 0 // inizializzazione per ogni s in S |
| 988 | | 2 finché (S nequal \empty) // insieme delle STA insoddifatte non vuoto |
| 989 | | 3 d <= \sum^S d_s // durata trasmissione di ognuna |
| 990 | | 4 a_{MAX} <= 1/d // concessione massima attuale |
| 991 | | 5 s_{cur} <= s \in S | min(a_{MAX} - a'_s) // STA meno insoddisfatta |
| 992 | | 6 a_{cur} <= min (a_MAX, a_{s_{cur}} - a'_{s_{cur}}) // concessione attuale |
| 993 | | 7 perogni (s \in S) |
| 994 | | 8 a'_{s} += a_{cur} // soddisfacimento per tutti |
| 995 | | 9 S <= S/s_{cur} // eliminazione STA di tara |
| 996 | | }}} |
| 997 | | |
| 998 | | === 15 Luglio === |
| 999 | | |
| 1000 | | Nell'algoritmo v4 l'aggiornamento della concessione massima del periodo in analisi in ogni giro avviene implicitamente, mediante la rimozione (r7) della stazione meno soddisfatta sulla quale si è tarata la concessione del periodo (r6). Questo aggiornamento è errato e va modificato, eventualmente considerando il numero di stazioni o normalizzando rispetto alla durata degli accessi delle stazioni servite. |
| 1001 | | |
| 1002 | | === 16 Luglio === |
| 1003 | | |
| 1004 | | Riprogettato da capo l'algoritmo, tentando di sistemare il problema di aggiornamento del numero di accessi ancora disponibili. |
| 1005 | | |
| 1006 | | ==== Algoritmo di ripartizione degli accessi - v5 ==== |
| 1007 | | |
| 1008 | | {{{ |
| 1009 | | 1 a_M <= 1/(\sum^S_i d_i) // tasso d'accesso inizialmente disponibile |
| 1010 | | 2 s <= i \in S : min(a_i-a'_s) // STA meno insoddisfatta |
| 1011 | | 3 SE (a_M > a_s - a'_s) // s e` soddisfacibile |
| 1012 | | 4 a'_S += a_s - a'_s // assegno ad ogni STA cio` che mancava a s |
| 1013 | | 5 d <= (1 - \sum^S_i d_i * (a_s - a'_s) ) // <------------ |
| 1014 | | 6 SE (d>0) // tassi d'accesso ancora incrementabili |
| 1015 | | 7 a_M <= 1/d // aggiornamento tasso d'accesso disponibile |
| 1016 | | 8 GOTO 2 // cicla |
| 1017 | | 9 ALTRIMENTI // s e` insoddisfacibile |
| 1018 | | 10 a'_S += a_M // assegno ad ogi STA il tasso d'accesso disponibile |
| 1019 | | }}} |
| 1020 | | |
| 1021 | | === 21 Luglio === |
| 1022 | | |
| 1023 | | Digitalizzazione della versione 5 dell'algoritmo. |
| 1024 | | |
| 1025 | | La forma spaghettosa con l'uso del GOTO è frutto di una riprogettazione da zero ancora non raffinata. È stato chiarito nel flusso di esecuzione il diverso comportamento a seconda della condizione in riga 3 cambiando, in questo modo, la condizione di chiusura del flusso (r9). Se la stazione meno soddisfatta non è soddisfacibile non lo è nessun'altra e la ripartizione non puo` che concludersi immediatamente concedendo ad ogni stazione il medesimo tasso d'accesso. |
| 1026 | | La riga 5 è da rivedere. |
| 1027 | | |
| 1028 | | Al termine dell'esecuzione dell'algoritmo di ripartizione degli accessi devono verificarsi alcune condizioni che possono essere utilizzate come parziale prova di correttezza. |
| 1029 | | {{{ |
| 1030 | | 1. \sum^S_i p'_i = 1 (p'_i = a'_i * d_i) |
| 1031 | | }}} |
| 1032 | | Il tasso di occupazione del mezzo, dato dalla somma di tutti i tassi di |
| 1033 | | partecipazione delle stazioni deve raggiungere il massimo, vale a dire uno, |
| 1034 | | il valore di saturazione. |
| 1035 | | {{{ |
| 1036 | | 2. \forall i \in S: a_s > a'_s |
| 1037 | | }}} |
| 1038 | | Ogni stazione ottiene un tasso d'accesso minore o uguale a quello ottenuto |
| 1039 | | in assenza della stazione associanda simulata. |
| 1040 | | {{{ |
| 1041 | | 3. \forall i,j \in S: a_i >= a_j => a'_i >= a'_j |
| 1042 | | }}} |
| 1043 | | Prese a caso due stazioni distinte se la prima aveva trasmesso più della |
| 1044 | | seconda, dopo l'entrata della stazione associanda la seconda non trasmette |
| 1045 | | piu` della prima. In effetti l'entrata di una nuova stazione si crede che |
| 1046 | | tenda a ridurre la partecipazione delle stazioni che partecipano |
| 1047 | | maggiormente, coerentemente con la tendenza all'equità. |
| 1048 | | |
| 1049 | | == Ottobre 2008 == |
| 1050 | | |
| 1051 | | === 23 Ottobre === |
| 1052 | | Il problema della modellazione della ripartizione degli accessi dopo l'entrata della stazione associanda dipende da due fattori: la tendenza all'equità nella spartizione degli accessi (DCF) e le esigenze trasmissive delle stazioni. |
| 1053 | | Elaborare una soluzione diretta al problema sembra simile alla risoluzione di un sistema di N equazioni differenziali e deve essere scartato. |
| 1054 | | |
| 1055 | | === 24 Ottobre === |
| 1056 | | La via che invece verrà utilizzata è quella di rinunciare ad un po' di precisione aumentando la realizzabilità della soluzione: si lavorerà con le frequenze d'accesso. Prima di realizzare una soluzione, però, è importante chiarire i legami fra l'equità della quale DCF è garanzia e le frequenze d'accesso. Soltanto palesando questa relazione si potrà motivare rigorosamente questa scelta. |
| 1057 | | |
| 1058 | | La soluzione algoritmica elaborata a maggio segue questo principio, ma sembra cadere negli stessi problemi emersi nei tentativi di soluzione tramite porzioni di accesso. Rinunciare ad adeguamenti precisi nelle proporzioni delle possibilità di accesso al mezzo semplifica notevolmente il problema e consente, rispetto agli approcci precedentemente utilizzati, di eliminare l'assunzione di indipendenza reciproca delle trasmissioni. Si tratta di tenere invariate le proporzioni delle possibilità trasmissive delle stazioni associate. |
| 1059 | | |
| 1060 | | {{{ |
| 1061 | | #a_x = d_0 / d_x \\ numero di accessi che x prende nel silenzio |
| 1062 | | p'_i = #a_i / (#a_S + #a_x) \\ probabilita` di trasmissione di ogni i |
| 1063 | | if (p'_x \get p'_i) \\ se x ha una prob >= alle altre sta |
| 1064 | | fine \\ quella prob e` corretta |
| 1065 | | else \\ altrimenti |
| 1066 | | p_x = max(p_i) \\ x ha diritto come il massimo |
| 1067 | | p'_i = p_i / p \\ normalizzazione i tutti i p'_i |
| 1068 | | }}} |
| 1069 | | |
| 1070 | | La gestione della presenza dei silenzi nel flusso d'ascolto sarebbe in realtà migliorabile, quella presentata potrebbe essere una buona approssimazione. |
| 1071 | | Resta da verificare la correttezza del ramo else e se il silenzio sia mangiato nella sua totalità. |
| 1072 | | |
| 1073 | | === 27 Ottobre === |
| 1074 | | L'algoritmo del 24 Ottobre sembra rappresentare correttamente l'intuizione di come i ''p '' vengano ripartiti, anche nel caso in cui i silenzi disponibili non siano sufficienti (ramo `else`). |
| 1075 | | Infatti: p > 1 => p'_i < p_i. |
| 1076 | | L'affidabilità delle intuizioni saranno messe alla prova nelle sperimentazioni future. |
| 1077 | | |
| 1078 | | === 28 Ottobre === |
| 1079 | | Il carico deve rappresentare l'impossibità di fruizione del mezzo, il grado di congestione della rete, quindi, intuitivamente, una rete con carico minore consentirà prestazioni maggiori. |
| 1080 | | Il primo tentativo di definizione operativa definisce il carico della stazione ''i''-esima come il prodotto della sua probabilità trasmissiva (''p_i'') e della durata della trasmissione (''d_i''). |
| 1081 | | In questo modo il carico di un BSS ''S'' è pari alla somma dei carichi unitari delle stazioni ad esso associate: |
| 1082 | | {{{ |
| 1083 | | \sum_i^S p'_i d_i |
| 1084 | | }}} |
| 1085 | | |
| 1086 | | Ma questa definizione è in gran parte debole; infatti la sequenza trasmissiva (1,1,1,2) avrebbe lo stesso carico della (1,2,1,2), vale a dire 1. |
| 1087 | | |
| 1088 | | === 30 Ottobre === |
| 1089 | | La presenza del parametro ''p'' appare non corretta o non sufficiente, benché contenga un senso d'efficacia. |
| 1090 | | |
| 1091 | | |
| 1092 | | |
| 1093 | | === 31 Ottobre === |
| 1094 | | Il problema delle definizioni di carico ideate ieri ed oggi (non riportate) sono tutte errate perché il parametro ''p'' non riesce a quantificare quanti e quali accessi siano presenti in ogni giro. È necessario quantificare la presenza di ogni stazione relazionandone l'attività con quella massima ottenuta dalle altre STA. Formalmente il carico unitario della stazione ''i''-esima è dato dal prodotto della durata del suo accesso (''d,,i,,'') e del suo peso (''w,,i,,''); formalmente: |
| 1095 | | {{{ |
| 1096 | | l_i = w_i d_i |
| 1097 | | w_i = \frac{a_i}{M(a_i)} |
| 1098 | | }}} |
| 1099 | | |
| 1100 | | == Novembre 2008 == |
| 1101 | | === 4 Novembre === |
| 1102 | | |
| 1103 | | Il carico del canale dipende in maniera lineare dal carico delle stazioni che lo utilizzano ed è inversamente proporzionale al silenzio in esso presente. |
| 1104 | | |
| 1105 | | Formalmente il carico del canale è esprimibile nel seguente modo: |
| 1106 | | {{{ |
| 1107 | | (1) L_i = \sum_i{l_i} o_S |
| 1108 | | (2) o_S = (\sum t_i) / t_S |
| 1109 | | (3) t_i = a_i * d_i |
| 1110 | | }}} |
| 1111 | | |
| 1112 | | === 5 Novembre === |
| 1113 | | |
| 1114 | | L'obiettivo di modellazione delle prestazioni ottenute o ottenibili dalle stazioni comporta un'analisi più accurata delle '''trasmissioni'''. La banda ricettiva (''download'') è infatti generata dalle trasmissioni provenienti dall'AP e dirette alle STA. |
| 1115 | | |
| 1116 | | Il carico prodotto dalle trasmissioni dall'AP è quantificato nel carico dell'AP, calcolato come ogni altro carico unitario. In particolare come durata della trasmissione si usa la durata media delle trasmissioni AP -> STA. In questo modo si tiene conto non solo della durata media delle ricezioni di ogni stazione, ma si considera anche la reale influenza delle ricezioni di ogni STA, infatti: |
| 1117 | | {{{ |
| 1118 | | d_i = \sum_i {a_di * d_di / a_d} |
| 1119 | | = \sum_i {a_di * d_di} / a_d |
| 1120 | | = \sum_i {t_d / a_d} |
| 1121 | | }}} |
| 1122 | | |
| 1123 | | Anche l'algoritmo di inserimento della stazione associanda deve essere ampliato per adeguare le trasmissioni che l'AP effettua verso di essa. Ecco una versione parziale che getta le intuizioni alla base della soluzione. |
| 1124 | | {{{ |
| 1125 | | t_s silenzio |
| 1126 | | a_ui a_di |
| 1127 | | a_d = sum a_di |
| 1128 | | a_x=0 |
| 1129 | | |
| 1130 | | 1 a'_ux = a_d |
| 1131 | | 2 t_s -= a'_ux * d_ux |
| 1132 | | 3 se t_s > 0 |
| 1133 | | 4 a'_dx = t_s / (d_ux + d_dx) |
| 1134 | | 5 a'_d = a_d + a'_dx |
| 1135 | | 6 a'_ux += a'_dx |
| 1136 | | 7 se a'_ux <= M(a_ui) |
| 1137 | | 8 a'_d = a'_ux = M(a_ui) |
| 1138 | | 9 \\ normalizzazione |
| 1139 | | 10 else |
| 1140 | | 11 else |
| 1141 | | 12 a'_d = a'_ux = M(a_ui) |
| 1142 | | 13 \\ normalizzazione |
| 1143 | | 14 \\ ripartizione ricezioni |
| 1144 | | }}} |
| 1145 | | |
| 1146 | | === 7 Novembre === |
| 1147 | | |
| 1148 | | Ampliamenti e miglioramenti all'algoritmo di ripartizione delle trasmissioni e delle ricezioni (ora anche commentato): |
| 1149 | | |
| 1150 | | {{{ |
| 1151 | | t_s: durata totale dei silenzi |
| 1152 | | a_ui, a_di: numero di accessi in invio e in ricezione della i-esima STA |
| 1153 | | a_d = sum a_di |
| 1154 | | a_dx = a_ux = 0 |
| 1155 | | |
| 1156 | | 01 se t_us >= d_ux * a_d [ se x puo` usare silenzio per trasmettere come AP ] |
| 1157 | | 02 t_us -= d_ux * a_d |
| 1158 | | 03 a_'ux = a_d [ x trasmette come AP ] |
| 1159 | | 04 se t_us >= 0 [ se avanza silenzio ] |
| 1160 | | 05 a'_dx = t_us / (d_ux + d_dx) [ meta` silenzio per ricezioni di x ] |
| 1161 | | 06 a'_d = a_d + a'_dx |
| 1162 | | 07 a'_ux += a'_dx [ meta` silenzio per trasmissioni di x] |
| 1163 | | 08 se a'_ux <= M(a_ui) [ se x non trasmette al massimo ] |
| 1164 | | 09 a'_d = a'_ux = M(a_ui) [ ripartizione grezza trasmissioni ] |
| 1165 | | 10 ... [ normalizzazione trasmissioni ] |
| 1166 | | 11 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1167 | | 12 ... [ normalizzazione ricezioni ] |
| 1168 | | 13 alrimenti [ x trasmette al massimo ] |
| 1169 | | 14 se a'_dx <= M(a_di) [ se x non riceve al massimo ] |
| 1170 | | 15 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1171 | | 16 ... [ normalizzazione degli a'_d ] |
| 1172 | | 17 altrimenti [ se non avanza silenzio ] |
| 1173 | | 18 a'_d = a'_ux = M(a_ui) [ ripartizione grezza trasmissioni ] |
| 1174 | | 19 ... [ normalizzazione trasmissioni ] |
| 1175 | | 20 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1176 | | 21 ... [ normalizzazione degli a'_d ] |
| 1177 | | }}} |
| 1178 | | |
| 1179 | | === 10 e 11 Novembre === |
| 1180 | | |
| 1181 | | L'algoritmo di inserimento della stazione associanda ha un errore concettuale. Nella sezione di riga 13-16 si fa infatti affidamento sull'avvenuto adeguamento delle possibilità trasmissive della stazione associanda e dell'AP, ma questa assunzione non e` sempre assicurata dalla sezione di righe 1-3. |
| 1182 | | |
| 1183 | | Corretta la notazione del tempo dei silenzi e alcuni commenti. |
| 1184 | | |
| 1185 | | {{{ |
| 1186 | | t_s: durata totale dei silenzi |
| 1187 | | a_ui, a_di: numero di accessi in invio e in ricezione della i-esima STA |
| 1188 | | a_d = sum a_di |
| 1189 | | a_dx = a_ux = 0 |
| 1190 | | |
| 1191 | | 1 se t_s >= d_ux * a_d [ se x puo` usare silenzio per trasmettere come AP ] |
| 1192 | | 2 t_s -= d_ux * a_d |
| 1193 | | 3 a_'ux = a_d [ x trasmette come AP ] |
| 1194 | | 4 se t_s >= 0 [ se avanza silenzio ] |
| 1195 | | 5 a'_dx = t_s / (d_ux + d_dx) [ meta` silenzio per ricezioni di x ] |
| 1196 | | 6 a'_d = a_d + a'_dx |
| 1197 | | 7 a'_ux += a'_dx [ meta` silenzio per trasmissioni di x] |
| 1198 | | 8 se a'_ux <= M(a_ui) [ se x non trasmette al massimo ] |
| 1199 | | 9 a'_d = a'_ux = M(a_ui) [ ripartizione grezza trasmissioni ] |
| 1200 | | 10 ... [ normalizzazione trasmissioni ] |
| 1201 | | 11 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1202 | | 12 ... [ normalizzazione ricezioni ] |
| 1203 | | 13 altrimenti [ x trasmette al massimo ] |
| 1204 | | 14 se a'_dx <= M(a_di) [ se x non riceve al massimo ] |
| 1205 | | 15 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1206 | | 16 ... [ normalizzazione delle ricezioni ] |
| 1207 | | 17 altrimenti [ se non avanza silenzio ] |
| 1208 | | 18 a'_d = a'_ux = M(a_ui) [ ripartizione grezza trasmissioni ] |
| 1209 | | 19 ... [ normalizzazione trasmissioni ] |
| 1210 | | 20 a'_dx = M(a_di) [ ripartizione grezza ricezioni ] |
| 1211 | | 21 ... [ normalizzazione delle ricezioni ] |
| 1212 | | }}} |
| 1213 | | |
| 1214 | | === 12 Novembre === |
| 1215 | | Il problema precedentemente rilevato nell'algoritmo consiste, in definitiva, nella mancata massimizzazione delle possibilità trasmissive dell'AP sfruttabili da parte della stazione associanda. Questo adeguamento dovrebbe essere eseguito prima dell'uscita dal flusso nel blocco delle righe 13-16. |
| 1216 | | |
| 1217 | | === 13 Novembre === |
| 1218 | | Il problema evidenziato il 12 Novembre è stato risolto tramite una totale riscrittura dell'algoritmo. |
| 1219 | | La riprogettazione ha reso lo pseudocodice più snello, leggibile ed organico. |
| 1220 | | |
| 1221 | | Sono state inoltre completamente eliminate i riferimenti alle normalizzazioni. |
| 1222 | | Questa operazione era legata al fatto che si lavorasse, nelle recenti versioni dell'algoritmo, con le porzioni d'accesso delle stazioni. Ora che, invece, si interviene direttamente sul numero di trasmissioni o ricezioni la normalizzazione è superflua o insensata. |
| 1223 | | |
| 1224 | | Ecco la nuova proposta. |
| 1225 | | {{{ |
| 1226 | | t_s: durata totale dei silenzi |
| 1227 | | a_ui, a_di: numero di accessi in invio e in ricezione della i-esima STA |
| 1228 | | a_d = sum a_di |
| 1229 | | a_dx = a'_ux = 0 |
| 1230 | | |
| 1231 | | 1 se (t_s >= 0) e (t_s >= d_ux * a_d) [ se con silenzio X e AP trasmetterebbero alla pari ] |
| 1232 | | 2 t_s -= d_ux * a_d [ riduzione silenzio ] |
| 1233 | | 3 a_'ux = a_d [ X trasmette come AP ] |
| 1234 | | 4 a'_dx = t_s / (d_ux + d_dx) [ meta` silenzio per ricezioni di X ] |
| 1235 | | 5 a'_d = a_d + a'_dx |
| 1236 | | 6 a'_ux += a'_dx [ meta` silenzio per trasmissioni di X] |
| 1237 | | 7 t'_s = 0 |
| 1238 | | 8 se a'_ux <= M(a_ui) [ se x e ap non trasmet al massimo ] |
| 1239 | | 9 a'_d = a'_ux = M(a_ui) [ ripartizione trasmissioni ] |
| 1240 | | 10 a'_dx = M(a_di) [ ripartizione ricezioni ] |
| 1241 | | }}} |
| 1242 | | |
| 1243 | | === 17 Novembre === |
| 1244 | | Il carico prodotto dalle trasmissioni AP -> STA era stato aggregato nel carico unitario della stazione "Access-Point", dove il parametro d_i è calcolato come media grezza delle durate (#9). |
| 1245 | | |
| 1246 | | Riguardo la modellazione delle stime delle prestazioni ottenibili (#12) il throughput è facilmente stimato nel seguente modo, che peraltro risulta coerente con lo scenerio di saturazione preso in esame nella Tesi di Andrea Rappini. Ecco le stime del throughput in invio e in ricezione: |
| 1247 | | {{{ |
| 1248 | | T_u = a_ui * b_ui / t |
| 1249 | | T_d = a_di * b_di / t |
| 1250 | | }}} |
| 1251 | | |
| 1252 | | Al fine di fornire una stima della latenza ricettiva si intuisce la necessità di una valutazione che sappia considerare le esigenze ricettive delle varie stazioni. |
| 1253 | | |
| 1254 | | === 18 Novembre === |
| 1255 | | Riguardo #12, l'intuizione sulla latenza in trasmissione (`Lat_ui = L - d_ui + d_ui0`) aveva bisogno di una modifica. Riflettendo sul significato profondo del parametro w_ui in ambito probabilistico esso risulta essere la previsione dell'evento trasmissivo. Pertanto il carico unitario è leggibile come previsione temporale della partecipazione trasmissiva. La versione definitiva è la seguente: |
| 1256 | | {{{ |
| 1257 | | Lat_ui = L - (w_ui * d_ui) + (w_ui0 * d_ui0) |
| 1258 | | = (\sum_{j!=i} w_uj * d_uj) + w_ui0 * d_ui0 |
| 1259 | | d_ui0 = durata di una trasmissione minimale (s) |
| 1260 | | w_ui0 = 1 = peso (probabilita`) della trasmissione minimale |
| 1261 | | }}} |
| 1262 | | |
| 1263 | | Seguendo il medesimo approccio, la latenza in ricezione potrebbe essere espressa nel seguente modo: |
| 1264 | | {{{ |
| 1265 | | Lat_di = (L - (w_ui * d_ui)) / w_di + (d_di0 * w_di0) |
| 1266 | | }}} |
| 1267 | | |
| 1268 | | === 19 Novembre === |
| 1269 | | La recente lettura probabilistica del parametro `w_u` ha permesso l'ideazione della stima di latenza in ricezione. Questo tempo (è utile ricordarlo) rappresenta l'attesa dovuta ad altre trasmissioni. Queste sono già analizzate probabilisticamente dal `w_u` fornendo, per dirlo informalmente, una previsione del giro di attività. L'attesa per la ricezione è quindi costituita da "giri" di incidenza dipendente dalle probabilità ricettive. Il nuovo parametro w_di consente la quantificazione necessaria al calcolo espresso di seguito. |
| 1270 | | {{{ |
| 1271 | | w_di = a_di / M(a_di) |
| 1272 | | Lat_di = (\sum_{j!=i} w_dj) * (\sum_{j!=i} w_uj * d_uj) |
| 1273 | | }}} |
| 1274 | | |
| 1275 | | === 20 Novembre === |
| 1276 | | Emergono dubbi sull'eccesso di stima della latenza. L'attesa di trasmissione ad esempio non dovrebbe essere costituita dall'interezza di un giro di trasmissioni, come se il giro iniziasse sempre dopo di essa. Forse l'idea di dimezzare questa quantità (usata nelle trascorse stime di latenza) va ripresa i considerazione. |
| 1277 | | |
| 1278 | | === 25 Novembre === |
| 1279 | | La latenza è costituita dal tempo di attesa e dal tempo effettivamente necessario alla comunicaizone. Il tempo di attesa precedentemente formalizzato deve essere dimezzato, in modo da rappresentare la previsione della posizione della comunicazione della stazione all'interno del tempo di attesa. Ecco come la latenza in trasmissione e in ricezione sono pertanto riformulate: |
| 1280 | | {{{ |
| 1281 | | Lat_ui = (\sum_{j!=i} w_uj * d_uj)/2 + w_ui0 * d_ui0 |
| 1282 | | Lat_di = (\sum_{j!=i} w_dj)/2 * (\sum_{j!=i} w_uj * d_uj) |
| 1283 | | }}} |
| 1284 | | |
| 1285 | | === 26 e 27 Novembre === |
| 1286 | | [113]: Creazione di uno scheletro di documento LaTeX, pronto per accogliere i contenuti man mano che saranno stesi in forma organica (#15). Inserimento e formattazione di tutti i risultati nell'analisi finora formalizzata (#11). |
| 1287 | | |
| 1288 | | [114]: Piccole manuntenzioni sul deposito SVN. |
| 1289 | | |
| 1290 | | === 28 Novembre === |
| 1291 | | Se il parametro `w_di` ha una reale valenza nella stima della latenza, forse esso andrebbe usato anche nel calcolo del carico, come peso con il quale ponderare le durate delle varie ricezioni. |
| 1292 | | |
| 1293 | | == Dicembre 2008 == |
| 1294 | | === 1 e 2 Dicembre === |
| 1295 | | Il calcolo del carico è in effetti da rivedere, proprio perché la semplice media grezza delle durate delle ricezioni non rappresenta adeguatamente il grado di congestione dell'AP, poiché il grado di partecipazione ricettiva non è sufficientemente espressa. Ecco la riformulazione proposta (#9): |
| 1296 | | {{{ |
| 1297 | | l_d = w_{uAP} * \sum_{i!=AP} l_di |
| 1298 | | l_di = w_{di} * d_{di} / n_{STA} |
| 1299 | | }}} |
| 1300 | | |
| 1301 | | Grazie ad ulteriori riflessioni, la versione del carico in ricezione precedentemente proposta si è rivelata errata. Ecco la nuova versione: |
| 1302 | | {{{ |
| 1303 | | l_{di} = w_{dj} \left( d_{dj} + p_u \sum_i{l_{ui}} \right) |
| 1304 | | }}} |
| 1305 | | |
| 1306 | | === 3 Dicembre === |
| 1307 | | Ho inserito gli ultimi risultati nella tesi, eseguendo alcuni aggiustamenti volti al miglioramento dell'organicità del modello, nella mappa concettuale come nell'esposizione. |
| 1308 | | |
| 1309 | | === 4 Dicembre === |
| 1310 | | Completamento delle operazioni di aggiornamento sulla mappa e sulla tesi [124]. |
| 1311 | | |
| 1312 | | Riguardo la quantificazione della presenza dell'AP all'interno del carico del canale si è presa in considerazione la possibilità di utilizzare una misurazione basata sulle probabilità ricettive delle stazioni, (con i parametri `w_di` ). Nonostante ci sia definitivamente convinti dell'interdipendenza fra il carico del canale (o trasmissivo) e quello dell'AP (o ricettivo), l'ipotesi è stata scartata. Infatti la misura della partecipazione dell'AP deve essere unicamente basata sulla previsione di durata del suo accesso, senza doverne quantificare il grado di congestione. |
| 1313 | | |
| 1314 | | === 5 Dicembre === |
| 1315 | | [128] Miglioramento nell'esposizione del carico del canale, specificando i dettagli sulle ultime decisioni. Formattazione dell'algoritmo di inserimento della stazione associanda (l'esposizione resta migliorabile). Piccoli aggiustamenti sulla mappa concettuale. |
| 1316 | | |
| 1317 | | === 8 Dicembre === |
| 1318 | | [128] Iniziata la stesura del modello di rete (#18) che si rivela, rispetto all'ultima versione, riducibile di parecchi dettagli diventati inutili. |
| | 4 | = [wiki:Diario/SoujaK/2007 ''Anno 2007''] = |
| | 5 | = [wiki:Diario/SoujaK/2008 ''Anno 2008''] = |
| | 6 | = ''Anno 2009'' = |
