wiki:Diario/SoujaK

Version 3 (modified by soujak, 17 years ago) (diff)

Aggiornamento.

Diario di SoujaK

4 Giugno 2007

Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion (2h).

5 Giugno 2007

Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web (1h).

11 Giugno 2007

Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico. (0.4h)

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. Lo studio prende in considerazione uno scenario privo di disturbi ambientali, senza coordinamento centralizzato. 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"). 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". La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate (1400-1740).

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. (1800-1820, 1900-1920)

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)

12 Giugno 2007

1000-1020 (0.33h)
Sincronizzazione del diario.

1030-1100 (0.50h)
Punto della situazione assieme a gnappo.

1120-1155 (0.58h)
03: In appendice è presente un'interessante calcolo dell'impatto degli errori di trasmissione sulle prestazioni, calcolando diligentemente i dettagli relativi ai backoff incrementali.

1210-1310 (1.00h)
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. 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. 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. 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. I concetti appena descritti appaiono come spunti piuttosto rilevanti ai nostri fini.

1450-1617 (0.45h)
Ricerche ulteriori.

1650-1720 (0.67h)
Approfondimento di 03.

13 Giugno 2007

0850-0910 (0.33h)
Approfondimento di 04.

1000-1025 (0.41h)
Sincronizzazione del diario.


Documentazione

Link Utili