[FTTC] TIM FTTC - Pre-installazione linea (info/richieste/prezzi/FAQ)

[mastra911]

Ciao a tutti ma per richiedere il modem nuovo cosa si deve fare?

Inviato dal mio galaxy S5 usando tapatalk

[rokis]

Originariamente inviato da oxidized

?? Non ho capito

risposta al quel ragazzo per una domanda già fatta, imho un tantinello aggressiva

[drunkct]

Originariamente inviato da oxidized

Non credo proprio tu possa essere così lontano dall'armadio, non sarai neanche 200 metri distante con quei valori

Chiaramente mi sono tenuto leggermente largo...ma ti assicuro che 300 metri sono sicuri,oltre che Google maps ho fatto il tragitto almeno 4 volte sia con un app dello smartphone,ed anche con il contachilometri della macchina.
Considera che il tratto secondario è nuovo (nemmeno un anno) e anche l'impianto.

Originariamente inviato da Psyred

E' una peculiarità del nuovo modem. Il G.INP comunque è attivo, lo si evince dal valore di INP di 59/59 simboli (io ho 59/61) e dal delay (Ritardo Effettivo) di 0 ms.

Grazie.

[corra98]

Originariamente inviato da drunkct

Chiaramente mi sono tenuto leggermente largo...ma ti assicuro che 300 metri sono sicuri,oltre che Google maps ho fatto il tragitto almeno 4 volte sia con un app dello smartphone,ed anche con il contachilometri della macchina.
Considera che il tratto secondario è nuovo (nemmeno un anno) e anche l'impianto.

Attenuazione?

[drunkct]

Originariamente inviato da corra98

Attenuazione?

Dallo screen vedo 3,8 e 10,3.

[rokis]

Ciao ragazzi un'informazione, chi di voi ha la XBOX ONE collegata via LAN?
A quanto scaricate?
Io da speed test su PC faccio 94 95, ma sulla xbox non scarica a più di 50Mbps, lo fa anche a voi?
Ciao e grazie!

[mastra911]

Originariamente inviato da rokis

Ciao ragazzi un'informazione, chi di voi ha la XBOX ONE collegata via LAN?
A quanto scaricate?
Io da speed test su PC faccio 94 95, ma sulla xbox non scarica a più di 50Mbps, lo fa anche a voi?
Ciao e grazie!

Ciao io ho la xbox one collegata con il cavo, da speedtest faccio 57 58mb e dalla one mi segna max 54 55mb

Inviato dal mio galaxy S5 usando tapatalk

[oxidized]

Originariamente inviato da rokis

risposta al quel ragazzo per una domanda già fatta, imho un tantinello aggressiva

Giusto per essere precisi, quale sarebbe questa risposta aggressiva? Perché ho controllato i vecchi post, e non c'è niente di simile. Anzi ho risposto a te consigliandoti di usare la funzione "cerca nella discussione"

Originariamente inviato da drunkct

Chiaramente mi sono tenuto leggermente largo...ma ti assicuro che 300 metri sono sicuri,oltre che Google maps ho fatto il tragitto almeno 4 volte sia con un app dello smartphone,ed anche con il contachilometri della macchina.
Considera che il tratto secondario è nuovo (nemmeno un anno) e anche l'impianto.

Grazie.

Allora semplicemente c'è quasi niente di diafonia stando alla tabella di ironmark, ottimo!

Originariamente inviato da ironmark99

[rokis]

Originariamente inviato da oxidized

Giusto per essere precisi, quale sarebbe questa risposta aggressiva? Perché ho controllato i vecchi post, e non c'è niente di simile. Anzi ho risposto a te consigliandoti di usare la funzione "cerca nella discussione"



Allora semplicemente c'è quasi niente di diafonia stando alla tabella di ironmark, ottimo!

Mea Maxima Culpa , ti ho confuso con "diaretto", mi sono impicciato con i quote anzi tu mi avevi dato ragione, la pensi come me!
Scusami ancora!!!

[rokis]

Originariamente inviato da mastra911

Ciao io ho la xbox one collegata con il cavo, da speedtest faccio 57 58mb e dalla one mi segna max 54 55mb

Inviato dal mio galaxy S5 usando tapatalk

Beh tu sei al limite quasi uguale allo speed test, difficile da capire, ci vorrebbe qualcuno che fa 90 come me sullo speed test e verificare a che velocità scarica con la ONE!
Comunque grazie lo stesso per il contributo!!!!

[oxidized]

Originariamente inviato da rokis

Mea Maxima Culpa , ti ho confuso con "diaretto", mi sono impicciato con i quote anzi tu mi avevi dato ragione, la pensi come me!
Scusami ancora!!!

Niente! diaretto a volte è un po nervoso, ma è in gamba

[ignaziogss]

Originariamente inviato da diaretto

Inutile allarmarsi tanto e riempire il post di thread, la linea è palesemente guasta e devi solo attendere che il tecnico venga a risolvere, noi qui non possiamo dirti nulla, lo capisci da solo che la linea è ovviamente guasta.

Risolto brillantemente, dopo diversi test, con cambio coppia. Un ringraziamento sentito al tecnico che si e' prodigato, con successo. E un grazie (e complimenti) sentiti anche alla TIM che mi ha mandato il tecnico a casa a tempo di record e persino di sabato. E' bene scrivere quando qualcosa va male ma trovo che sia un dovere anche scrivere le cose che vanno bene, altrimenti si ha l'impressione che succedano solo cose brutte

[diaretto]

Originariamente inviato da ignaziogss

Risolto brillantemente, dopo diversi test, con cambio coppia. Un ringraziamento sentito al tecnico che si e' prodigato, con successo. E un grazie (e complimenti) sentiti anche alla TIM che mi ha mandato il tecnico a casa a tempo di record e persino di sabato. E' bene scrivere quando qualcosa va male ma trovo che sia un dovere anche scrivere le cose che vanno bene, altrimenti si ha l'impressione che succedano solo cose brutte

Ottimo! Tecnico di sabato per intervento personale mi è nuova, davvero fortunato!

[ironmark99]

Originariamente inviato da Yrbaf

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.

[giovanni69]

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!

[corra98]

Originariamente inviato da drunkct

Dallo screen vedo 3,8 e 10,3.

Ops, me l'ero perso. Grazie

[oxidized]

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

[drunkct]

Originariamente inviato da oxidized

Giusto per essere precisi, quale sarebbe questa risposta aggressiva? Perché ho controllato i vecchi post, e non c'è niente di simile. Anzi ho risposto a te consigliandoti di usare la funzione "cerca nella discussione"



Allora semplicemente c'è quasi niente di diafonia stando alla tabella di ironmark, ottimo!

Molto probabile...considera che l'armadio dai file risulta attivo da questo mese.

Inviato dal mio SM-G930F utilizzando Tapatalk

[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).

[Psyred]

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.