|
|
|
|
Strumenti |
27-08-2016, 12:12 | #74901 | |
Senior Member
Iscritto dal: Jan 2015
Città: Torino
Messaggi: 1599
|
Quote:
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 --- Qui tutti i miei interventi su HU --- Modem reader: qui l'installer e qui l'help on line --- Qui il simulatore VDSL v3.0 Ultima modifica di ironmark99 : 27-08-2016 alle 12:19. |
|
27-08-2016, 12:23 | #74902 |
Senior Member
Iscritto dal: Jun 2005
Messaggi: 21829
|
O.T. Una delle cose più disastrose di questo forum che pur fornisce un incredibile servizio a noi tutti, è il fatto che si accedano ai post di ironmark solo dall'inizio dell'anno.. le solite 25 pagine. Grazie ironmark99!!!
E non me ne vogliano gli altri a partire in primis da diaretto & C. che pur ci aiutano tutti con generosità, competenza e... pazienza! |
27-08-2016, 12:25 | #74903 |
Senior Member
Iscritto dal: Dec 2015
Città: Piacenza
Messaggi: 494
|
__________________
TIM FTTC 100/20 dal 7/01/16. Aspettando OpenFiber... |
27-08-2016, 12:26 | #74904 |
Senior Member
Iscritto dal: Nov 2013
Messaggi: 1455
|
Devo dire che di solito preferisco forum stranieri, ma quando si parla di certi argomenti, davvero non credo ci siano paragoni rispetto quello che ho trovato su questo forum e su questo thread in particolare. Davvero, grazie
Italians do it better |
27-08-2016, 12:27 | #74905 | |
Member
Iscritto dal: Oct 2014
Messaggi: 54
|
Quote:
Inviato dal mio SM-G930F utilizzando Tapatalk |
|
27-08-2016, 12:28 | #74906 |
Senior Member
Iscritto dal: Dec 2004
Messaggi: 15570
|
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).
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing] |
27-08-2016, 12:44 | #74907 |
Senior Member
Iscritto dal: Dec 2004
Messaggi: 15570
|
Riquoto qui il brano di un articolo che avevo già linkato e citato una settimana fa:
The first layer of G.inp's protection uses a combination of a strong Reed-Solomon Forward Error Correction (FEC) encoding scheme that hardens packets against multiplebit errors and a retransmission scheme to recover packets that are unrecoverable with FEC coding. When a VDSL transceiver encounters persistent, severe impulse noise, interleaving techniques are also employed to further harden the channel against data loss. http://www.ospmag.com/issue/article/Saving-Coppers-Life Quindi secondo questo autore in teoria già la FEC dovrebbe essere sufficiente di per sè a salvaguardare l'integrità di buona parte dei pacchetti, ricorrendo limitatamente alla ritrasmissione e in extrema ratio anche a tecniche di interleaving. Ecco perchè mi torna poco questo discorso dei FEC.
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing] Ultima modifica di Psyred : 27-08-2016 alle 12:52. |
27-08-2016, 12:54 | #74908 | |
Senior Member
Iscritto dal: Nov 2013
Messaggi: 1455
|
Quote:
|
|
27-08-2016, 13:02 | #74909 |
Senior Member
Iscritto dal: Dec 2004
Messaggi: 15570
|
Io a dire il vero ho sempre avuto il "vecchio", il nuovo modello ce l'ho da pochi giorni. A livello di FEC non mi sembra di notare particolari differenze comunque.
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing] |
27-08-2016, 13:17 | #74910 |
Senior Member
Iscritto dal: Nov 2013
Messaggi: 1455
|
Boh, io per quei pochi giorni che ho provato il nuovo, m'è sembrato di leggere valori FEC totalmente diversi, probabilmente mi sbaglio, comunque la differenza c'è tra i technicolor e altri (non so quali) modem, a quanto pare i tc conteggiano in un modo particolare, questo è quello che leggevo in questo thread diverse pagine fa
|
27-08-2016, 13:20 | #74911 | |
Senior Member
Iscritto dal: Dec 2004
Messaggi: 15570
|
Quote:
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing] |
|
27-08-2016, 13:25 | #74912 |
Senior Member
Iscritto dal: Nov 2013
Messaggi: 1455
|
Io avevo il technicolor più vecchio di tutti, e l'ultimo, m'è sembrato che qualche differenza c'era, ripeto, non sono sicurissimo.
|
27-08-2016, 13:35 | #74913 |
Senior Member
Iscritto dal: Jun 2016
Città: PD province
Messaggi: 2160
|
Secondo un semplice conteggio, sembra che gli errori FEC non richiedano nessuna correzione a meno che falliscano, poi se il modem conti anche quelli falliti non lo so, ma visti i numeri e' ininfluente:
prendo in esame i dati postati di quella linea qualche fa e faccio un calcolo semplicissimo: Up time: 181395 Total FEC Errors: 127044668 che significa 700.37 fec corretti al secondo Inronmark infatti riporta che le a 100Mbit/s le DTU sono circa 700/s Visti i crc, la quantita' di pacchetti che devono essere trasmessi e' pari a 0,385 al secondo, ed ecco che diventa difficile apprezzare delle perdite, e del fatto che la mia e la sua linea si equivalgono in prestazioni. Fra l'altro vi ringrazio perche' con le informazioni che mi avete fornito comincio a capire l'origine del problema: nessun pacchetto o raramente i pacchetti arrivano integri, piu' del 99% dei pacchetti viene corrotto ma solo lo 0,05% circa richiede la ritramsissione e quindi anche il suo ping non differisce dal mio. Dato che tutti i pacchetti vengono danneggiati e son oquasi sempre riparabili devo cercare un'interferenza che genera un impulso molto stretto e a elevata frequenza, lavoro da vent'anni in elettronica e ipotizzo che al 90% c'e' un alimentatore switching senza presa di terra (noncnecessariamente) con il condensatore del circuito primario in perdita e che deve essere collegato nei pressi del cavo direte alimentazione che affianca il doppino. edit: la correzione dei fec usa l'algoritmo di Reed Solomon, richiede un doppio overhead che puo essere variabile di dimensione, confermato anche da Ironmark qualche post fa, ma la dimensione dei due gruppi ridondanti non e' scritta da nessuna parte, forse viene decisa quando viene creato il profilo; il maggiore indagato all'origine delle interferenze adesso e' un gruppo di continuita' del tipo always-on-line a sinusoide perfetta; questo tipo di gruppo e' sempre attivo nel senso che la tensione viene abbassata e poi rialzata senza mai bypassare il circuito, quindi ha due trasformatori, ma per generare una sinusoide perfetta in uscita pilota un trasformatore da 50hz con un pwm sui 20khz in modo da non generare un fischio udibile, e questo potrebbe essere la fonte di interferenza; in questo caso aiuta la codifica di trellis che sparge i bit secondo un ordinamento preciso, il picco che arriva dal pwm dell'ups ha una certa larghezza e danneggerebbe una serie di bit consecutivi rendendo impossibile la correzione precedente, invece questi bit dopo la ricodifica trellis risultano sparsi e la reed solomon riesce a correggere piu' del 99% come verificato sopra. Sempre se confermato il meccanismo di funzionamento ovviamente.............. edit: con i nuovi numeri piu' precisi forniti da Ironmark i conti sono tutti da rifare, ma stasere ho la sindrome dello zombie perche' e' l'ultimo giorni di ferie........... Ultima modifica di Busone di Higgs : 28-08-2016 alle 19:18. |
27-08-2016, 14:17 | #74914 | |
Senior Member
Iscritto dal: Jul 2009
Messaggi: 739
|
Quote:
probabile che limitano la banda per non intasare i server e consentire a più persone contemporaneamente di usufruire del servizio. facendo un es. molto semplificato, se il server può erogare 10mb/s loro preferiscono far connettere 10 persone a 1mb/s piuttosto che una sola a 10mb/s. certo a 10mb/s finisci prima e lasci il posto a un altro, ma nel frattempo gli altri 9 restano fermi e allora meglio un servizio limitato a tutti che un servizio ottimo per qualcuno e disservizio agli altri
__________________
[Cooler Master Centurion 5] [Cooler Master B700 V2] [Intel Core i5 750] [AC Freezer Xtreme Rev. 2] [Gigabyte GA-P55M-UD4] [2x2Gb G.Skill Ripjaws 1600Mhz cl9] [Sapphire Ati Radeon HD6870] [Maxtor 320Gb + Seagate 200Gb] [DeLL U2414H] [Enermax Aurora Premium] [Windows 7 Home Premium 64bit] GAMERTAG XBOX360 PSN ID |
|
27-08-2016, 14:19 | #74915 |
Senior Member
Iscritto dal: Feb 2001
Città: Vicenza
Messaggi: 5240
|
Io ho questi valori
Cabinet a 500 metri e linea VDSL naked e da due giorni ho questi errori, come vi sembrano?
__________________
Corsair 4000d Airflow | AMD Ryzen 7 5800x | Asus TUF GAMING B550-PLUS | Corsair iCUE H115i Elite + LCD Upgrade Kit | 32 GB Corsair Vengeance LPX DDR4 3600MHz | nVidia Geforce 3070ti FE | Corsair RM750X | Samsung 980 PRO NVMe M.2 SSD 1 TB + Crucial MX500 1TB | LG 27GL83A | Logitech G915 | Logitech G Pro Wireless + Logitech G440 Gaming Mouse Pad | |
27-08-2016, 15:08 | #74916 | |
Member
Iscritto dal: Aug 2016
Messaggi: 92
|
Quote:
Io sono in derivazione secondaria (con 2 pallini in pratica): considerando che il cabinet dalla mia chiostrina dista 250 metri a stare larghi (in linea d'aria saranno 150 metri), io avrò comunque un'attenuazione altissima? Vale la pena andare in VDSL? ma soprattutto, c'è una qualche correlazione tra come andavo in ADSL e come andrei in VDSL considerando che il problema qui sta in un tratto che non viene modificato? |
|
27-08-2016, 15:23 | #74917 |
Senior Member
Iscritto dal: Dec 2010
Messaggi: 570
|
Speriamo che da lunedi riprendono ad aggiornare i file e rendano verde il mio semaforo
__________________
Tim FTTH profilo 1000/300 |
27-08-2016, 15:27 | #74918 | |
Senior Member
Iscritto dal: Dec 2010
Messaggi: 3362
|
Quote:
Non avrai un'attenuazione alta per via della derivazione, avrai un buco nell'attenuazione ad una certa frequenza e vari sottobuchi a multipli del primo picco. Questo ti fa perdere ovviamente Mb di banda rispetto a non avere la derivazione. No non puoi desumere nulla sulla VDSL partendo dall'ADSL, non c'entra nulla il tratto di derivazione in comune, anche perchè in ADSL essendo frequenze circa 1/8 più basse gli effetti delle derivazioni sono diverse, potresti non "vederla" sulla tua linea una certa derivazione.
__________________
CPU: i5 760 MOBO: P7P55D-Deluxe RAM: Corsair DDR3 Dominator 1600MHz CL7 VGA: Radeon HD 6870 DISSI: Arctic Cooling Freezer Xtreme SSD: Samsung 840 HD: 2x Seagate 280GB RAID 0 ALI: Cooler Master 700W Modulare |
|
27-08-2016, 15:36 | #74919 |
Senior Member
Iscritto dal: Nov 2013
Messaggi: 2486
|
|
27-08-2016, 15:38 | #74920 |
Senior Member
Iscritto dal: Dec 2010
Messaggi: 570
|
Il sabato si, la domenica solo per le emergenze.
__________________
Tim FTTH profilo 1000/300 |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 09:53.