|  | 641 | == 03 Luglio == | 
                          |  | 642 |  | 
                          |  | 643 | 0950 - 1415 (4.41h) | 
                          |  | 644 |  | 
                          |  | 645 | Aggiornamento del diario. | 
                          |  | 646 |  | 
                          |  | 647 | Riflessione: dal momento che SNR dovrebbe essere sufficiente per la valutazione | 
                          |  | 648 | delle condizioni del mezzo, mi chiedo perche' i produttori di schede 802.11 non | 
                          |  | 649 | utilizzino questo fattore: una causa potrebbe essere ricercata nel fatto che | 
                          |  | 650 | questo indicatore non e' sufficientemente preciso (e.g. troppo discretizzato). | 
                          |  | 651 |  | 
                          |  | 652 | Approfondimento di 25. | 
                          |  | 653 |  | 
                          |  | 654 | Dando un'occhiata veloce a 26, trova forse risposta la domanda precedente: gli | 
                          |  | 655 | AP, e piu' in generale i dispositivi 802.11, possono utilizzare tecniche per | 
                          |  | 656 | limitare la potenza trasmissiva in un'ottica di economia degli apparecchi. Lo | 
                          |  | 657 | studio puntualizza pero' che questi meccanismi sono raramente adottati (questa | 
                          |  | 658 | informazione necessita di verifica dal momento che lo studio e' piuttosto | 
                          |  | 659 | datato). Lo studio assume che l'RSS abbia, in media, una relazione lineare con | 
                          |  | 660 | l'SNR. | 
                          |  | 661 |  | 
                          |  | 662 | Correlazione tra l'RSSI e qualita' del collegamento: da ricerche effettuate | 
                          |  | 663 | sembrano emergere pareri discordanti riguardo la bonta' di questo indicatore. | 
                          |  | 664 | I detrattori sostengono che non c'e' uniformita' tra gli implementatori e che i | 
                          |  | 665 | valori forniti non sono affatto precisi. In aggiunta, si consideri anche il | 
                          |  | 666 | problema evidenziato in precedenza legato al controllo della potenza di | 
                          |  | 667 | trasmissione. [[BR]] | 
                          |  | 668 | Sembra essere piu' affidabile (per la stima del ''packet error rate''), invece, | 
                          |  | 669 | il ''Link Quality Indicator'' (LQI) che meriterebbe un approfondimento. | 
                          |  | 670 |  | 
                          |  | 671 | Assieme a soujak: breve condivisione di conoscenze, aggiustamento della mappa | 
                          |  | 672 | mentale (sottoalbero carico teorico) alla luce di alcune considerazioni | 
                          |  | 673 | effettuate sugli errori dei ''frame'' e loro incidenza sulla determinazione del | 
                          |  | 674 | carico. | 
                          |  | 675 |  | 
                          |  | 676 | 1520 - 1530 (0.16h) | 
                          |  | 677 |  | 
                          |  | 678 | Aggiornamento del diario. | 
                          |  | 679 |  | 
                          |  | 680 | 1630 - 1830 (2h) | 
                          |  | 681 |  | 
                          |  | 682 | Assieme a soujak: riflessioni sulla determinazione del ''data rate'' della STA | 
                          |  | 683 | associanda alla luce di quanto letto recentemente. Essendo la questione | 
                          |  | 684 | abbastanza problematica si e' deciso che si faranno delle approssimazioni che | 
                          |  | 685 | potrebbero essere significative. Una soluzione che stimi il ''data rate'' | 
                          |  | 686 | conoscendo il ''vendor'' di una scheda, e quindi il meccanismo adottato, appare | 
                          |  | 687 | non percorribile. | 
                          |  | 688 |  |