Telegramma Ethernet - Tempi di risposta

[rob10kg]

Durante un corso fatto in Germania sulle reti Ethernet mi hanno spiegato che un telegramma Ethernet è una combinazione di 7 layers e ha una dimensione di 1500 byte.

A parte il tempo che ci vuole per elaborare da parte del sistema un telegramma così grande (i bus di campo hanno telegrammi molto più piccoli e semplici),la mia domanda é:

trasmettendo a 100 Mbs ora che tutto il telegramma è uscito bit per bit dal trasmettitore,ha attraversato la linea è è entrato completamente nel ricevitore di tempo ne passa o no?

Delucidatemi perfavore.

Ciao e grazie.

[batta]

1500 byte * 8 = 12000 bit. A 100 Mbps servono 0,12 ms.

[ifachsoftware]

Oltre ai tempi di trasmissione ed elaborazione vanno considerati i vari retry dovuti ad eventuale traffico di rete o errori di trasmissione , il che rende l'Ethernet NON DETERMINISTICA anche se si stanno realizzando protocolli che cercano di aggirare tale problema.

Ciao

[rob10kg]

Siete proprio bravi ragazzi altro che palle.

[Piero Azzoni]

non c'e' nulla da aggirare

se passi attraverso uno switch lui fa uno stere and forward, se passi attraverso due ne fanno due

l'idea buffa che le collisioni siano un difetto e' un grave errore visto che e' su questo meccanismo si basa il buon funzionamento di ethernet

la conclusione e' che il collegamento ethernet e' per sua natura estremamente veloce ma la sua indeterminatezza e' la sua garanzia di funzionamento

all'opposto hai reti di tipo deterministico

normalmente conosci il tempo di latenza, ma quando la rete non ci riesce succedono danni:

-perdi il segnale

-si blocca la rete

[rob10kg]

Ciao Piero.Non sono d'accordo su quello che hai detto.Le collisioni vanno evitate perchè sono perdite di dati quindi perdita di tempo.

Senti cosa dice "Bus di campo a confronto (è un libricino) " : in linea di principio ,i protocolli che prevedono componenti collegati sul bus di tipo peer to peer non sono in grado di evitare le collisioni.Per evitare la perdita di dati,tali casi devono essere quindi riconosciuti e risolti tramite specifici processi di risoluzione delle collisioni.Per lo più,la risoluzione delle collisioni viene implementata con l'introduzione di tempi di attesa statistici specifici dei singoli componenti collegati sul bus prima che abbia inizio il nuovo accesso al bus.Piero forse abbiamo ragione entrambe.La collisione la riconosci quando è già avvenuta,puoi solo evitare che ne avvenga un'altra.

[Piero Azzoni]

..... con l'introduzione di tempi di attesa statistici specifici dei singoli componenti .....

il principio base di ethernet e' proprio il contrario ed e' quello che permette la realizzazione di una rete di comunicazione [ethernet] nativamente multimaster

qualsiasi componente della rete puo' iniziare a trasmentere in qualsiasi momento, a condizione che non rilevi che vi sia gia' in atto una trasmissione

evidente che l'ipotesi che i progettisti di xerox era perfetta, rimaneva un solo aspetto da risolvere, l'ipotesi che due nodi iniziazzero la trasmissione con assoluta contemporaneita'

la soluzione (1964 !) valida ancora oggi fu quella di definire questa condizione "collisione"

< dicasi collisione la presenza contemporanea di due trasmissioni >

in questo caso il comportamente dei nodi e' il seguente:

- i nodi in trasmissione smetteno di trasmettere

- i nodi in ascolto non iniziano a trasmettere

- sia negli uni che negli altri si attiva un timer con un tempo random, passato questo tempo il singolo nodo e' di nuovo abilitato a trasmettere

- ovviamente i nodi che non hanno nulla da trasmettere non trasmettono

- i due (o piu') nodi entrati in collisione dovrebbero (vorrebbero) iniziare a trasmettere finito il conteggio del proprio timer, MA, il tempo di set e' random ed e' statisticamente altamente improbabile che due nodi, aventi entrambi l'intenzione di trasmettere, abbiano lo stesso tempo, ne deriva che il primo trasmette ed il secondo aspetta

cio' dimostra tre cose:

che le collisioni non hanno nulla di negativo, anzi sono il meccanismo piu' efficente che esista per gestire reti multimaster

molto piu' di quanto lo sia il token che ha strutturalmente il difetto di interessare sempre e comunque al pari livello i nodi con necassita' di comunicazione quanto quelli che "non hanno il quel momento nulla da dire

la prima che il ragionamento impostato su tempi statistici e' scorretto, anzi e' necessario che il tempo di attesa si molto basso e assolutamente random

terza e piu' importante !

la chiave di tutto e' solo una, la banda reale disponibile deve sempre e comunque essere superiore alle necessita', cio ' da' intrinseca garanzia che la comunicazione si realizzi in tempi anche migliori delle necessita'

la determinatezza del tempo e' un falso per qualsiasi rete in quanto l'unico modo di garantire detta determinatezza e' lavorare sempre e comunque al di sotto delle prestazioni reali

[Piero Azzoni]

affronto il problema da un'altro punto di vista

se dovessi progettare una rete deterministica con una banda da (per esempio) 5 Mb/sec. dovrei creare detta struttura su un supporto fisico con prestazioni decisamente piu' elevate

a questo punto comunque rischierei, in un momento ove la banda necessaria a muovere i miei dati sia piu' elevata del solito, un blocco della rete o una perdita dei dati

di contro in un momento nel quale il fabisogno reale e' modesto non ne avrei alcun giovamento

al contrario se mi appoggio ad un rete non deterministica (questo discorso e' valido per ethernet, ma tale quale si verifica con bus basati sul can-bus) avendo cura di verificare in sede di progettazione che la banda disponibile sia sempre superiore a quella richiesta

comunque in un momento di particolare necessita' di banda sarei comunque meglio del limite prestazionale minimo richiesto

quando il fabisogno di banda non e' piu' al massimo la prestazione gia' e' nettamente migliore delle necessita'

[rob10kg]

Piero ho riletto attentamente tutto quello che hai scritto,figata,che dire figata.Grazie.