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

[Barrys]

Originariamente inviato da giovanni69

Esatto, una 60/17 diciamo dovrebbe esserti assicurata, se hai l'impianto in casa ok.

L'impianto di casa consiste in un cavo ct1220 di 15 metri circa giuntato a quello che arriva da fuori, che arriva ad una rj11. direi che da questo punto di vista sto in una botte di ferro.

[rokis]

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

Ti quoto al 100% anche a me hanno risolto in tempi brevissimi, ho telefonato il venerdì per un calo di banda e delle disconnessioni, venuto di sabato mattina risolto brillantemente con un cambio di coppia secondaria, veramente gentilissimi sia il tecnico sia la tipa del 1949!

[Psyred]

Originariamente inviato da ironmark99

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.

Avevo già citato anche quel brano dell'articolo nel post della settimana scorsa http://www.hwupgrade.it/forum/showpo...ostcount=75224

proprio nel tentativo di comprendere la faccenda dei famosi +4 ms dei Broadcom. Che difatti anche secondo me derivano da un interleaving aggiunto, forse in modo fino troppo prudente.

Per il resto il discorso dell'autore mi pare chiaro e comprensibile, io rimango della mia idea.

[ironmark99]

Originariamente inviato da Psyred

Per il resto il discorso dell'autore mi pare chiaro e comprensibile, io rimango della mia idea.

Fai bene.
Anche io resto della mia, anche perché lo dice l'autore dell'articolo, nella frase che ho evidenziato in rosso. Come la interpreti tu?

[Psyred]

Originariamente inviato da ironmark99

Fai bene.
Anche io resto della mia, anche perché lo dice l'autore dell'articolo, nella frase che ho evidenziato in rosso. Come la interpreti tu?

L'autore specifica in ambienti particolarmente "rumorosi" For environments rich in frequent and short impulses that cause too many retransmit events

ossia quando la FEC non riesce più a gestire la grande mole di dati corrotti e le ritrasmissioni per forza di cose aumentano.

Però non è detto che quello debba essere il comportamento normale del G.INP.

[ironmark99]

Originariamente inviato da Psyred

L'autore specifica in ambienti particolarmente "rumorosi" For environments rich in frequent and short impulses that cause too many retransmit events

ossia quando la FEC non riesce più a gestire la grande mole di dati corrotti e le ritrasmissioni per forza di cose aumentano.

Però non è detto che quello debba essere il comportamento normale del G.INP.

Guarda, dato che lo ho provato di persona in laboratorio, posso confermarti che il comportamento "normale" del G.INP è ritrasmettere, e caso mai creare jitter. Sui casi estremi mi sa che diciamo la stessa cosa... con un REIN pesante avvengono troppe ritrasmissioni ergo passa a INP-delay, e aggiunge i 4ms stabili.

[animalenotturno]

INFORMAZIONE DA FARE GIRARE: ALLE 21.00 SONO USCITO DAL LAVORO ARRIVA UN COMUNICATO DAI NOI TECNICI CHE ENTRO OTTOBRE 2016 TIM COMINCERà A usare il vectoring e la banda in upload verrà cambiata per le nuove attivazione da 20mega a 50mega ! danno come data ottobre ma io penos che se ne parlo il prossimo anno 2017

roba che ho trovato in giro.. bufala?
a quando con il 35b?

[Psyred]

Originariamente inviato da ironmark99

Guarda, dato che lo ho provato di persona in laboratorio, posso confermarti che il comportamento "normale" del G.INP è ritrasmettere, e caso mai creare jitter. Sui casi estremi mi sa che diciamo la stessa cosa... con un REIN pesante avvengono troppe ritrasmissioni ergo passa a INP-delay, e aggiunge i 4ms stabili.

Però come è possibile che anche quando aumentino a dismisura i FEC rilevati (sto parlando del Technicolor) non ci sia la minima conseguenza sul jitter?

Io ho avuto sia pochi FEC che vagonate, e in entrambi i casi il ping rimaneva stabile (anche quando era a 6 ms, ergo senza delay aggiunto).

[ironmark99]

Originariamente inviato da Psyred

Però come è possibile che anche quando aumentino a dismisura i FEC rilevati (sto parlando del Technicolor) non ci sia la minima conseguenza sul jitter?

Io ho avuto sia pochi FEC che vagonate, e in entrambi i casi il ping rimaneva stabile (anche quando era a 6 ms, ergo senza delay aggiunto).

Beh, il jitter è più evidente quando i FEC sono pochi, più aumentano e più il delay tende ai 4ms aggiunti. Comunque direi che il ping non è lo strumento adatto per vederlo. Noi lo rilevavamo (è c'era) con Wireshark (a parte gli strumenti di laboratorio, ovviamente).

[Psyred]

Originariamente inviato da ironmark99

Beh, il jitter è più evidente quando i FEC sono pochi, più aumentano e più il delay tende ai 4ms aggiunti.

A dire il vero il periodo dei 6 ms (fissi e stabili) è stato proprio quello in cui i FEC erano per me al picco massimo.

Anche un altro utente ricordo che ha sperimentato questa cosa.

In realtà sembra non esserci correlazione tra i FEC rilevati dal TC e la latenza, da qui tutti i dubbi.

[ironmark99]

Originariamente inviato da Psyred

A dire il vero il periodo dei 6 ms (fissi e stabili) è stato proprio quello in cui i FEC erano per me al picco massimo.

Anche un altro utente ricordo che ha sperimentato questa cosa.

In realtà sembra non esserci correlazione tra i FEC rilevati dal TC e la latenza, da qui tutti i dubbi.

Se mi capita mi informo...

[Yrbaf]

Originariamente inviato da ironmark99

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.

Per quanto mi fidi della tua interpretazione (nonostante pure io ero per il FEC + ritrasmissioni solo in caso CRC) non penso che tenere il FEC attivo (come protocollo di correzione non come finto contatore di errori) che sia senza delay.

Però io sapevo che il grosso del delay era dato dalla coda di interleaving, tolta quella rimane solo il computo del protocollo RS e magari l'hw di oggi lo fa sub 1 ms non rendendolo non particolarmente visibile.
Il mio modem segnala la presenza di un delay residuo di 0.15ms sul down con il G.Inp attivo.
Quindi se prendiamo per buona l'informazione a zero delay non è manco ipotizzando la parte FEC non attiva.

Infine sfogliando la documentazione ufficiale nei gg scorsi ho intravisto una frase che diceva che la latenza della tecnologia vdsl è di soli 2ms, e che gli ms aggiuntivi sono dovuti ai protocolli aggiuntivi per mantenere i dati corretti.
Non potrebbe essere il costo del FEC già compreso nei 1.5-2.5ms che separano un ping fast (ho già tolto un 1-1.5ms che sono dovuti probabilmente al router) dai 2ms citati ?
Insomma una roba tipo: 2ms di vdsl + 2-3 ms di FEC + 8-10 ms di interleave (se senza g.inp).
Non ho però appronfondito la lettura e quindi non sono neanche sicuro che i 2ms fossero un RTT (alias andata + ritorno) e non solo il tempo di volo sul bus vdsl.

PS
Su internet ho trovato affermazioni (però non so quanto attendibili) che dicevano (parlando però di adsl) che ha senso tenere il protocollo FEC attivo (per correggere) anche su canali FastPath.
I-FEC è la consuetudine ma FEC può vivere a parte da I (di interleaved)

[viko]

Allora ragazzi, la mia situazione e questa:nela citta dove abito , la copertura vdsl e quasi totale, tranne 3 cabinet nella mia zona . Secondo voi esiste qualche modo per poter attivare la vdsl(magari spostando la utenza al cabinet più distante) oppure mi dovrei rassegnare? La zona non e isolata, anzi, pero non capisco perché non hanno portato la fibra..

[totocrista]

Originariamente inviato da viko

Allora ragazzi, la mia situazione e questa:nela citta dove abito , la copertura vdsl e quasi totale, tranne 3 cabinet nella mia zona . Secondo voi esiste qualche modo per poter attivare la vdsl(magari spostando la utenza al cabinet più distante) oppure mi dovrei rassegnare? La zona non e isolata, anzi, pero non capisco perché non hanno portato la fibra..

Finché non coprono non si può.

[viko]

Originariamente inviato da totocrista

Finché non coprono non si può.

E che da come sono andate le cose credo che hanno gia coperto quello che dovevano coprire...quindi mi tocca tenere la adsl .

[Robecate]

Originariamente inviato da Yrbaf

PS
Su internet ho trovato affermazioni (però non so quanto attendibli) che dicevano (parlando però di adsl) che ha senso tenere il protocollo FEC attivo (per correggere) anche su canali FastPath.
I-FEC è la consuetudine ma FEC può vivere a parte da I (di interleaved)

Certo che ha senso. Dal punto di vista teorico di teoria dell'informazione, il codice RS corregge gli errori correggibili (il concetto di errore correggibile è definibile matematicamente e dipende solo dalla ridondanza e dalla suddivisione dei dati in blocchi) per cui è fondamentale soprattutto in assenza di interleaving che invece non introduce ridondanza ma solo ritardi.
Intuisco però dai vostri interessanti discorsi tecnici che attualmente sono state introdotte varianti che mescolano e adattano i due meccanismi per ottimizzare il tutto.

[rinelkind]

Originariamente inviato da Busone di Higgs

il punto e' che vista la quantita' di errori continuiamo a confrontare le nostre linee sia come latenza/ping etc sia come velocita' di trasferimento up/down, entrambe con massima intorno ai 116000 per capire che tipo di problemi gli possa creare; io ho crc solo con i temporali.
Se ripeti lo stesso test piu' volte sai che il risultato non e' mai uguale giusto?
Questa incertezza nelle nostre prove e' tale che non si capisce se c'e' qualche differenza, probabilmente c'e' ma e' nascosta dalle imprecisioni di queste misure.

E comunque qualche conto si puo' fare, ovvero un crc richiede una ritrasmissione ed incrementa la latenza di 4ms, accade ogni 3 secondi, ma quanti pacchetti/frame passano ogni 3 secondi a 100megabit?

Vedi che non ha senso, e ancor meno se si parla di FEC?
Se gli errori non sono consecutivi tali da avere un'interruzione di comunicazione per un certo tempo, le correzioni faranno il loro lavoro e la differenza non si notera'.

Io sarei curioso di una cosa... non è che puoi chiedere al tuo amico con quella linea piena di errori di fare un ping -n 4000 maya.ngi.it e poi riferirti il risultato? :P

[Busone di Higgs]

Originariamente inviato da rinelkind

Io sarei curioso di una cosa... non è che puoi chiedere al tuo amico con quella linea piena di errori di fare un ping -n 4000 maya.ngi.it e poi riferirti il risultato? :P

si puo' fare ma non credo che vedresti differenze significative, comunque dopo o domani edito il messaggio e metto il risultato;
con 700 frames al secondo e una ritrasmissione ogni 2 o 3 secondi, bisogna che il pacchetto contenente l'icmp del ping caschi in un buffer dove c'e' una ritrasmissione in corso, e dato che la trasmissione puo' essere inserita fra i frame che stanno riempendo quel buffer non e' detto che vengano addizionati i 4ms, e dato che c'e' molta variabilita' in generale l'incremento finira' perduto in questo "jitter" naturale.

In fondo questa persona e' soggetta proprio a quel tipo di disturbi impulsivi per cui il g.inp e' stato ideato, e nel sua caso fa un lavoro magnifico cosi' come lo fanno gli altri sistemi di correzione, considerando che piu' del 99% dei pacchetti arriva corrotto e viene corretto al volo.

edit: facendo un po' di conti il 99,8% dei frame arrivano corrotti al modem e vengono corretti con la Reed Solomon, mentre lo 0,07% richiede una ritrasmissione; dato che non conosco la lunghezza del buffer non sono in grado di dire quante di queste ritrasmissione coinvolgano un pacchetto icmp del ping , ne' ho idea di quante ritrasmissioni generino l'incremento di latenza, quindi si conferma come sopra detto che il ping e' uno strumento inutile.
Tuttavia la ritrasmissione toglie banda quindi la velocita' di ricezione dovrebbe calare dello ....... 0.1% , e anche qui a fare statistiche la vedo dura.

edit: ecco il suo ping test, ha del traffico p2p ma in misura ridotta:
Statistiche Ping per 88.149.202.248:
Pacchetti: Trasmessi = 4000, Ricevuti = 3940,
Persi = 60 (1% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 31ms, Medio = 14ms

questo il mio per un confronto, niente traffico, ma il route e' differente.
Ping statistics for 88.149.202.248:
Packets: Sent = 4000, Received = 3998, Lost = 2 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 17ms, Average = 15ms

[LordSilver]

Posto qui la mia esperienza per avere qualche parere: ho fatto un contratto per l'attivazione di una nuova linea verso fine giugno con il profilo 20Mega ADSL2+ inizialmente e sono in seguito passato alla 100Mega VDSL di TIM ad agosto. Avevo problemi anche con la ADSL2+ (frequenti disconnessioni, perdita pacchetti, errori CRC, ecc.), che però dopo 2 uscite e solleciti ai tecnici sono stati risolti definitivamente.

Con la fibra invece sta diventando un calvario senza fine... Nel senso che sono già arrivato al 5° ticket e ancora il mio problema non è stato risolto: la linea è continuamente instabile (perdo circa il 20% di pacchetti e ho molti errori CRC), casca sempre la connessione a causa dell'SNR appena sufficiente (intorno a 6dB di solito). I tecnici han provato di tutto: controllare la mia linea a casa (che però è perfetta), cambiare decine di volte presa negli armadi fino a mettermi in un box dedicato senza interferenze di cavi d'alta tensione o altro, ecc. Ma nel frattempo, dal 18 agosto (data di apertura dell'ultimo ticket) sono ancora senza una connessione usabile.

Quando chiamo l'assistenza fibra (1949) ogni volta mi dicono una cosa diversa: prima che è un guasto alla linea, poi che è un problema generalizzato in centrale che riguardo la mia zona, e via dicendo. E continuo così ogni giorno a inviare un sollecito, senza che la situazione cambi minimamente.

È fattibile una cosa del genere? Cosa dovrei fare? Dite che è possibile chiedere di tornare alla 20Mega senza la penale della cessazione del servizio fibra? Perché ormai ci ho perso le speranze che siano in grado di sistemare la linea.

[BarbaN3rd]

Oggi nel mio comune, completamente a sorpresa, è stato montato un ONU su un armadietto. Dico a sorpresa perché non c'era scritto da nessuna parte la programmazione di questo armadietto (e io giovedì ci ero passato davanti ed era tutto normale), o almeno non sono riuscita a trovarla nel modo corretto (nel mio comune è programmato un solo armadietto che si trova in una frazione bel lontano da questo).

Ora la domanda è questa. L'armadio al quale sono collegato è predisposto allo stesso modo di questo (con box per l'elettricità accanto installato da un pezzo), secondo voi verrà montato l'ONU a sorpresa? Dubito oggi visto che è ormai domenica, magari questa settimana?

Grazie a tutti.