<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 8 maggio 2015 04:10, Stefano De Carlo <span dir="ltr"><<a href="mailto:stefanauss@gmail.com" target="_blank">stefanauss@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao a tutti,<br>
<br>
stasera il buon Peppe è stato fermato durante una sessione d'uso concreto di NinuCS (vnc tra lui e ulisse) dalle pessime performance della rete. Non era l'unico, pertanto sotto i riflettori è finita in particolare la Rocket a NewSpig.<br>
<br>
Da una rapida e sicuramente incompleta analisi sono emerse queste cose:<br>
<br>
* Non c'è packet loss nè vero e proprio down<br>
* CCQ, latenza ma soprattutto e specialmente TX/RX sono ballerini.<br>
* Airmax quality/capacity hanno avuto salti confermati e improvvisi del 30% su almeno una STA (BrodoliniBeam).<br></blockquote><div><br></div><div>Non è che mi faccia impazziere quest'ultima  riga, considerando quello che voglio fare.<br><br></div><div>Però confido nei risultati che ninux ha saputo dare alla nostra rete.<br><br></div><div>:-D<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Il sintomo concreto è molto jitter e throughput basso.<br>
* Un site survey a Brodo non dà altro sul canale di NewSpig<br>
* Alcune STA potrebbero metterci di più ad associarsi (non confermato), ma di certo impiegano di più a rientrare nelle statistiche delle STA attive.<br>
<br>
Sappiamo anche bene che<br>
* il numero di STA collegate a NewSpig è aumentato negli ultimi mesi<br>
* di conseguenza c'è più traffico operativo<br>
* Un certo numero di STA, in particolare quelle di ingresso recente, hanno puntamenti subottimali.<br>
<br>
Ovviamente un reboot è stato tentato ma non è servito. Si è però notato che i parametri (CCQ, latenza, quality, capacity) hanno un rapido abbassamento al collegamento delle ultime 3-4 STA (non in ordine cronologico, si intende al riassociamento), ma nel frangente immediatamente precedente perlomeno la latenza sembra stabile e lo jitter minimo. Poi, quando tutti si riassociano, tutto come prima.<br>
<br>
L'idea è quella di testare, per un periodo limitato di tempo ma comunque sufficientemente esteso a farci capire, il blacklisting (ACL deny) progressivo di alcune STA a partire da quelle meno performanti. I proprietari saranno, ovviamente, informati prima di procedere. Questa cosa è time-consuming e una volta cominciata richiede di essere seguita, quindi va organizzata bene.<br></blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Speriamo che questo lavoro di bisezione possa rivelare una singola station problematica, in modo da concentrarci sul fixarla.<br>
<br>
Sappiamo bene che il fix a lungo termine di questa situazione è la diminuizione dei single-point-of-failure, la supernodizzazione, la ridondanza, la ripartizione dei carichi, l'aumento del meshing insomma. Sappiamo anche bene che nuovi ingressi sono 100x più importanti di qualsiasi throughput. Tuttavia studiare quale sia il limite per le settoriali ha implicazioni importanti per il futuro, e tanto vale fare questi test "distruttivi" quando la nostra rete è piccola. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ci organizzeremo ASAP per questo test.<br>
<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stefanauss.<br>
<br>
<br>_______________________________________________<br>
Calabria mailing list<br>
<a href="mailto:Calabria@ml.ninux.org">Calabria@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/calabria" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/listinfo/calabria</a><br>
<br></blockquote></div><br></div></div>