Aggiornamento Netgroup R.Gomezel Commissione Calcolo e Reti Presidenza 5/10/2010-7/10/2010.

Presentazione sul tema: "Aggiornamento Netgroup R.Gomezel Commissione Calcolo e Reti Presidenza 5/10/2010-7/10/2010."— Transcript della presentazione:

1 Aggiornamento Netgroup R.Gomezel Commissione Calcolo e Reti Presidenza 5/10/2010-7/10/2010

2 Attività in corso e da completare Technology tracking apparati di rete Continua attività gruppo lavoro IPv6 ▫Francesco Prelz partecipa prossimo HEPiX a Ithaca per relazionare su IPv6 e problematiche Piano di studio per valutare e analizzare le problematiche del TCP in presenza di server a 10 Gb con WN a 1 Gb 2

3 Gruppo d'interesse IPV6 (Francesco Prelz, Luca Carbone, Giuseppe Sava, Riccardo Veraldi) La pagina html del gruppo di lavoro si trova all’URL ▫http://www.mi.infn.it/ipv6/http://www.mi.infn.it/ipv6/ Continua l’attività di consulenza e viene seguito lo sviluppo e il deployment del protocollo in modo tale da segnalare eventuali problemi o necessità cui l’INFN deve porre attenzione Relazione dello stato IPv6 al prossimo HEPiX Non si è accertato quali sezioni o gruppi collegati INFN abbiano di fatto attivato il filtro per IPv6 quando non configurato – si ribadisce la necessità di applicare il filtro sul router di accesso prima possibile

4 Problematica performance 10Gb Genova prima e poi confermato da test a Trieste avevano evidenziato problematica di basse performance collegamenti server a 10Gb verso WN a 1 Gb su switch Extreme Inizialmente tra X650 concentratore porte 10Gb con X35o connessi con uplink 10Gb ▫In seguito a prestito X450 da Lantech si sono evidenziate le medesime basse performance ▫Questo ha escluso l’hw come problema

5 Problematica performance 10G In seguito si è continuato i test utilizzando gli X350 Un server a 10Gb connesso al X650 verso WN a 1 Gb connessi all’X350 (12) ▫I test evidenziavano che non veniva saturata la banda quando i WN prelevavano dati dal server ▫A volte risultati imbarazzanti ▫L’uso del flow control sullo switch aiutava ma poco ▫Quindi si è passati a provare con UDP e si è così verificato che la banda veniva saturata

6 Problematica performance 10G Apparso chiaro che il problema sta nell’implementazione dell’algoritmo del controllo flusso e congestione del TCP Prove con Reno e BIC (default su SL) hanno dato gli scarsi risultati evidenziati nei primi test Disabilitando flow control e utilizzando Vegas per il controllo congestione si riesce su rete locale a sfruttare la banda 10Gb in modo significativo

7 Proposta di studio A questo punto appare chiaro che la prossima fase di lavoro consiste nel verificare un tale comportamento anche in altre configurazioni hw e programmare dei test mirati che possano analizzare e poi proporre le soluzioni migliori per sfruttare la banda trasmissiva delle nostre farm distinguendo in connessione su LAN o su WAN dove invece il delay legato alla distanza introduce altre variabili