Newsgroup: it.comp.os.linux.sys
Titolo: ethernet overrun

Ciao,
ricevo, da qualche ora a 'sta parte, una marea di overrun su
una scheda di rete gigabit.
Leggendo in giro, sembra che il server non riesca a rimuovere
tutti i dati dal buffer della scheda prima che ulteriori frame
'montino' sopra a quelli già presenti in buffer.
Strano, la scheda è gigabit ed il traffico su tale interfaccia
è di circa 15mbit.
Sapete dirmi se c'è qualche parametro da modificare o verificare
per identificare il problema?
Grazie.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.


lo switch che dice?
che roba  e'?

 che roba  e'?
Lo switch? Un huawei quidway 3900 o giù di li. Non ricordo il modello
esatto in questo momento ma non è propriamente economico.
Siamo nella fascia degli 800-1000 euro l'ultima volta che ne guardai
il valore (1-2 anni fa)
Faccio presente che cambiando nic, con una identica, tutto è
ripartito.
Può essere quindi che sia la nic che mi stia per lasciare?
Come faccio a sapere sia quanto è grosso il buffer delle schede di
rete (in questo caso delle broadcom gigabit) in modo da poter valutare
gli acquisti futuri?


penso sia scritto sul datasheet della scheda. ma fino ad oggi, non ho 
ancora trovato una scheda a cui ho riempito il buffer, se non a causa di 
problemi di trasmissione dovuti a cavo (di solito). altrimenti fai un 
bonding su più schede e dovresti andare meglio. ma questo (di solito) 
prevede un intervento anche sullo switch...

 prevede un intervento anche sullo switch...
Mai visto sui datasheet, ne sulle Intel 1000/PT (che dovrebbero essere
di ottima qualità) ne sulle più economiche broadcom.
Lato Linux, si può verificare il buffer della scheda ed il valore di
riempimento?
Il bonding non lo posso fare, questo è escluso. Lo chiesi già a suo
tempo per altri motivi e non l'hanno approvato.


prova con ethtool. non posso verificare al momento

 prova con ethtool. non posso verificare al momento
Ci avevo guardato, ma in fretta, e non mi pare di aver visto niente di
utile.


l'unica altra cosa da guardare è lato switch. se è manageable, di sicuro 
ha qualche contatore di errori sulla porta.
anche se il fatto che ti lasci a piedi di botto non è così frequente. di 
solito è solo una porta rotta, e basta prenderne un'altra.
io procederei cambiando solo la nic e vedendo come va.

 io procederei cambiando solo la nic e vedendo come va.
Se fosse la porta, però, cambiando nic in teoria avrei lo stesso
problema
ed invece adesso mi sembra stabile. l'up/down della porta non è stato,
dato che ho fatto almeno 2 volte up/down con la vecchia nic e non è
cambiato nulla.

 è di circa 15mbit.
mi confermi 15mbit = 1.8Mb/s ?
perchè qualora fossero 15Mb/s sei molto vicino al troughput del gigabit 
"reale" che si aggira intorno ai 22-24Mb/s (quindi comunque a tale 
velocità qualche errorino saltuario di buffer potrebbe anche essere 
fisiologico).

 gli acquisti futuri?
in genere però il buffer è abbondante rispetto al troughput della 
scheda. è un parametro abbastanza poco interessante.
nelle nic un aspetto interessante è la capacità di elaborare 
direttamente i pacchetti senza appesantire le cpu, è anche uno dei 
motivi per cui una nic costa 3,50 euro ed un'altra ne costa 200.
http://developer.intel.com/network/connectivity/solutions/gigabit.htm
Intel PRO Gigabit Server Adapters enhance server efficiency. Intel 
offload technologies, Large Send Off (LSO) and TCP Checksum Offload, 
unburden the server by moving CPU intensive network tasks off the server 
and onto the adapter card.

 fisiologico).
Eh?
15Mbit non è vicino a 1000Mbit... è 1/60....

 motivi per cui una nic costa 3,50 euro ed un'altra ne costa 200.
Si, ma considerato che è appoggiata ad una macchina QuadCore Xeon 2.50
con
4GB di ram quando, attualmente, sta usando 400-500m di ram (senza
contare le cache)
ed ha un load, nei picchi, pari a 0.1, anche se appesantirebbe la CPU
non dovrebbe
essere un problema.

 15Mbit non è vicino a 1000Mbit... è 1/60....
---> perchè qualora fossero 15Mb/s --> 120Mbit effettivi
non è il tuo caso, sei decisamente scarico in quella situazione. 
probabilmente la nic aveva semplicemente un problema sul buffer. accade 
di rado, ma accade.
ciao.


e allora, rispondendo alla tua domanda circa l'acquisto giusto da fare, 
qualsiasi scheda di rete penso vada più che bene. anche la broadcom.
ciao.

 ---> perchè qualora fossero 15Mb/s --> 120Mbit effettivi
Non capisco che calcolo tu stia facendo...
Come arrivi da 15mbit a 120mbit?
Guarda che stai confondendo i miei dati.
Io parlo di megaBIT, quindi non devi moltiplicare per 8.
Sono megaBIT no megaBYTE, quindi 15mbit restano sempre 15mbit.
Se la scheda è 100mbit, dovrei poter arrivare (sulla carta) a 100mbit
o giù di li.
Che equivalgono a 12.5megaBYTE, ed infatti ci arrivo vicino,
mediamente trasferisco,
su altri server, a 10-11mbyte

 qualsiasi scheda di rete penso vada più che bene. anche la broadcom.
Ok, grazie per la info.
Ma non c'è modo di capire con certezza cosa è successo alla mia nic?
O ogni volta che capita così la soluzione è sostituire schede su
schede?
Vorrei sapere se è lo switch, in modo da farlo cambiare
preventivamente
e/o farmi configurare una porta differente, o se è il bus del server o
robe simili
in modo da chiamare l'assistenza prima che il problema si possa
ripresentare
di nuovo.

 di nuovo.
bhè, obiettivamente, se hai cambiato la nic ed ora il difetto (che prima 
entro 15 minuti si ripresentava) non fa più... semplice deduzione :)
calcola che i problemi di buffer sulle nic sono davvero abbastanza rari. 
molto più di frequente parte una porta (o un gruppo di porte adiacenti) 
sullo switch.
anzi, toglimi una curiosità, come te ne sei accorto? in log/messages ?

 su altri server, a 10-11mbyte
ti manca un pezzo.
ti ho chiesto "mi confermi che stiamo parlando di Mbit e non MBYTE?" 
"perchč qualora fossero stati 15MEGABYTE/SECONDO il traffico non č 
proprio basso"
poi mi hai confermato che parlavi di mbit, quindi ti ho scritto "allora 
il carico č leggero" sicuramente non tale da giustificare una crisi del 
buffer :)

 anzi, toglimi una curiosità, come te ne sei accorto? in log/messages ?
Ci han pensato i clienti a farmi notare il problema.
Vado a vedere i grafici e... sopresa, si è passati da 15mbit a 4-5mbit.
Vado a vedere sul server ed ho notato l'overrun che incrementava a
dismisura.


 buffer :)
megaBIT, bit bit, i cari vecchi bit :)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 perchè qualora fossero 15Mb/s sei molto vicino al troughput del gigabit
Eh?
l'OP ha parlato di 15 mbit al secondo, non di 15 megabyte al secondo...
(e anche con 15 megabyte al secondo, saresti ben lontano dal limite
teorico di una scheda gigabit...)

 teorico di una scheda gigabit...)
lasciamo stare il teorico.
Mbyte effettivi al secondo:
1000 to 1000 fiber to fiber senza apparati di mezzo, solo trasferimento: 
29Mb/s
1000 su switch di fascia alta: 24-26Mb/s
1000 attraversando uno switch di fascia entry level: 18-22Mb/s
15Mb/s sono molto simili a 18, il resto ed anche questo è stato già scritto.

 scritto.
Io con scheda di rete ad 1Gbit, trasferendo files via scp da una 
appliance con processore GEODE a 200Mhz e minidisco da 2500rpm, non vado 
più di 250Kb/sec.
Al contrario, su switch di qualsiasi razza ed estrazione, su server 
decenti, i 50Mb/S comodi comodi non me li leva nessuno.
Come vedi, lasciando stare il teorico, la pratica è molto variegata e se 
avessi i tuoi dati di performance, probabilmente avrei qualche 
preoccupazione sul buono stato della rete o dei servers.
scp xx...@172.16.1.1:iso/debian-502-amd64-netinst.iso .
 ....... 100%   131MB  58.6MB/s   00:02

  ....... 100%   131MB  58.6MB/s   00:02
Umh, e l'altro mezzo giga di chi è?
L'overhead non ti porterà mai via mezzo giga.
Tu stai trasferendo, su rete gigabit, visto che sei
a circa 500mbit, un file, ma gli altri 500 dove
sono finiti, nel tuo caso?
Potrei capire un 20% (che è comunque una esagerazione) di
perdita a causa dei protocolli, ma qui un 50% è andato a
donnine facili.
Chiedo giusto per curiosità.


   ....... 100%   131MB  58.6MB/s   00:02
guarda, è davvero tanto. i miei test li feci tra due server ibm di 
prestazioni ottime proprio per evitare colli di bottiglia derivati 
dall'hardware (entrambi xeon QC min. 2Ghz con scheda intel F.O.). la 
media si attestò a 26Mb/s ed il picco iniziale a 35 con una patch 
incrociata LC/LC 50/125 con SFP a 1000Mb ovviamente SX.
58 è davvero tanto. e comunque un trasferimento di 2 secondi non è 
attendibile, puoi provare a tenerlo 60 secondi? gli passi magari una 
distro in DVD. in genere si consiglia di effettuare i test minimo con 30 
secondi e tagliando il picco iniziale.

 Chiedo giusto per curiosità.
L'altro mezzo è:
1) in parte dedicato a scp, se avessi usato FTP sarebbe andato meglio...
2) in parte "puppato" dall'overhead del tcp
3) l'altra parte probabilmente la sta succhiando DRBD che gira su quella 
macchina e che quando lo sincronizzai, non andava a meno di 80MB/sec.
;-)

 secondi e tagliando il picco iniziale.
1Gb è sufficiente.
lamu:~# wget 
http://172.16.1.84/test.raw
--2010-04-07 15:59:43--  
http://172.16.1.84/test.raw
Connessione a 172.16.1.84:80...connesso.
HTTP richiesta inviata, in attesa di risposta... 200 OK
Lunghezza: 1000000000 (954M) [application/octet-stream]
Salvataggio in: "test.raw"
100%[8===[CUT]=========D] 1.000.000.000 66,6M/s   in 15s
2010-04-07 15:59:58 (65,3 MB/s) - "test.raw" salvato 
[1000000000/1000000000]


ovviamente non sei da una VM all'altra, no? perchè la velocità ci 
assomiglia taaaanto. :)
guarda, qui, su tomshardware (non proprio l'ultima arrivata) fanno una 
comparazione tra nas, tra cui HP MV2020 e similari. si tratta di NAS di 
fascia economica, però:
http://img.tomshardware.com/uk/2006/11/16/hp_mediavault_1g_perf_read.png
in lettura, tolto il picco iniziale, hanno beccato una media di 
16-17Mb/s in gigabit
http://img.tomshardware.com/uk/2006/11/16/hp_mediavault_1g_perf_write.png
in scrittura addirittura 11Mb/s.
Ora, ok, non sono test assoluti, ma trovo siano una media coerente con 
ciò che vedo normalmente.
magari mi sbaglio, quindi prendo i due HP che ho sottomano e faccio un test:
[mumble mumble... metti apache... bla bla...]
dal mio notebook al primo server ho trasferito a 9Mb/s, ma sono viziato 
dal traffico di rete, dall'attraversamento di alcuni nodi di attivi e da 
diverse cose che sto facendo in contemporanea, quindi prendilo come dato 
senza pretese.
server to server sono sui 24,5 Mb/s
di mezzo c'è un Allied Telesis AT-9400, mica proprio l'ultimo arrivato.
davvero sarebbe interessante capire in che condizioni ti sfornano 
66Mb/s, perchè sono molti e potrebbe essere utile riprodurli.
che hardware/nic hai?

> server to server sono sui 24,5 Mb/s
per completezza (online si trova molto su quanto l'hd sia un fattore 
limitante)
hdparm -tT /dev/sda
/dev/sda:
  Timing cached reads:   5572 MB in  2.00 seconds = 2788.28 MB/sec
  Timing buffered disk reads:  520 MB in  3.00 seconds = 173.10 MB/sec
è un raid hardware SATAII
l'altro server è SAS, quindi non penso crei problemi, magari ora 
approfondisco.

 macchina e che quando lo sincronizzai, non andava a meno di 80MB/sec.
Ecco, questo è molto più probabile.


 di mezzo c'è un Allied Telesis AT-9400, mica proprio l'ultimo arrivato.
Ecco, hai tirato fuori la parola magica.
Vola su icr.ip-admin e rispondi alla mia domanda, se ti va :)


 16-17Mb/s in gigabit
A questo proposito può essere utile rileggere un messaggio di due anni 
fa sempre su icol.sys:
http://groups.google.it/g/7e47fef8/t/4a31c0565fc3f8e/d/b835ca84f23335f2?hl=it


molto interessante, ora tocca capire qual'è davvero il fattore 
limitante. le nic? gli hd? gli attivi?
domani ispeziono per bene, mi sembra una discussione davvero molto utile.
ciao!

 che hardware/nic hai?
Ti assicuro che sono dati normalissimi per schede da 1Gbit.
Sono server Dell.
Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
Lo switch in questo caso è un 3Com economico. In altri casi è cisco ma il 
risultato è identico.
I dischi sono normalissimi sas da 7200, quindi nemmeno troppo veloci.
Suppongo che il trasferimento sia limitato a quei 60Mb/s proprio a causa 
dei dischi.
Nessuna ottimizzazione lato kernel o lato switch.
Forse che forse che Debian r0x e Suse Sux ?? :-D

> Forse che forse che Debian r0x e Suse Sux ?? :-D
lol

 Nessuna ottimizzazione lato kernel o lato switch.
Peraltro, se lo scopo del test è misurare la banda effettivamnte
disponibile sulla *rete*, eseguire uno spostamento file è un nonsense.
Così come cercare di mettere in piedi test empirici via
netcat+dd+/dev/zero et similia...
Ci sono oggetti fatti apposta, mica per niente:
# iperf -V -c 2a02:9a8:1::f:ff7f
------------------------------------------------------------
Client connecting to 2a02:9a8:1::f:ff7f, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 2a02:9a8:1:0:230:48ff:fe70:49c8 port 34159 connected with
2a02:9a8:1::f:ff7f port 5001
[  3]  0.0-10.0 sec    908 MBytes    761 Mbits/sec
Switch cisco 2960G...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 disponibile sulla *rete*, eseguire uno spostamento file è un nonsense.
Non c'è alcun dubbio che hai ragione.
Ma per mostrare che 20Mb/sec sono veramente pochi, basta un wget.
Max

 Switch cisco 2960G...
Per la gioia del Sasdelli, fai partire 24 test
(uno per porta) per vedere se l'apparato si siede :)


 (uno per porta) per vedere se l'apparato si siede :)
la features si chiama "no blocking", indica che il troughput è superiore 
alla somma di tutte le porte.

 alla somma di tutte le porte.
Schhhhhhh, non generiamo un flame :)
Non tutti concordano su quanto scritto nel datasheet e mi
piacerebbe avere un test esatto, come quello proposto da skull.
