Quote:
Originariamente inviato da Psyred
Secondo me invece i FEC non rappresentano ritrasmissioni a livello fisico tra CPE e dslam, ma errori corretti dalla Forward Error Correction, oppure i byte usati per quel processo.
Anch'io ho avuto quel dubbio, ma recenti letture sul G.INP e anche il comportamento stesso della connessione mi fanno pensare che le ritrasmissioni siano in numero più limitato di quanto si pensi.
Per esempio, com'è possibile che la latenza aumenti di quei 4 ms e tale rimanga a tempo indeterminato? Addirittura a me succede 9 volte su 10 anche quando riavvio il router, pure quando lo ho sostituito con il nuovo la latenza era aumentata dei consueti +4 ms (per scendere dopo, ma solo per brevi periodi).
|
Scusa ma non concordo con la tua interpretazione del funzionamento generale del meccanismo del G.INP. Se interpreto bene le tue parole mi sembra di capire che per te il "
trucco fondamentale" sia quello legato all'uso di un Reed-Solomon code "rinforzato" (
e senza delay!?), e che solo in caso di fallimento di quest'ultimo si ricorra alla ritrasmissione.
Invece io sono convinto che il funzionamento principale sia basato sulle ritrasmissioni. Poi (
e volevo anche scriverlo ma mi sembrava di aver già esagerato coi dettagli) è possibile che i Broadcom siano configurati in modo tale che
quando il numero di ritrasmissioni è molto elevato (come quando è presente un REIN sostenuto) poiché queste transitano sul bearing1 che sottrae banda al canale, allora tutto ricada su un meccanismo tipo "INP-delay", con delay fisso di 4ms. Il punto di scambio di metodo può benissimo essere determinato dall'overhead necessario al bearing1 in confronto con quello necessario all'INP-delay (che oltre ad aggiungere costantemente il delay necessario all'interleaving ha anche come effetto un
notevole overhead). Quindi normalmente si avranno ritrasmissioni, sino al punto in cui il bearing1 necessiterebbe di una banda superiore a quella introdotta da un normale (se pur potenziato) sistema interleaved. A quel punto potrebbe avvenire lo scambio di priorità tra i due metodi.
Tutto ciò mi sembra anche confermato proprio dall'articolo di cui hai messo il link, nella frase:
"For environments rich in frequent and short impulses that cause too many retransmit events, again this vectoring solution innovatively implements the standard. It uses a combination of interleaving and Reed-Solomon encoding to minimize retransmission of lost packets. Since these techniques add latency and reduce the channels' usable bandwidth, this particular solution employs control algorithms that have been tuned to activate only when the overhead they impose causes less impact than the retransmission losses they are preventing."
Ciò spiegherebbe quei casi in cui (solo coi Broadcom, mi pare) quando la banda è vicina al massimo (e quindi molte portanti hanno 15 bit, ossia sono frazionate in 256 livelli di ampiezza e 128 offset di fase) e perciò la sensibilità al REIN diventa molto accentuata, viene aggiunto un delay di 4ms. Esso sarebbe dovuto al fatto che le ritrasmissioni hanno superato quella soglia oltre alla quale diventa conveniente passare all'interleaved classico (e questo per questioni di overhead necessario al bearer1, non di ritardo). A questo proposito si pensi che il livello di una sola portante è di circa 35mVeff, che spartito tra i 256 possibili livelli di una portante con 15bit, dà una distanza tra un livello e l'altro di 0.13mVeff, e dunque un distubo di questa ampiezza genera già un errore.
A me sembra quindi che il caso dell'uso dell'interleaving sia l'eccezione per i casi estremi e non la regola, anche perché non si spiegherebbe come un metodo con correzione basata su FEC classico (Reed-Solomon più o meno potenziato) potrebbe fare a meno di delay costante.