[Ninux-Wireless] fast-olsr

Filippo Sallemi tonyputi a gmail.com
Sab 27 Feb 2010 11:21:27 CET


Grande Antonio!


Il giorno 27 febbraio 2010 10.43, Antonio Anselmi
<tony.anselmi a gmail.com>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 <tonyputi a gmail.com> 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 <reiser4 a gmail.com> ha
> scritto:
> >>
> >> Il giorno 26 febbraio 2010 19.56, Gioacchino <gmazzurco89 a gmail.com> 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
> >> Wireless a ml.ninux.org
> >> http://ml.ninux.org/mailman/listinfo/wireless
> >>
> >
> >
> >
> > --
> > Filippo Sallemi
> >
> > _______________________________________________
> > Wireless mailing list
> > Wireless a ml.ninux.org
> > http://ml.ninux.org/mailman/listinfo/wireless
> >
> >
> _______________________________________________
> Wireless mailing list
> Wireless a ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
>



-- 
Filippo Sallemi
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/wireless/attachments/20100227/2800f2be/attachment-0001.html>


Maggiori informazioni sulla lista Wireless