Newsgroup: it.comp.os.linux.sys
Titolo: Linux e prestazioni a 100Mbit

Ho un bel cellerone a 300 con una scheda tulip a 100Mbit con installata
una Debian 2.1. 
Funziona tutto, ma se provo a fare FTP (sia con ftpd o proftp) i
trasferimenti vanno in crescendo, partendo da qualche kbit di transfer
per raggiungere dopo qualche minuto la banda piena. 
La stessa cosa mi succede anche con Netatalk.
Cosa può essere? 
-- 
Byz
---
Pavanel Massimo
ICQ# 63077580

Cosa può essere? 
TCP funziona cosi`.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 TCP funziona cosi`.
Qualche minuto mi pare tantino pero`...
-- 
  /Kinkie
Se sulla scatola c'e` scritto "Per windows 95 e superiori", dovrebbe
funzionare sotto Linux, vero?

Cosa può essere? 
I parametri di window size del TCP, credo. Non so se si possano
modificare con "make menuconfig" (mi pare di ricordare qualcosa
del genere).
Leonardo
".signature": bad command or file name

Qualche minuto mi pare tantino pero`...
Anche 100Mbps e` tanto. Non ho sottomano le formule, ma dovrebbe bastare
prendere TCP/IP illustrated e fare i conti.


 prendere TCP/IP illustrated e fare i conti.
Io ho una 100Mbps in casa, e anche tenendo conto del fatto che le schede di
rete sono scarsine (una e` una PCCARD, con un throughput massimo TCP di
circa 20 Mbit/s), il tempo richiesto per arrivare alla saturazione della
banda disponibile e` al massimo di un paio di secondi (due linux/2.2.14
senza ottimizzazioni particolari).


 writes:

No, sono "accordabili" con i file in /proc/sys/net/ipv4


 bastare prendere TCP/IP illustrated e fare i conti.
IMHO, qualche minuto e' troppo. Probabilmente ci sono collisioni e/o
"perdite" e la finestra non cresce esponenzialmente ma linearmente.
-- 
                                                                     __
 __                                                              _  ///
| _        Student in Computer Science, Swiss Federal Institute  \\///
|__|iambo      of Technology - mailto:
ggia...@iiic.ethz.ch
       \X/

 "perdite" e la finestra non cresce esponenzialmente ma linearmente.
Con ifconfig non rilievo collisioni con FTP (cosa che invece con
Netatalk siamo sul 5-8%). Potrebbe essere interessante la finestra del
TCP, potete spegarmi un po' meglio?


 po' meglio?
E' passato un po' di tempo, ma ci provo lo stesso (Se qualcuno vuole
divertirsi a correggermi e darmi dell'ignorantone, benvenga :-)).
E' un metodo per evitare congestioni: TCP comincia con spedire nK di
dati, se questi arrivano senza  problemi, la prossima volta spedira'
2*nK, se anche questi vengono  confermati da ricevente, provera' con
2*(2*nK),  e cosi'  via finche'  o  c'e' un  problema (timeout,  per
esempio)  o  finche' viene  raggiunta  la  dimensione massima  della
finestra (= quantita'  massima di bytes spedibile in  un colpo solo:
64K, giusto ?).
Ora,  siccome  ogni  volta  la  quantita'  di  bytes  spediti  viene
radoppiata, teoricamente la finestra viene riempita in fretta.
C'e' un  pero'. In caso  di problemi, TCP  setta un limite  (Mi pare
venisse  chiamato Threshold)  pari alla  meta' del  numero di  bytes
spediti al momento  del problema e ricomincia a  spedire pochi bytes
per  volta,  radoppiando  ogni  volta la  quantita'  (Come  spiegato
sopra).  TCP smette  di radoppiare  il  numero di  bytes spediti  al
momento nel quale raggiunge  il Treshold settato precedentemente: Da
questo momento in avanti aumetera' linearmente il numero.
Esempio: Spedisce 1K,  poi 2K, 4K, 8K, 16K, 32K  e in questo momento
c'e'  un problema:  Il  Threshold  viene settato  a  32/2=16K e  TCP
ricomincia  spedendo 1K,  poi 2K,  4K, 8K,  16K e  da qui  in avanti
aumentera' linearmente: 17K, 18K, 19K,  ... finche' incappa di nuovo
in un timeout, ...
Nel tuo caso (Niente collisioni),  non riesco a capire dove potrebbe
essere il problema  ... Anche perche', per riempire  una finestra da
64K (Anche linearmente) parlare di _minuti_ e' eccessivo ...
IMHO, il  problema sta' altrove: Quanti  MB di RAM hai  ? Che Kernel
usi ?


 TCP, potete spegarmi un po' meglio?
Piccola lezione di Reti di Telecomunicazioni:
I protocolli con trasmissione garantita (come TCP) funzionano in modo
riscontrato: in linea di principio, ogni pacchetto inviato dal trasmittente
viene riscontrato dal ricevente (non ricordo se TCP permette anche di
effettuare meno ACK). Secondo lo schema piu` semplice, il trasmittente
attende di ricevere questo riscontro prima di inviare il prossimo
pacchetto, in questo modo se il pacchetto viene perduto deve reinviare solo
quello. Questo e` ovviamente molto poco performante, specialmente se la
latenza (ovvero il tempo che un pacchetto impiega a arrivare a
destinazione) e` alta. Per questa ragione tutti i protocolli permettono al
trasmettitore di inviare ulteriori pacchetti anche prima di avere ricevuto
il riscontro. La "finestra" spiega quanti pacchetti (o byte, a seconda dei
casi) e` possibile trasmettere prima di aver ricevuto un riscontro
positivo. Questo permette di sfruttare tutta la banda disponibile, e
controllando l'"apertura della finestra" (il numero di pacchetti non
riscontrati che e` possibile spedire) si effettua anche il controllo della
congestione in rete: se la rete e` congestionata, perde pacchetti, e allora
e` in inutile spedirli. Quando questo succede, viene "chiusa" la finestra
calando il ritmo di trasmissione.
Il discorso e` ovviamente piu` complesso, ma queste ne sono le linee guida.


No, sono "accordabili" con i file in /proc/sys/net/ipv4
Ahh, mi pareva bene :-)
(Subito dopo aver inviato il messaggio mi sono detto: see, sta' a vedere
che ora per modificare i parametri di TCP bisogna _riavviare_ :-))) ).
