Newsgroup: it.comp.reti.locali
Titolo: mistero inspiegabile di throughput

Ciao  a tutti,
avrei un enigma da sottoporvi che non ha nulla da invidiare a quelli della
settimana enigmistica.
PREMESSA:
Ci sono due computer collegati in rete fra di loro. Uno è un desktop ed un
altro è un notebook. I due computer sono collegati mediante cavo cross, ed
il collegamento fisico che si stabilisce è a 100 Mbps. La lunghezza del cavo
è di circa 5 metri. Il problema riguarda il trasferimento di file da una
parte all'altra.
FATTO 1:
Se trasferisco un file dal computer desktop al notebook, manovrando il
notebook, il transfer rate è di circa 3 Megabyte/s, ben al di sotto dei 12,5
MB/s previsti.
Gli hard disk non dovrebbero rappresentare un collo di bottiglia, in quanto
da benchmark il notebook risulta capace di 20 MB/s (è un 4200 rpm) mentre il
desktop di circa il doppio (è un 7200 rpm). Inoltre a conferma di ciò,
durante l'operazione le luci dell'hd non sono costantemente accese.
FATTO 2:
Se trasferisco un file dal notebook al desktop, manovrando il desktop, il
transfer rate sale a circa 6 MB/s.
FATTO 3:
Se trasferisco un file dal desktop al notebook, manovrando il desktop, il
transfer rate è di circa 6 MB/s.
Domande:
1) Come mai in tutti i casi il transfer rate è al di sotto dei 12,5 teorici
?
2) Perchè quando trasferisco un file da desktop a notebook il transfer rate
cambia da 3 a 6 MB/s semplicemente a seconda della postazione da cui do
l'ordine ?
3) Perchè quando do l'ordine dal notebook ottengo soltanto 3 MB/s ?
Ringrazio tutti in anticipo. Chi riesce a scovare il problema avrà il suo
nome pubblicato sul newsgroup :)

 l'ordine ?
immagino perchè i protocolli fanno un loro traffico per il controllo del 
file transfer che va a utilizzare porzioni consistenti di banda sulla 
rete....e che tu non conteggi nel tuo calcolo :))) 

 rete....e che tu non conteggi nel tuo calcolo :)))
Ciao
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:32bf2uF...@individual.net...


10 MB/s è già un buon valore, ma 6 è il 50% del valore teorico...


 tua spiegazione...
la realtà stessa ti smentisce....tant'e'; vedi il post che precede che 
riporta appunto, su un tranfer moooolto grande dove il traffico di controllo 
diventa trascurabile si arriva appunto a 10.... al secondo punto mi 
riferisco al controllo che la cpu/protocollo deve effettuare sul file 
transfer...immagino che abbiano bisogno di banda anche loro, tu che dici?? 

 Con 100 Megabit/s credo si intendano dati utente
credi male
è il dato teorico della 100basetx
conta ogni bit che passa
P.S. x Millo non c'e' "parità", start/stop... mica è seriale 

 P.S. x Millo non c'e' "parità", start/stop... mica è seriale 
Infatti:
1) Primo: stiamo lavorando in full duplex o half duplex?
2) E le eventuali collisioni non le contiamo?
3) Il frame mi pare abbia lunghezza massima di 1526 bytes, di cui
    ne perdiamo sicuramente 26
4) Se si lavora col protocollo tcp/ip, perdiamo mi pare almeno
40 byte di intestazione.
5) Nel payload del pacchetto ip, perdiamo altri byte in
    intestazione del protocollo di trasporto tcp-udp (o icmp)
Se trasferiamo files con rete microsoft, usiamo netbios over
tcp/ip, e smb over netbios... Immagino perdiamo altri bytes in
intestazioni varie.
Contiamo poi che col tcp vengono spediti in piu' i pacchetti
di riscontro della stream, che pur non sempre spediti come
pacchetti separati (anzi), tolgono comunque altri bytes. In
ogni caso c'e' anche un "flusso di ritorno", mica c'e' solo
una stream monodirezionale "sparata" da un pc all'altro...
Senza contare gli eventuali icmp in mezzo...
Contiamo poi, pur con pc veloci, il carico del sistema fra
tcp/ip, netbios su tcp/ip, e smb over tcp, e, perche' no,
disco rigido (pur se veloce).
C'e' un bel po' di roba in mezzo, mi sembra...
Morale: non possiamo pretendere 12,5 megabyte, perche' non stiamo
evidentemente usando solo e direttamente il primo layer della pila
iso/osi (al quale banalmente basterebbe il driver della scheda di
rete...). I miei calcoli non saranno certo esatti (anzi, non sono
neanche calcoli), ma dico: almeno facciamo bene i "calcoli delle
varie implicazioni pratiche", quando facciamo prove cosi' empiriche...
bye G.L.

 varie implicazioni pratiche", quando facciamo prove cosi' empiriche...
Okay, però mi rimane un dubbio. Com'è possibile ottenere transfer rate di 3
MB/s ? E' un valore molto basso. E come mai nel verso opposto ottengo 6
MB/s? E,
cosa ancora PIU strana, come mai a parità del verso in cui vengono
trasferiti i dati (dal desktop al pc ad esempio) il transfer rate
addirittura raddoppia a seconda di dove do il comando ??

 addirittura raddoppia a seconda di dove do il comando ??
Il problema indubbiamente c'e': ma tieni presente che con ftp ottieni
un transfer rate al piu' dell'83-85% (8,5 mb/s su 100mbps) rispetto a
tutta la banda "raw" dell'ethernet. E sono i risultati migliori che
puoi ottenere in assoluto (a meno che non siano uscite novita').
Forse giusto il netbeui ti puo' dare prestazioni simili (ma solo fra
pochi pc, perche' fa tutto in broadcasting).
Comunque mi rifarei alla technet microsoft. Ci sono diversi articoli
riguardanti lo scarso troughput in rete, e molti mirati proprio alle
prestazioni della rete microsoft smb.
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 P.S.: Penso intendessi "8.5 MBps su 100 Mbps" giusto?
No, quelli su una 10mbit: circa >800*K*byte al secondo.
bye G.L:


 e mi sembrano valori corretti, sempre negli 80%/85%.
Giusto, giusto. Dimenticavo che "B" maiuscolo e' byte, "b" minuscolo
e' bit.
bye G.L.


faccio sapere ;o)
Attendiamo i risultati ;-)
L'interpretazione però su quel taglio di banda diventa difficoltosa
perché si rischiano altri colli di bottiglia (ad es. i dischi).
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 dectnet, apple talk, nfs su udp, nfs su tcp, etc.?
OK,  loro non sanno cosa usi sopra, ma potrebbero  fare riferimento al solo
livello 2,
intendendo cioè che i 100 Mbit/s sono calcolati sui dati utente del
pacchetto ethernet. Ma non credo sia questo il caso

 un transfer rate al piu' dell'83-85% (8,5 mb/s su 100mbps) rispetto a
No:
http://www.google.it/groups?hl=it&lr=&frame=right&th=e5bcc00212aca8ef&seekm=3A6BF1B2.53540360%40cometweb.it#link5
-- 
Vincenzo

 teorici ?
<snip>
Sorvolando su tutta la discussione, il test che hai fatto
coinvolge troppe variabili (dischi ecc..) direi di iniziare
valutando l'effettiva velocità della tratta di rete, per fare
questo potresti utilizzare ad esempio NetPerf
http://www.netperf.org/netperf/NetperfPage.html
a questo punto effettuando più tests con NetPerf (in modo
da avere un campione "decente") e scambiando di ruolo
(netperf client/server) le macchine dovresti ottenere un
dato che si avvicinerà di molto all'effettivo throughput
Posta i dati di cui sopra e poi ... ne riparliamo :-)
Ciao

 della settimana enigmistica.
<cut all>
Guarda, il mistero si infittisce: ho fatto delle prove più accurate, e
ho scoperto (per quanto riguarda la mia rete le cui caratteristiche sono
nel mio post "Rete locale: problemi velocità") che:
1) se ordino il trasf. dei file dal portatile con WinXP (sia che
trasferisca i dati verso il portatile stesso, sia verso il PC) raggiungo
al massimo i 4 MB/s - quando va proprio bene.
2) se invece ordino il trasf. operando sul PC Win98, raggiungo anzi
supero gli 8 MB/s sia da PC a portatile sia nel senso inverso.
In pratica quello che determina la velocità di trasf. è il computer dal
quale impartisco il trasferimento.
Meditate, gente, meditate ...
-- 
Zibibbo
Togli BaStAsPaM per rispondere.

 
http://www.google.it/groups?hl=it&lr=&frame=right&th=e5bcc00212aca8ef&seekm=3A6BF1B2.53540360%40cometweb.it#link5
 
Sono d'accordo, a livello teorico, sull'overhead: io intendevo dal lato
pratico il transfer rate che ti ritrovi nella statistica di un ftp di un
grosso file alla fine del trasferimento. Ancora non ho visto valori al
di sopra di 8,7 o giu' di li'. Considera' pero' che a influenzare il
rsultato pratico sono molti altri fattori, IMHO non basta certo solo
sottrarre bytes.
Per il resto, devo dire la verita', non mi son mai messo a controllare
che le schede fossero settate in full duplex, magari e' possibile che
ottenga valori piu' vicini a quelli ideali da te riportati, ma ho i miei
dubbi.


 pacchetto ethernet. Ma non credo sia questo il caso
Ecco, a questo punto non lo so neanch'io. Ma io penso che i 100mbps
si riferiscano al frame intero, perche' un frame ethernet non contiene
sempre il massimo (1500 byte) dei dati, ma puo' contenere anche poche
decine di byte, e li l'overhead e' piuttosto altino. Quindi dubito che
possano riferirsi al livello 2, dato che al livello superiore ognuno
almeno ipoteticamente, puo' gestirsi la mtu nel modo che piu' gli
aggrada.


Bravo, è proprio quello che ho scoperto pure io, ed è uno dei punti a cui
non so ancora dare una risposta.
Comunque ti consiglio di controllare il carico della cpu, ho notato che la
differenza di carico è sensibile, a seconda di dove dai l'ordine.
E nel mio caso le cpu non sono poi troppo diverse...
"zibibbo" <cmpie...@BaStAsPaMvirgilio.it> ha scritto nel messaggio
news:chGwd.531844$35.22...@news4.tin.it...



Sì è vero mi ero un po' confuso leggendo il tuo post.
Ho controllato il carico, e quando la velocità è elevata (comandi
impartiti dal desktop Win98) il carico è simile per entrambe le CPU, e
si attesta sul 34/35 %. Quando impartisco il trasf. dal portatile WinXP
(bassa velocità di trasf.) il carico è molto basso per quest'ultimo,
circa il 17 %, ma si eleva al di sopra del 55 % per il desktop, il quale
subisce oltretutto il completo sequestro dei 256 MB di RAM di cui
dispone, che poi non vengono più rilasciati.
Per la cronaca, il desktop è un Celeron  1,1 GHz, il portatile un P4
Mobile 1,7 GHz con 256 MB RAM.


quale impartisco il trasferimento.
Sotto XP Pro per farti vedere che nonostante grossi volumi di dati
scambiati le macchine XP in rete si parlano ancora velocemente viene
riservata una certa porzione di banda per le comunicazioni di
servizio. Ovviamente sotto 98 questa cosa non c'è.
Puoi provare a disabilitare questa cosa con il metodo qua sotto:
---------------------------------
SpeedUp Your Connection By 20% (Cable Users Only) 
1.Log on as "Administrator". 
2. Run - gpedit.msc 
3. Expand the "Local Computer Policy" branch. 
4. Then expand the "Administrative Templates" branch. 
5. Expand the "Network" branch. 
6. Highlight the "QoS Packet Scheduler" in left pane. 
7. In the right window pane double-click the "Limit Reservable
Bandwidth" setting. 
8. On the settings tab check the "Enabled" item. 
9. Change "Bandwidth limit %" to read 0. 
10. Then go to your Network connections Start=>Control Panel>Network &
Internet connections>Network Connections and right-click on your
connection. Then under the General or the Networking tab, (where it
lists your protocols) make sure QoS packet scheduler is enabled. 
It may take effect immediately on some systems. To be sure, just
re-boot. 
---------------------------------------
Prova e facci sapere come è andata.
Ciao
				Cristian

 Prova e facci sapere come è andata.
Uhmmm, preciso che sono di un'ignoranza abissale su questi argomenti, ma
ad occhio e croce mi sembra che la procedura equivalga a disabilitare
del tutto l'utilità  di pianificaz. QoS, cosa che avevo già provveduto a
fare da tempo. Ad ogni modo ho seguito passo passo la procedura da te
gentilmente
riportata ma, ahimè, non ci sono state differenze.
Grazie lo stesso.
