[Ninux-Wireless] fast-olsr

Gioacchino gmazzurco89 a gmail.com
Sab 27 Feb 2010 12:26:19 CET


si questo e' il discorso esaminato nelle sue casistiche, praticamente abbiamo 
quindi visto che per un nodo che si muove il max che si puo' fare e' qualcosa 
tipo fast-olsr ( cmq i 150km/h non interessavano a me ma sono quelli riportati 
nei loro "studi" ) che da quello che dicono funziona anche abbastanza bene ora 
bisogna trovare il sorgente o riscriverlo ( dalla spiegazione che fanno non 
sembra troppo complicato ) 

nel caso due bisogna vedere come fare un'idea era usare una subnettona gigante 
per tutti i client cosi' che spostandosi da un nodo all'altro non sia 
necessario cambiare ip ma a questo punto bisogna vedere come si comporta 
l'instradamento verso la nuova strada

On Saturday 27 February 2010 10:43:57 Antonio Anselmi wrote:
> 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



Maggiori informazioni sulla lista Wireless