Newsgroup: it.comp.reti.locali
Titolo: HUB e collegamenti in cascata

Ciao a tutto il newsgroup!!!!
Per pietà (sono messo in ginocchio sui ceci), datemi una dritta!
Ho la necessità di collegare due pc con Windows 2000 ad un unica presa di
rete proveniente da un hub. Dopo una ricerca su cosa offre il mercato,
l'unica soluzione mi è sembrata quella di collegare le due stazioni ad un
piccolo hub (4 porte) e quest'ultimo alla presa di rete esistente.
Essendo di "primo pelo" in materia di reti, ho pensato che quì potevo
trovare una "anima pia" che mi potesse dare un consiglio per questo
problema.
Ringrazio anticipatamente tutti, anche chi leggerà solamente questo
messaggio :-).

 piccolo hub (4 porte) e quest'ultimo alla presa di rete esistente.
qual e' la domanda?
[procedi! ;)]

piccolo hub (4 porte) e quest'ultimo alla presa di rete esistente.
prova a collegare l'hub alla presa con un cavo incrociato, sempreche'
l'hub stesso non abbia una porta "invertibile".
--
ciao dal Tinto (aka Alessandro)
www.tinto.org

Ciao a tutto il newsgroup!!!!

se la domanda e'  ho un secondo hub ma non riesco a collegarlo al
primo allora ti posso dire che in genere gli hub hanno o una porta a
parte adibita al collegamento in cascata ad un altro hub che se
utilizzata impedisce il funzionamento di una delle porte normali (in
genere l'ultima) oppure una porta che puo' essere utilizzata come
porta normale o come porta per collegare un altro hub tramite un
tasto. 
Ricapitolando:
hai il nuovo hub a 4 porte, colleghi i due pc, colleghi un cavo ad una
porta normale del nuovo hub e l'altro capo del cavo va inserito in
quella famosa porta per la connessione a cascata
spero di esserti stato d'aiuto
ciao
Gianluca

 >Ringrazio anticipatamente tutti, anche chi leggerŕ solamente questo


 ha scritto nel messaggio
news:9blbss$aqk$1...@nreadA.inwind.it...


 da 16... :-) peccato che la rete esistente è composta da un pc ogni piano
e
non ne vedo. hub economico per ogni porta da "raddoppiare". un 3Com
officeconnect costa ormai pochissimo!

 > da 16... :-) peccato che la rete esistente è composta da un pc ogni
piano


 (4) è vero?
Che io sappia si, e' il numero massimo di 'ripetitori di segnale' che si
possono collegare contemporaneamente. Oltre questo numero il segnale
subisce troppo ritardo in trasmissione e saltano fuori un mucchio di
errori durante il checksum
-- 
Mr. Fix at work

 ha scritto nel messaggio
news:1et4w4s.rpmww619u1mcoN%fixth...@yahoo.com...


 riguarda la PRONFONDITA' dell'albero, non la sua LARGHEZZA, è corretto?
Premessa: non sono un tecnico delle reti.  : )
Sto studiando per approfondire l'argomento ma non sono un guru, anzi,
soprattutto dal punto di vista teorico.
Detto questo, che io sappia su una rete ethernet classica non si possono
mettere piu' di 4 'ripetitori di segnale' (e l'hub e' considerato un
ripetitore di segnale) in quanto oltre questo limite il segnale acquista
un ritardo troppo elevato e ci sono problemi in fase di verifica dei
pacchetti che viaggiano sulla rete.
Gli hub sono comunque messi in cascata (tramite la porta 'uplink', che
e' una sola per ogni hub) quindi non puoi collegare piu' hub in cascata
ad un qualsiasi hub (a meno di usare dei cavi incrociati ma questa e'
un'altra storia).
Credo che il limite dei 4 hub si possa superare utilizzando dei 'bridge'
che separino 'segmenti di rete" (tipo un ufficio con 2 piani e relative
reti eth uniti insieme da un bridge) ma non ci metterei la mano sul
fuoco.


 ha scritto nel messaggio
news:1et6t5l.16xx3j968l014N%


 cascata) uno switch farebbe cambiare qualcosa?
In questo caso specifico secondo me non cambierebbe granche'...
-- 
Mr. Fix at home

 niente di simile e, a logica, mi pare impossibile che possa funzionare.
Scusa Mr Fix, se sei arrivato a questa conclusione con un minimo di
fondamento, dimmelo SUBITO perchè non vorrei comprare 1.000.000 di lire di
hub e poi non poterli installare.... tutti non riuscirei a farli entrare!!!
:-) (chi ha orecchie per intendere, intenda)
MAD

 hub e poi non poterli installare...
Dunque... Sul manualetto dell'hub 10/100 che ho qui c'e' scritto:
"Se colleghi un hub da 10Mbps il massimo numero di hub che possono
essere collegati in cascata e' 4 (con un massimo di 100 metri tra un hub
e un altro). Invece connettendosi ad un altro hub a 100Mbps il numero di
hub collegati in cascata e' limitato a 2"
Inoltre sul libro che sto studiando si dice che il numero massimo di
ripetitori (e l'hub viene considerato un ripetitore di segnale) da
installarsi in rete e' 4. Oltre questo limite il segnale "ritarda
troppo" e le collisioni aumentano (e le prestazioni della rete scendono)
Ecco il perche' delle mie perplessita'. 
Magari la rete funziona anche con 10 hub collegati in qualsiasi modo
pero' credo che le prestazioni scadrebbero a livelli disastrosi...
Di piu' nin zo...  : )


 Di piu' nin zo...  : )
Innanzitutto ti ringrazio per l'interessamento.
Riguardo quello che dici e in particolar modo quello che c'è scritto sul
manualetto dell'hub e quello che c'è scritto sul libro che stai studiando,
le informazioni coincidono. Quindi sin quì tutto ok! Il fatto è che devo
collegare 6 hub in cascata ad un'altro hub, ma non uno "dietro l'altro", ma
uno per ogni porta, e cioè non ci saranno più di due hub collegati in
cascata o "serie", ma 6 hub collegati in parallelo (vedi miei post
precedenti).
Ti schiedo una cortesia... potresti controllare sul libro che stai studiando
la fattibilità del mio progetto?
Grazie anticipatamente
MAD

 la fattibilità del mio progetto?
Uhm... Ho dato un'occhiata ma purtroppo il libro tratta l'argomento in
modo generico e non entra nello specifico. Sto cercando anch'io delle
informazioni un po' piu' precise sull'argomento. Se trovo qualcosa in
rete te lo posto.


Scusate il quote orribile (non c'e' ;)) ma mi era sfuggito il msg durante la
"migrazione" di client.
La domanda e' subdola e ci ho pensato un po'... secondo me il problema e'
falso. La regola 5-4-3 della 10BaseT e' una facilitazione draconiana per
definire a naso la lunghezza massima.
==> IMHO
Nella realta' io intanto non vedo *nessuna* preclusione a usare un numero
qualunque di hub!
L'unico parametro che io conosca vincolante in una rete Ethernet e'  la
condizione che permette al meccanismo di individuazione delle collisioni di
funzionare correttamente, e cioe' che il ritardo di propagazione su un
percorso andata-ritorno non deve superare i 512 tempi-bit (per una 10Mbit
vuol dire 51,2 microsecondi). Per la tua rete, devi quindi prendere in
considerazione i due punti piu' distanti tra loro e calcolare il PDV (path
delay value) in tempi-bit (bit times o bt). Se non supera 512 puoi attuare
il progetto dal punto di vista della regolare gestione del traffico.
In pratica:
PDV = ritardi dei collegamenti + ritardi dei ripetitori (hub) + ritardi
delle NIC dei Pc + margine di sicurezza.
Ritardi dei collegamenti: 2 volte (andata e ritorno) la lunghezza del
segmento (cavo tra host e hub e tra hub e hub) moltiplicato per il parametro
di ritardo del cavo (fornito dal costruttore, ad es.: CAT 5 = 1,112 bt/m ).
Ritardi dei ripetitori: questi sono fortemente dipendenti dai costruttori e
dai modelli.
Ritardi delle schede di rete (NIC) dei PC: come sopra ma in media si
aggirano sui 100 bt.
Margine di sicurezza: 5-10 bt
Potrei dire buon calcolo, ma nella rete di cui parliamo a 2 livelli mi
sembra che senza calcolare nulla saremo nella realta' sempre ben al di sotto
dei 200m (max due spezzoni), di conseguenza confermo la mia idea originale.
Se non funziona non te la prendere con me ;)))))
-- 
Posted from 
htt06-acc.tin.it
 [212.216.176.133] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 percorso andata-ritorno non deve superare i 512 tempi-bit 
Perdi di vista l'altro 'caposaldo' dello standard 802.3 che si 
chiama 'inter-packet gap'. Cioe` l'intervallo minimo tra due frame 
consecutivi che deve essere superiore a 9.6 microsecondi. Facendo 
passare il frame attraverso un repeater il gap si riduce. Questo
e` il motivo del '4' nella regola 5-4-3.
-- 
Vincenzo 
Non esistono verita'. Esistono solo versioni.

 Potrei dire buon calcolo, di conseguenza confermo la mia idea originale.
Grazie IH870! Sei stato molto preciso (forse un po troppo per le mie
conoscenze! ;-)).
Quindi non vedi nessun problema nel mio rpogetto, neanche quello che gli hub
di secondo livello andranno collegati alle normali porte dell'hub di primo
livello e non in quella di uplink...
Ok, realizzerò il mio progetto!!
Tranquillo che non me la prenderò con te, anzi ti ringrazio ugualmente in
anticipo.
Saluti a tutti,
MAD

 passare il frame attraverso un repeater il gap si riduce.
scusa, non ho capito. Ok il gap... ma non ti seguo sul perche' sia coinvolto
ne' sulla riduzione.

 ne' sulla riduzione.
http://sunsite.net.edu.cn/tutorials/urnetworks/ch07.htm
sezione 'Configuration Guidelines for Multiple Ethernet Segments'


 Facendo passare il frame attraverso un repeater il gap si riduce.
letto e capito.
pero' consentimi un appunto alla traduzione:
"can lead to a reduction when combined with the signal disturbance" e' una
possibilita' che da come io interpreto (almeno in quel testo) e' una causa
secondaria non certa del lavoro del repeater.
Non ricordavo assolutamente comunque questa riduzione, grazie.
Non e' che dalle specifiche dell'hub si puo' ricavare almeno in parte?
Comunque nel caso di MAD il diametro e' minimo gli hub 6 e questo dovrebbe
permettere di funzionare.

 Non e' che dalle specifiche dell'hub si puo' ricavare almeno in parte?
Il preambolo del frame ethernet viene usato dal pll interno all'hub
per sincronizzarsi sulla portante. Chiaramente il tempo necessario
alla sincronizzazione puo` variare da frame a frame in funzione
di eventuale rumore presente al momento della sincronizzazione
stessa. Appena l'hub riesce a sincronizzarsi iniziera` a
ripetere il frame sulle altre porte. L'istante di tempo in cui
questo avviene rispetto al tempo di arrivo del frame e`
variabile e dipende appunto dal rumore presente in quel momento.
Da questo e` abbastanza facile capire perche` un hub puo` ridurre
il gap tra due frame consecutivi. Piu` hub si mettono in cascata
piu` la situazione peggiora.


 di eventuale rumore presente al momento della sincronizzazione
Chiarissimo e concordo. Pero' ci sara' un tempo minimo proprio
dell'elettronica e questo e' noto...

 dell'elettronica e questo e' noto...
Certo, il problema non e` della latenza introdotta dalla
componentistica che e`, chiaramente, costante e puo` essere
anche relativamente alta senza influenzare il gap in quanto 
e` sempre la stessa per ogni frame (inflenza il rtt ma questo 
e` altra cosa). Il problema e` dovuto alla differenza del
tempo di risposta del pll ad ogni frame in funzione del rumore.


 tempo di risposta del pll ad ogni frame in funzione del rumore.
merde, quando mi sembra di stringerla mi sfugge tra le dita. let me
riassuming:
- tra una frame e l'altra c'e' un intervallo chiamato inter-packet gap di
9,6 per Ethernet.
- le NIC sono progettate per fermarsi un attimo (blind-time) alla fine del
pacchetto per evitare che il normale rumore sia interpretato come inizio di
un pacchetto successivo
- il blind-time deve essere inferiore al gap... beh direi che non ci piove
Adesso abbiamo una frame che entra nel ripetitore. "Dietro" a 9,6 ce ne e'
un'altra (ecco il trucco) quindi il ripetitore stesso non puo' introdurre un
ritardo variabile e quindi deve solo sbrigarsi il piu' possibile a
presentare il segnale sulle porte!!!
La latenza _mantiene_ il gap a 9,6 mentre il tailgating "rosicchia"
sull'uscita del singolo pacchetto
Mi sembra d'esserci

 Mi sembra d'esserci
Esatto.
