Ecco qua un po' di trucchi da usare se si soffre di problemi di basso throughput Ethernet o per guadagnare un pochino di velocità nei trasferimenti ftp.
Il programma ttcp.c è un buon test per misurare la velocità di
throughput. Un altro modo comunemente usato è di fare un ftp> get
grosso_file /dev/null dove grosso_file è >1MB e
risiede nel buffer della macchina in trasmissione (si faccia il 'get' almeno
due volte, poiché la prima volta si caricherà la cache del buffer
nella macchina in trasmissione). Si deve mettere il file nella
cache del buffer perché non si è interessati ad includere nella
misura la velocità di accesso ai file dal disco. Questo è anche
il motivo per cui si inviano i dati in ingresso a /dev/null
piuttosto che al disco.
Anche una scheda a 8 bit è in grado di ricevere pacchetti back-to-back (uno dietro l'altro) senza alcun problema. Le difficoltà nascono quando il computer non riesce a estrarre i pacchetti ricevuti dalla scheda abbastanza velocemente da far spazio ai pacchetti in arrivo. Se il computer non libera abbastanza velocemente la memoria della scheda dai pacchetti già ricevuti, la scheda non avrà spazio dove mettere i nuovi pacchetti.
In questo caso o si perdono (drop) i nuovi pacchetti oppure si scrivono sopra a quelli già ricevuti (overrun). In entrambi i casi si interrompe seriamente il flusso regolare del traffico causando/richiedendo la ritrasmissione e degradando seriamente le prestazioni fino ad un fattore di 5!
Le schede con a bordo più memoria sono in grado di bufferizzare più pacchetti e quindi gestire grossi picchi di traffico (burst) back-to-back senza perdere nessun pacchetto. D'altra canto questo significa che la scheda non necessita di una così bassa latenza nell'estrazione dei pacchetti dal buffer da parte del computer per evitare la perdita di pacchetti.
La maggior parte delle schede a 8 bit hanno un buffer da 8kB e la maggior parte di quelle a 16 ne hanno uno da 16kB. La maggior parte dei driver per Linux riserva 3kB del buffer per due buffer di trasmissione, quindi nel caso di una scheda a 8 bit rimangono solo 5kB di spazio per la ricezione. Questo è spazio sufficiente solo per tre pacchetti Ethernet a dimensione massima (1500 byte).
Come menzionato in precedenza, se i pacchetti vengono rimossi abbastanza velocemente dalla scheda allora la condizione di drop/overrun non si verificherà anche se la dimensione del buffer per i pacchetti in arrivo è ridotta. Il fattore che determina la frequenza con la quale i pacchetti vengono rimossi dalla scheda e messi nella memoria del computer corrisponde alla velocità del percorso dati che collega le due, ovverosia la velocità del bus ISA (ma se la CPU è un vecchio e lento 386sx-16 allora anche questo avrà la sua influenza).
Il clock del bus ISA raccomandato è circa 8Mhz, ma molte schede madri e dispositivi periferici possono essere fatti funzionare a frequenze più elevate. La frequenza di clock per il bus ISA solitamente può essere impostata nel setup della CMOS, selezionando un divisore della frequenza di clock della scheda madre/CPU. Alcune schede madri ISA e PCI/ISA possono non avere questa opzione e quindi si è vincolati dalle impostazioni di fabbrica.
Per esempio, ecco qui alcune velocità di ricezione misurate dal programma TTCP su un 486 a 40Mhz, con una scheda a 8 bit WD8003EP, a diverse velocità del bus ISA.
Velocità bus ISA (MHz) Rx TTCP (kB/s)
---------------------- --------------
6.7 740
13.4 970
20.0 1030
26.7 1075
Voglio vedere chi riesce a far meglio di 1075kB/s con una qualsiasi scheda Ethernet a 10Mb/s usando TCP/IP. Comunque, non ci si aspetti che qualsiasi sistema funzioni a velocità del bus ISA molto elevate. La maggior parte dei sistemi non funzioneranno correttamente a velocità superiori a 13MHz (inoltre, in alcuni sistemi PCI la velocità del bus ISA è bloccata a 8 Mhz, cosicché l'utente finale non ha la possibilità di incrementarla).
Oltre a una velocità di trasferimento più elevata, si trarrà anche beneficio da una riduzione nell'uso della CPU dovuta alla durata minore dei cicli di memoria e di I/O (si noti che anche i dischi fissi e le schede video presenti nel bus ISA mostreranno solitamente un aumento delle prestazioni dovuto all'incremento della velocità del bus ISA).
Ci si assicuri di fare un back up dei propri dati prima di fare esperimenti con velocità del bus ISA superiori agli 8Mhz e di controllare accuratamente che tutte le periferiche ISA funzionino correttamente dopo aver fatto qualsiasi incremento alla velocità del bus.
Ancora una volta, le schede con poca memoria RAM a bordo e percorsi dati tra la scheda e la memoria del computer relativamente lenti avranno dei problemi. L'impostazione predefinita per la finestra di ricezione TCP è di 32kB, il che significa che un computer veloce nella sottorete a cui appartiene la propria macchina, può scaricare in quest'ultima 32kB di dati senza fermarsi per controllare se tutti sono stati ricevuti correttamente.
Le versioni recenti del comando route hanno la possibilità di
impostare al volo la dimensione di questa finestra. Solitamente
la riduzione della dimensione di questa finestra è necessaria solo
per la rete locale, poiché i computer che sono dietro ad un paio
di router o gateway sono abbastanza 'bufferizzati' da non avere
problemi. Un esempio d'uso potrebbe essere:
route add <qualcosa> ... window <dim_fin>
dove dim_fin è la dimensione della finestra che si vuole usare
(in byte). Una scheda 3c503 a 8 bit su un bus ISA che va a 8Mhz o
meno dovrebbe funzionare bene con una dimensione della finestra di
circa 4kB. Una finestra troppo grande causerà drop e overrun dei
pacchetti e una riduzione drastica del throughput. Si possono
verificare le condizioni operative con cat /proc/net/dev,
che elencherà il numero di drop/overrun verificatisi.
Alcuni utenti hanno osservato che l'uso di una scheda a 8 bit con client NFS causa prestazioni peggiori di quanto previsto quando vengono usati pacchetti di 8kB (la dimensione nativa Sun).
Una possibile causa di questo potrebbe essere la differente dimensione del buffer a bordo tra schede a 8 e 16 bit. La dimensione massima di un pacchetto Ethernet è di approssimativamente 1500 byte. Affinché arrivi un pacchetto NFS di 8kB ci vogliono circa sei pacchetti back to back Ethernet di dimensione massima. Sia le schede a 8 bit che quelle a 16 non hanno problemi a ricevere pacchetti back to back. Il problema sorge quando la macchina non rimuove in tempo i pacchetti dal buffer della scheda e il buffer va in overflow. Il fatto che le schede a 8 bit necessitano di un ulteriore ciclo di bus ISA per ogni trasferimento non aiuta. Quel che si può fare se si ha una scheda a 8 bit è di impostare la dimensione del trasferimento NFS a 2kB (o anche 1kB) o provare a incrementare la velocità del bus ISA per far sì che il buffer della scheda venga svuotato più velocemente. Ho scoperto che una vecchia scheda WD8003E a 8MHz (senza altro carico di sistema) può sostenere un traffico notevolei a dimensioni NFS di 2kB, ma non a 4kB, dove le prestazioni si degradano di un fattore tre.
D'altra parte, se l'opzione predefinita di mount è di usare la dimensione di un 1kB per i pacchetti NFS e si usa come minimo una scheda ISA a 16 bit, si riscontrerà un incremento significativo nel passare a pacchetti NFS di 4kB (o addirittura 8kB).