Grande Antonio!
Il giorno 27 febbraio 2010 10.43, Antonio Anselmi <[email protected]>ha scritto: > la caduta di chiamate non dipende tanto dalla velocita' con cui ti > muovi ma dal conseguente fatto che cambiando il path (la route) devi > rinnovare gli handshake TCP con il next hop. Ergo: quanto piu' a lungo > la route e' considerata valida (anche se degradata) minore e' il > rischio di connessioni TCP abbattute (poprio perche' cambia il > gateway). > > olsrd usa l'algoritmo "shortest path first" per quanto riguarda il > mantenimento dello status di un link (almeno le versioni RFC > compliant...). Ora supponiamo che: > > - al tempo t0 sei collegato al gateway G con un solo hop (te -> nodo G) > - al tempo t0+n e' *disponibile* una rotta migliore: te -> > nodo-intermedio -> nodo G (2 hop) > > orbene, olsrd privilegia il link con un solo hop (con ETX povero) a > dispetto due hop (ciascuno con ETX migliore). Questo "dovrebbe" > garantire una certa persistenza delle connessioni TCP, perlomeno in > presenza di una mobilita' "circolare", ovvero ti muovi gironzolando e > NON orizzontalmente "in fuga". > > Ma non bisogna esagerare nel tenersi "stretta" una rotta che - piu' o > meno velocemente - sta' degradandosi, e qui entra in gioco la > velocita'. > Occorre anche stimare il ritardo tra "quando" la route e' andata > definitivamente a fangala e "quando" (invece) olsrd ne prendera' atto. > Ovvero riflettere sia su gli intervalli con cui le informazioni sono > aggiornate (Hello e TC interval) sia sul periodo di tempo durante il > quale quelle informazioni sono considerate attendibili *anche* in > assenza di un loro aggiornamento (soft state). Un soft state > eccessivamente conservativo rischia di mantenere come praticabili > rotte che in realta' sono cadute. > > Diminuendo i due valori HelloInterval e HelloValidityTime otterremo > sicuramente un demone piu' reattivo ai cambiamenti di topologia ma > aumenteremo - e non di poco - l'overhead (la vita e' un compromesso). > > In buona sostanza, email, web o chat (o streaming video se > bufferizzati) non creano grossi problemi mentre il voip ne risente in > misura maggiore. > > Ma non e' finita qui.... > > Altre considerazioni devono essere fatte a seconda che il terminale > skype stesso esegua olsrd (ed e' quindi lui stesso un nodo del mesh!) > oppure se il termnale skype si connette ad un nodo meshato (magari > statico, montato su un palo) che esegue olsrd. > In questo ultimo caso non e' la mobilita' del nodo mesh che deve > essere presa in considerazione (e quindi tutto l'ambaradan di olsrd) > bensi' la mobilita' di un client nei confonti di un AP. > > ...post poco adatto per un sabato mattina (quasi) primaverile, ma mi > e' presa cosi' :) > > > Antonio > > > > Il 27 febbraio 2010 04.08, Filippo Sallemi <[email protected]> ha > scritto: > > Gioacchino intende questo.... > > se io sono in un parco comunale, tipo villa margherita, e mi muovo a > piedi > > trai nodi, come faccio a non far cadere la mia chiamata skype? > > Ovviamente lui pensa in grande e 150 Km/h sono tanti, a me ne > basterebbero > > 1/3 per far contentala gente... e sarebbero costretti a non correre :-) > > Ovviamente la risposta più banale è IPv6 ma non sono io l'esperiente in > > merito. > > Ciao > > > > Il giorno 26 febbraio 2010 20.08, Reiser4 <[email protected]> ha > scritto: > >> > >> Il giorno 26 febbraio 2010 19.56, Gioacchino <[email protected]> ha > >> scritto: > >>> > >>> ciao ragazzi > >>> cercando come si comporta olsr con al mobilita' ho trovato informazioni > >>> su un > >>> plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a > >>> 150km/h > >>> una perdita di pacchetti del 15% ma cercando il sorgente o comunque un > >>> modo > >>> per poterlo usare ho trovato solo un'archivio su una pagina di un > >>> professore > >>> francese che contiene cose che il mio pc dice che sono script mathlab > ma > >>> se li > >>> apro con un editor di testo mi dice che sono binari infatti del testo > si > >>> riesce a leggere solo qualcosa il resto sono simboli strani > >>> > >>> cosa ne sapete/pensate voi ? > >>> > >> > >> andando a 150km/h hai perso per strada la punteggiatura? non capisco la > >> finalità del mesh a 150km/h nè come possa un plugin cambiare la > situazione. > >> Spiegaci cosa vuoi fare che ci pensiamo su.. > >> Enrico > >> > >> _______________________________________________ > >> Wireless mailing list > >> [email protected] > >> http://ml.ninux.org/mailman/listinfo/wireless > >> > > > > > > > > -- > > Filippo Sallemi > > > > _______________________________________________ > > Wireless mailing list > > [email protected] > > http://ml.ninux.org/mailman/listinfo/wireless > > > > > _______________________________________________ > Wireless mailing list > [email protected] > http://ml.ninux.org/mailman/listinfo/wireless > -- Filippo Sallemi
_______________________________________________ Wireless mailing list [email protected] http://ml.ninux.org/mailman/listinfo/wireless
