Quote:
Originariamente inviato da MiloZ
Visto che siamo un pò in argomento errori e quant'altro, mi chiedevo una curiosità tecnica che penso pochi oltre te potrebbero chiarire.
|
Ti ringrazio per la fiducia
MiloZ, tuttavia io sono più che altro un esperto del livello fisico, e ciò che mi chiedi esula un po' dal mio campo specifico. Prendi ciò che sto per dire con le dovute cautele. Potrebbe essere una eccessiva semplificazione del problema, e non del tutto accurato/aggiornato.
Quote:
Da poco Fastweb ha cominciato ad attivare il G.INP, ed ho notato che i valori sono un pò differenti dai nostri, sia come INP che come INPRein.
Esempio di un paio di linee Fastweb che agganciano una portante sui 100.000Kbps: ...cut...
Cioè, se effettivamente è possibile configurare il G.INP in maniera più o meno protettiva, perchè non metterlo sempre con la protezione massima? E' già così?
...cut...
E' anche possibile per caso impostare il G.INP in maniera tale che nella peggiore delle ipotesi (o in certe condizioni) possa alzare la latenza, se necessario, di OLTRE 4ms? Oppure 4ms è il massimo?
|
Intanto va detto che sì, anche il G.INP è configurabile per essere più o meno protettivo. Esistono tuttavia dei limiti legati alla memoria fisica dell'apparato, alla sua potenza di calcolo e al massimo delay che si è disponibili a sopportare.
Mi spiego meglio:
ricordi la vecchia protezione INP/delay in uso prima dell'arrivo del G.INP?
La protezione veniva sempre descritta con due valori, tipo 2/8, che stava per protezione di 2 simboli ogni 8ms. Questi valori significavano che la protezione era in grado di correggere
completamente sino a due simboli DMT errati (non importa quanto) ogni 8 millisecondi. Ciò comportava tuttavia una latenza (ritardo) minima di 8 millisecondi, perché il sistema doveva attendere quel tempo per riempire la memoria di simbolo prima di poter effettuare la correzione. Dunque il ping minimo del sistema diventava 8 ms.
Va chiarito che una protezione 2/8 è migliore di una protezione 2/16, perché avere 2 simboli errati ogni 8 millisecondi è più "grave" che avere 2 simboli errati ogni 16 millisecondi (ciò perché nel secondo caso la frequenza degli errori è la metà di quella del primo caso). La seconda configurazione è dunque più rilassata della prima: richiede, è vero, il doppio di memoria di simbolo, ma anche la metà delle capacità di calcolo. Approfondendo ulteriormente si può dire anche che una protezione 4/16, pur potendo correggere praticamente gli stessi errori di una 2/8 richiede il doppio della memoria (e quindi comporta un ping minimo di 16ms) e la stessa capacità di calcolo (stesso numero di simboli da correggere nell'unità di tempo). La seconda ha solo il piccolo vantaggio di poter correggere anche 4 errori consecutivi nei primi millisecondi purché non ne arrivino altri nei 16 ms complessivi, cioè regge un po' meglio i burst di errore (e ti fa pagare pegno di ciò sul ping), ma regge meno bene il rumore REIN.
Ciò ci fa intravedere il concetto di protezione REIN. Un rumore di tipo REIN è un rumore ripetitivo (lo dice l'acronimo stesso che significa
Repetitive Electrical Impulse Noise, ossia rumore da disturbo elettrico ripetitivo) tipicamente generato dagli apparati elettrici. Dato che la nostra rete elettrica funziona a 50Hz, i disturbi che questi apparati generano sono tipicamente a 100Hz (un impulso per ogni attraversamento dello 0 della sinusoide della tensione di alimentazione). Dato che il periodo di una frequenza a 100Hz è 10ms, se voglio proteggermi da questo tipo di disturbi è bene che questo sia il periodo massimo su cui devo tarare la mia protezione. Ed ecco perché si usano 8ms come tempo base per l'INP classico (per inciso 8ms vanno bene anche per le reti a 60Hz poiché il reciproco di 120Hz è 8.333ms). Questa base di 8ms mi dice che posso correggere un REIN con frequenza di ripetizione sino a 125 Hz. Il numero di simboli che riesco a correggere ogni 8ms è il mio INPRein quando il REIN è a 125Hz.
I valori di INP e INPRein che vedi sul bearer1 sono i valori di INP classico con cui è protetto il canale usato per la ritrasmissione (dato che anche lui deve essere protetto). Se guardi vedrai che TIM ha scelto di correggere sino a 3 simboli ogni 2ms, che comportano un ritardo nella ritrasmissione di 4ms (se ci sono errori). FW ha invece scelto di correggere 5.5 simboli ogni 4ms che comportano un ritardo nella ritrasmissione di 8ms (sempre se ci sono errori). Ora, 3 simboli ogni 2 ms (ossia 6 simboli ogni 4ms) sono di più che 5.5 ogni 4ms, quindi la protezione di TIM (sul canale di ritrasmissione) è un po' più efficace al rumore ripetitivo. Il calcolo del valore di INP equivalente di 59 di TIM rispetto a quello di 76 di FW dipende dai vari parametri di configurazione della macchina a stati interna al firmware di ritrasmissione. Sinceramente ho cercato di capire come il G.INP lo calcoli, ma non mi è per nulla chiaro. Probabilmente l'apparente valore superiore di Fastweb dipende da una "base tempi" diversa. In effetti dire solo il valore dei simboli correggibili senza dire in quale periodo di tempo lascia un po' il tempo che trova. Mi sembra probalile che il valore sia riferito al ritardo di ritrasmissione, quindi sarebbe 59/4 per TIM e 76/8 per Fastweb (che renderebbe la protezione data da TIM più efficace). Non ho invece idea del perché di quel delay=0 nel bearer1 per l'US di TIM.
Riguardo al fatto di configurare sempre l'INP alla massima protezione dipende sia dalla memoria disponibile, sia dalla capacità di calcolo del processore, sia dagli effetti che si vogliono raggiungere. Inoltre esiste un limite legato al
massimo bitrate raggiungibile data una certa protezione. A questo proposito posso dire che il 35b richiederà l'uso del G.INP in DS, perchè
l'attuale configurazione standard dell'INP (usata fino a poco fa da Fastweb), data la memoria di calcolo disponibile sui modem in uso
limiterebbe il flusso DS a un massimo di poco superiore ai 100Mbit/s (la lunghezza di un simbolo DMT dipende dal bitrate. A parità di simboli memorizzati per la loro correzione, la memoria richiesta cresce col bitrate).
Riguardo all'alzare in certi casi la latenza, come abbiamo detto, ciò non renderebbe la protezione più efficace, anzi! Oltre a richiedere più memoria renderebbe solo la latenza più alta, senza che il numero di simboli proteggibili per unità di tempo possa aumentare.
Quote:
Mi veniva anche un'altro dubbio: non è che quegli utenti di cui abbiamo avuto qualche feedback in passato collegati a certi ONU Alcatel 192p e Selta 64p che rilevavano (stranamente) una latenza di quasi 15ms al gateway con il Technicolor avessero ping del genere a causa di una differente configurazione del G.INP? Che appunto in certe situazioni desse come risultato una latenza maggiore? Impossibile? 
|
Mi sembra possibile, ma di più non saprei dire...
Questo è quello che so e mi sento di dire... Per chi avesse voglia di approfondire il funzionamento del G.INP
ecco il link alla specifica ITU (solo in inglese) che è liberamente scaricabile in .pdf
Buona lettura.