[nuovoUtente86]

Se leggi i post precedenti ho ribadito più volte di riferirmi al contesto in esame (dove gli hope in esame sono in numero esiguo) e non ad una struttura di rete ipotetica.
Partendo dal presupposto(se ne parlava all' inizio di tale discussione, se ricordo) che il degrado introdotto dai core device è di principale interesse nei domini di collisione piuttosto che nelle reti commutate.

Originariamente inviato da hibone

quindi stai dicendo che in una rete ad albero di n livelli il tempo di commutazione non è, nel caso peggiore, proporzionale al numero dei livelli?

n livelli è solo un' informazione parziale. Il caso peggiore è dato da tutti i livelli pieni al 100% e con tutti gli hope in trasmissione lungo la dorsale(il che praticamente porterebbe alla totale congestione).
Nella pratica delle reti, il traffico è di tipo burst e le richieste di un singolo hope possono essere approssimate alla completa casualità di Poisson su un numero di postazioni abbastanza grande, il che garantisce un carico accettabile sulla rete ma porta a poter approssimare solo valori medi.
Non a caso, i link backbone sono solitamente di ordine superiore ai singoli collegamenti sul commutatore.

mi pare strano... non sono un esperto di reti ma se dalla radice dell'albero vado alla foglia ( o viceversa) e ad ogni passaggio di livello devo aspettare che lo switch commuti, mi aspetto che i tempi di commutazione si sommino...

quindi almeno in linea di massima le prestazioni degradano...

Innanzitutto dovremmo metterci d' accordo sul degrado, ovvero le prestazioni degradano rispetto a cosa: banda,latenza, throughput....
Se prendiamo l' aumento di latenza(e il conseguente calo di throughput)come parametro, è additivo lungo la serie: la risposta è Si ma è molto molto generica e approssimanta, perchè non abbiamo informazioni necessarie per dirlo.
Non conosciamo il carico di host sugli switch, non conosciamo eventuali QoS impostate, e soprattutto non conosciamo il tipo di inoltro che il commutatore utilizza:
-store and forward
-fragment-free
-cut-through
in quest' ultimo caso, in una rete media (che mediamente trasmetta tra nodi e mediamente sulla dorsale)lo switch è quasi trasparente in quanto l' unico onere è la lettura del destination mac address.

se poi il degrado si traduce in collo di bottiglia o meno non lo ritengo così immediato. almeno a quanto ricordo tutto dipende dalla quantità di dati trasferiti.

voglio dire, se la rete è sfruttata al minimo delle sue possibilità, i ritardi non incideranno in modo significativo, mentre se la banda è sfruttata al massimo delle sue possibilità ecco che allora la somma dei ritardi si traduce in un collo di bottiglia. però, almeno a mio avviso l'equivalenza non è così immediata...

La definizioni di collo di bottiglia esula dal tipo e quantità di traffico trasmesso, ma indica, stabilito un parametro di riferimento, la parte di rete più lenta da attraversare (riferita al parametro).
Se stabilisco la banda e ho una rete adsl->56k->adsl la 56k sarà il collo di bottiglia per questa infrastruttura.
Se assumi che lo switch introduca latenza sul percorso assumi che sia un collo di bottiglia.In che misura lo sia, ovviamente cresce in maniera proporzionale al traffico.
Se in una rete con switch e hub considero il numero di ritrasmissioni (ma anche il throughtput) gli hub saranno sicuramente il punto di bottiglia.

visto che io non sono esperto, saresti così gentile da spiegarmi perchè il mio ragionamento è sbagliato?

Il ragionamento non è totalmente sbagliato, ma non è applicabile al contesto in esame, dove anche a regime la commutazione è pressoche trasparente..