On 12/09/2014 11:14 PM, leonaard wrote: > On 12/09/2014 09:41 PM, Francesco Frassinelli wrote: >> Il 9 dicembre 2014 21:28, leonaard <le...@inventati.org> ha scritto: >>>> Ciao, ho linkato una buona spiegazione della differenza sostanziale tra >>>> olsr e batman [0] e delle differenze di performance tra i due [1]. >> Il link è del 2009 e analizza una vecchia versione di batman (la 0.3, >> non la adv) quindi non so se possa essere calido. > > Sono ancora validi: olsr afaik non e' progredito molto da allora, e in > ogni caso la differenza strutturale spiegata nel link [0] rimane ed e' > quella ad influenzare molto le prestazioni.
lasciami dissentire. La storia di olsr.org dal sito di batman non mi è mai piaciuta molto. Sostanzialmente si può riassumere in "non funzionava, abbiamo fatto un po' di modifiche in direzioni più o meno coerenti tra loro, alla fine abbiamo lasciato perdere e ne abbiamo fatto uno nuovo". Se prendi un protocollo, gli togli e rimetti pezzi in ordine sparso, poi non ti puoi aspettare che tutto funzioni. Ad esempio (vado a memoria) prima togli isteresi ed MPR perchè "non funzionano". Poi scopri che questo genera più segnalazione, e allora inventi fisheye, che introduce loop per definizione, e ti lamenti dei loop. poi dici che hopcount non funziona, e introduci ETX, ma non hai più isteresi sui link e le rotte flappano... etc. n.b. non dico che sia andata veramente cosi'. dico solo che a leggere quel sito la storia è riportata cosi'. e che i problemi riportati sono comuni un po' a tutti i protocolli proattivi, solo che olsr è stato il primo implementato, quindi è facile dargli contro. Per quel che riguarda le performance, e l'altro paper che hai citato, lascia perdere. Con una topologia di 6 nodi indoor puoi dimostrare tutto ed il contrario di tutto. soprattutto se prendi olsr con la metrica hop-count, e non dici come hai fatto tuning dei parametri. Io conosco poco batman, ma in ogni caso, per me, trovare un motivo percui "uno è meglio di un altro", è impossibile. Le differenze le conosciamo, (layer2/3, distance vector/link state ecc) poi come questo influenzi macroscopicamente il funzionamento della *tua* rete, è difficile da dire. secondo me se non vuoi avere mobilità, la differenza è limitata. Forse rispondendo all'email orginale, è il caso di studiarli un po' e decidere anche in funzione di quanto uno li capisce e quanto la gente intorno ti può aiutare. > Riguardo a olsr2 (in fase sperimentale) cedo il testimone :) ipoteticamente ha una metrica nuova che funzionerebbe meglio di ETX, è tutto pluginabile quindi puoi modificarlo come ti pare, hanno migliorato diverse cose che non funzionavano in OLSRv1 (tipo la definitione degli mpr, il supporto a ipv6). C'e' una RFC dietro, quindi puoi capire come funziona senza studiarti il codice (ad esmepio invece per bmx6 non c'e' ancora molto). Non so quanto sia stabile l'implementazione, so che Henning è uno bravo. ciao, leonardo. -- www.leonardo.ma / twitter: @leobowski ninux evangelist. gpg Key ID: AABE2BD7 _______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless