View Single Post
Old 27-08-2016, 12:12   #75484
ironmark99
Senior Member
 
L'Avatar di ironmark99
 
Iscritto dal: Jan 2015
Città: Torino
Messaggi: 1430
Quote:
Originariamente inviato da Yrbaf Guarda i messaggi
Beh l'aumento di latenza non avviene quando c'è un FEC.

Un FEC è un errore corretto SENZA ritrasmettere.
Aehm... no. Almeno se per ritrasmissione intendiamo quella che avviene tra ONU e modem, come in G.INP.

In G.INP il FEC non viene utilizzato per correggere la DTU (ossia il pacchetto di dati) corrotta ma solo per individuare quelle che contengono errore. La correzione avviene a tutti gli effetti ritrasmettendo la intera DUT. Il numero di FEC indicati dal modem di fatto coincide col numero di ritrasmissioni avvenute. Il conteggio dei CRC invece mostra il numero di DTU che non è stato possibile correggere neppure con la ritrasmissione, e che dunque dovranno essere corrette dai livelli superiori (TCP o applicativo).

Il fatto che la latenza resti bassa anche in presenza di molti FEC (e dunque ritrasmissioni) è dovuta al fatto che l'aumento di latenza di 4ms (a parte eventuali bug) non è cumulativo per OGNI ritrasmissione avvenuta, ma complessivo.

I pacchetti ricevuti vengono memorizzati in un buffer di ricezione, essenzialmente per riorganizzarli nella corretta sequenza temporale in caso di ritrasmissione. La profondità di tale buffer è ciò che introduce il massimo ritardo di picco possibile in caso di correzione (Quello massimo POSSIBILE non quello che effettivamente ci sarà, che dipende invece dal tempo di ritrasmissione, ma questo lo vedremo più tardi). Normalmente (senza errori) i dati ricevuti vengono immediatamente inoltrati in uscita, ma contemporaneamente anche accumulati nel buffer di ricezione, in cui rimangono per un tempo che dipende dalla profondità dello stesso, per poi uscirne, uno ad uno, nella stessa sequenza in cui vi sono entrati. Ogni singola DTU resta dunque nel buffer di ricezione per tutta la sua lunghezza. Individuato un errore i dati smettono di uscire direttamente, ma continuano ad accumularsi nel buffer di ricezione. Il modem chiede il reinvio del pacchetto errato e attende che il pacchetto corretto arrivi. Al suo arrivo il pacchetto errato presente nel buffer di ricezione viene sostituito da quello corretto, lì, nel posto in cui nel frattempo è arrivato. A questo punto tutta la parte di buffer di ricezione accumulata nell'attesa e non ancora inviata, può essere trasmessa all'uscita (ovviamente di gran carriera) e i dati ricevuti possono essere nuovamente inviati direttamente in uscita.

Guardando solo l'uscita si noterà dunque che ad un certo punto il flusso dati alla normale velocità si interrompe, e per un tempo pari al tempo del reinvio del pacchetto corretto non arriveranno altri dati. Improvvisamente poi i dati riprenderanno a fluire, ancora nella corretta sequenza di invio, a velocità molto superiore al normale, sino a riprendere, ad un certo punto la velocità normale. Questo effetto di "pompaggio" si chiama jitter, ed ha introdotto un picco di latenza di 4ms.

Ovviamente durante i 4ms di "blackout" sui dati in uscita, ossia nella attesa della ritrasmissione di una DTU corretta, è possibile che altre DTU in arrivo siano errate e se ne debba richiedere la ritrasmissione. Nel caso in cui ciò accada, all'arrivo della prima DTU corretta, il buffer di ricezione viene ributtato all'uscita non completamente, ma solo sino alla posizione della seconda DTU da correggere, che poiché la prima è appena arrivata, dovrà ancora arrivare. Guardando l'uscita del modem si vedrà dunque come prima, una improvvisa interruzione del flusso dei dati dovuto alla attesa della prima DTU corretta, poi un improvviso riprendere del flusso dati a velocità elevata, ma per un totale di solo una parte dei dati mancanti all'appello, per poi reinterrompersi. Finché però il tempo di ritrasmissione non eccede mai i 4ms, anche la latenza non eccede mai questo valore. Semplicemente il jitter, sin ché continuano ad arrivare DTU errate, continua ad "pompare" tra un minimo di 0 ad un massimo di 4ms.

A 100Mbit/s le DTU sono circa 700/s (ogni DTU contiene 65byte di payload più alcuni byte di overhead). Virtualmente il meccanismo sarebbe in grado di correggere tutte le DTU errate, ma almeno due fenomeni lo impediscono.

Il primo dipende dal fatto che anche le DTU ritrasmesse possono essere corrotte dal rumore durante la ritrasmissione. Per limitare questa possibilità esse viaggiano su un canale riservato (bearer1) sul quale la protezione dall'errore è data da un meccanismo più potente di correzione immediata (extended Golay code) al quale si devono i 4ms di latenza di questo canale (2 per direzione, tra richiesta e renvio). Infatti il ritardo nella ritrasmissione non è certo dovuto al tempo di transito del segnale sul cavo, tempo che si misura in microsecondi al chilometro. Tuttavia anche questo metodo non è infallibile e può capitare che, per disturbi particolarmente grandi, una DTU ritrasmessa venga corrotta nella ritrasmissione e dunque debba nuovamente essere richiesta. Ciò porterebbe il ritardo di ritrasmissione al doppio del normale (8ms) e nel frattempo la DTU corrotta immagazzinata nel buffer di ricezione potrebbe esserne già fuoriuscita (dipende dal dimensionamento della profondità del buffer) e a quel punto si avrebbe un CRC, ossia la presenza di una DTU non corretta. Tuttavia se il buffer di ricezione fosse dimensionato per contenere almeno 8ms di DTU, non si avrebbe il CRC, ma un picco di latenza di 8ms. Questo raddoppiarsi della latenza dovuta alla ritrasmissione sarebbe comunque un fenomeno molto raro (dato che una doppia ritrasmissione non dovrebbe accadere se non in casi estremi), e che sposterebbe di pochissimo la latenza media.

Il secondo fenomeno che rende impossibile correggere tutte le DTU è che il bearer1, su cui viaggiano le ritrasmissioni, sottrae banda al bearer0 su cui viaggia il normale flusso dati. Se si dovessero ritrasmettere tutte le DTU (a causa di un rumore impulsivo davvero grave) in pratica si dimezzerebbe il bitrate del canale, portando l'overhead del meccanismo a valori troppo elevati (anche se si tratterebbe di un overhead dinamico, presente solo in caso di disturbi davvero imponenti). Si preferisce dunque limitare il massimo possibile bitrate sostenibile dal bearer1 ad una frazione (che non conosco) del massimo bitrate del canale. Questa operazione di fatto limita il numero massimo di errori correggibili nell'unità di tempo.

Questa è la descrizione di come ho inteso il meccanismo del G.INP... e ovviamente è, come sempre, salvo errori od omissioni.
__________________
Il mio PC autocostruito e raffreddato ad acqua: http://irom.eu/w --- Modem reader: qui l'installer e qui l'help on line --- Qui il simulatore VDSL v1.0 e qui quello v2.0

Ultima modifica di ironmark99 : 27-08-2016 alle 12:19.
ironmark99 è offline   Rispondi citando il messaggio o parte di esso