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

[fanfa]

Ciao,
questa settimana hanno montato il DSLAM sopra l'unico armadio che c'è vicino a casa mia, secondo voi quanto tempo passerà prima di poter attivare la fibra? Sui vari fogli xls della telecom ancora non ho trovato niente

Poi una curiosità: è possibile che a quell'armadio sia collegata tutta la mia zona (una decina di condomini per un totale di circa 150 appartamenti)?

Grazie

[totocrista]

Originariamente inviato da fanfa

Ciao,
questa settimana hanno montato il DSLAM sopra l'unico armadio che c'è vicino a casa mia, secondo voi quanto tempo passerà prima di poter attivare la fibra? Sui vari fogli xls della telecom ancora non ho trovato niente

Poi una curiosità: è possibile che a quell'armadio sia collegata tutta la mia zona (una decina di condomini per un totale di circa 150 appartamenti)?

Grazie

Un armadio di norma può arrivare anche a 400 utenze. Se non tutte una buona parte si rifarà a quell'armadio.

[babene]

Originariamente inviato da fanfa

Ciao,
questa settimana hanno montato il DSLAM sopra l'unico armadio che c'è vicino a casa mia, secondo voi quanto tempo passerà prima di poter attivare la fibra? Sui vari fogli xls della telecom ancora non ho trovato niente

Poi una curiosità: è possibile che a quell'armadio sia collegata tutta la mia zona (una decina di condomini per un totale di circa 150 appartamenti)?

Grazie

Passano anche dei mesi.

[Abbott]

Originariamente inviato da fanfa

Ciao,
questa settimana hanno montato il DSLAM sopra l'unico armadio che c'è vicino a casa mia, secondo voi quanto tempo passerà prima di poter attivare la fibra? Sui vari fogli xls della telecom ancora non ho trovato niente

Poi una curiosità: è possibile che a quell'armadio sia collegata tutta la mia zona (una decina di condomini per un totale di circa 150 appartamenti)?

Grazie

Sul mio armadio è stato montato a inizio luglio e ad oggi l'attivazione è prevista ad ottobre.

[giovanni69]

Originariamente inviato da Barrys

...
50 mega in downstream per me sarebbe ok, è l'upload che lo vorrei a 20...

Originariamente inviato da diaretto

... cut

Secondo me 50Mb in down li hai tranquillamente, anche di più, dipende da varie cose.

Anche i 20Mb in up secondo me potrebbero essere fattibili, anche in questo caso però dipende da varie cose, magari sono 17Mb e non 20, non si può dire con sicurezza finchè non attacchi la linea e vedi.

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

[Barrys]

Originariamente inviato da diaretto

Mah sai non so a 250m con derivazioni quanti bit sulle portanti del 35b potrebbero essere assegnati, senza contare il fatto che il 35b estende solo lo spettro in DL e non quello in UL.

Secondo me 50Mb in down li hai tranquillamente, anche di più, dipende da varie cose.

Anche i 20Mb in up secondo me potrebbero essere fattibili, anche in questo caso però dipende da varie cose, magari sono 17Mb e non 20, non si può dire con sicurezza finchè non attacchi la linea e vedi.

ah ok grazie mille, allora così mi andrebbe da dio

[ironmark99]

Originariamente inviato da 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).

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.

[MarcoKK]

Originariamente inviato da 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

Pur avendo la vula Tiscali vi seguo davvero con interesse, grazie per il vostro impegno e precisione ....

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