Newsgroup: it.comp.reti.locali
Titolo: Collision

Come mai quando trasferisco i file tra i due PC che ho a casa connessi ad un
hub 10 Mbit/s insieme ad un alcatel speed touch home, mi si accende sempre
il led della collision??

 ha scritto nel messaggio
news:KyMt6.59957$yl2.2...@news1.tin.it...

collegamento HW schifoso?

 ha scritto nel messaggio
news:99865a$5l8n$2...@ID-65620.news.dfncis.de...


 ha scritto nel messaggio
news:99865a$5l8n$2...@ID-65620.news.dfncis.de...



E` assolutamente normale.
-- 
Vincenzo 
Si puo' scrivere una breve lettera alla nonna nel nome del file.

 ha scritto nel messaggio
news:3AB87779...@cometweb.it...


 E perchč č normale??
Perche` sull'hub hai sempre un collegamento half/duplex e anche con
due pc si sono sempre due schede che tentano di trasmettere. Quindi
per definizione, nel protocollo CSMA/CD e` normale avere collisioni.


 > E perchè è normale??


 E quindi non ci sono pacchetti persi?
No, e tutto ok.


 due pc si sono sempre due schede che tentano di trasmettere.
stai dicendo che la sk in ricezione tenta pure di trasmettere?
xche di grazia?

 xche di grazia?
No, sto dicendo che di solito non si puo` instaurare una 
comunicazione nella quale i protocolli di livello 4 e 
superiori delle due macchine siano sincronizzati e aspettino 
che il mittente abbia finito di trasmettere per poter 
trasmettere a loro volta.
Tipico esempio: Protocollo tcp/ip, due host 
- tx che invia prevalentemente
- rx che riceve prevalentemente 
E` la tipica situazione di trasferimento file con protocollo 
smb over tcp/ip da tx a rx.
Per *ogni* pacchetto trasmesso (tx->rx) c'e` un pacchetto di 
ack (rx->tx). I processi sulla macchina tx e rx sono 
assolutamente asincroni.
In pratica tutte e due le macchine saranno sempre sia riceventi
che trasmittenti (anche se la macchina tx avra` una richiesta molto
maggiore della macchina rx di occupare il canale per trasmettere) 
e questo porta a collisioni anche con due soli PC.


 assolutamente asincroni.
hai dimenticato il "cs" di CSMA/CD ;)
non contesto la logica, solo che prima di trasmettere si ascolta per vedere
se qualcuno lo sta gia' facendo ed evitare cosi' la collisione.
Quindi la collissione c'e' solo se il segnale elettrico e' ancora sul cavo
fisicamente.
L'assunto prevede solo due PC coinvolti in hduplex e la vedo piuttosto
difficile no?
perche' PC2 deve trasmettere l'ack _prima_ di aver ricevuto tutta la
finestra?
E se invece ha completato la ricezione, deve essere ben veloce (vicino) per
anticipare lo stato di quiete del supporto, no?

 finestra?
Dipende dalla dimensione della finestra, dai timer per i delayed ack
(che vengono di solito impostati su 200ms ma la durata effettiva
varia in funzione dell'arrivo del pacchetto), dalla velocita` del 
canale ed anche dal funzionamento del procotollo che sta sopra tcp/ip.
Quando scade un timer per il delayed ack, l'ack viene trasmesso e basta
anche se la finestra di input annunciata non e` piena.


 a trasmettere nello stesso istante.
Assolutamente vero, infatti c'e' il "cd" del nome ;)
il punto e' due SOLI PC con un trasfer file danno (e quante) collisioni?
Questo era il thread. Io dico pochissime forse zero, il resto NON e'
normale!
Un buon cablaggio, con due sk decenti e due SO che non si stiano scaccolando
nel frattempo, si limitera' a sparare pacchetti da A a B con qualche ack in
mezzo.

 collisioni?
Credo che il problema stia tutto nella velocita` dei pc e
nella (relativa) lentezza del canale. Comunque io non
voglio (e non posso) entrare nel merito del numero di
collisioni (richiederebbe un calcolo complicato).
Volevo solo dire che e` normale avere collisioni
anche con due soli PC.
-- 


, 
free...@libero.it
 
says...

Ciao,
ho potuto sperimentare personalmente una situazione simile a quella 
descritta qui sopra (2 pc su una rete ethernet a 10 Mbit realizzata con 
hub) e ti confermo che le collisioni ci sono numerose! il cablaggio credo 
sia buono perche' le velocità di trasferimento sono buone (circa 950 kb/s 
in ftp e poco meno via smb). Il nocciolo della questione secondo me sta 
nella velocità di trasmissione delle applicazioni : in una situazione di 
trasferimento file ci sarà una macchina A che trasmette dati e una 
macchina B che riceve e trasmette quasi solo esclusivamente gli ack di 
tcp. Supponiamo inoltre che la macchina A sia abbastanza veloce da avere 
in ogni istante un pacchetto pronto da inviare. La trasmissione comincia 
alla massima velocità possibile ossia i pacchetti si susseguono con 
intervallo minimo possibile (mi pare 96 bit  o qualcosa di simile...) Ad 
un certo punto la macchina B dovrà inviare un ack , la scheda di rete 
farà il suo bravo lavoro e aspettera che il pacchetto che attualmente sta 
passando sia terminato , aaspetterà i 96 bit dopo di che inizierà a 
trasmettere e inevitabilmente ci sarà una collisione perche' sicuramente 
la macchina A avrà inviato un'altro pacchetto. A questo punto le due 
macchine aspetteranno un tempo casuale (algoritmo di back-off 
esponenziale) dopo di che tenteranno di ritrasmettere probabilmente in 
istanti diversi...e così via....
Se i pacchetti da A verso B sono tutti di dimensione massima gli ack non 
sarano affatto rari anzi saranno all'incirca uno ogni 3 o 4 pacchetti.
Questa è la mia opinione , suffragata da una esperienza sul campo molto 
simile a quella descritta nel post iniziale...che ne pensate ?
Marco

 simile a quella descritta nel post iniziale...che ne pensate ?
Tutto esatto.


 la macchina A avrà inviato un'altro pacchetto.
la macchina A non sta aspettando l'ack?

da quanto dite ....deduco che
le collisioni a 100 mbit sono in percentuale senza dubbio superiori di
quelle a 10 mbit ,
e che in certe  condizioni di utilizzo ......... usando degli hub
la differenza tra 10 e 100 mbit non è poi molta
nelle poche installazioni che ho fatto .....comparandole
il dubbio mi era venuto  ........
mi date conferma ?
:c()

 la differenza tra 10 e 100 mbit non è poi molta
No, 100Mbit sono sempre meglio di 10. Il problema e` che
spesso i client vecchi non riescono a star dietro 100Mbit/s
e quindi potresti notare poca differenza.
