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

[Marcospippoz]

Salve ragazzi, sono riuscito a scoprire la causa dei tanti errori Fec che avevo, per farla breve il connettore rj11 che entra nel modem Tim, non arriva completamente in fondo, ho fatto la prova mettendo uno stuzzicadenti come fermo, ho rifatto i test e la differenza è impressionante, adesso ho un Fec al secondo, prima ne avevo 10 al secondo.;

Ma esistono dei cavi con connettori rj11 lunghi in modo che vadano inseriti completamente senza ballarci dentro?

[papillon56]

Originariamente inviato da Marcospippoz

Salve ragazzi, sono riuscito a scoprire la causa dei tanti errori Fec che avevo, per farla breve il connettore rj11 che entra nel modem Tim, non arriva completamente in fondo, ho fatto la prova mettendo uno stuzzicadenti come fermo, ho rifatto i test e la differenza è impressionante, adesso ho un Fec al secondo, prima ne avevo 10 al secondo.;

Ma esistono dei cavi con connettori rj11 lunghi in modo che vadano inseriti completamente senza ballarci dentro?

problema gia' trattato
io ho risolto saldando il doppino in entrata ed eliminando la rj11, ma se non hai una stazione saldante puoi optare per una giunta fatta bene eliminado quindi la rj11 a muro

[giovanni69]

Originariamente inviato da Marcospippoz

.. cut.. adesso ho un Fec al secondo, prima ne avevo 10 al secondo.;

Ma esistono dei cavi con connettori rj11 lunghi in modo che vadano inseriti completamente senza ballarci dentro?

papillon56, grazie dell'idea ma al di là della soluzione saldatura/ giunto è una bella domanda in effetti.

[Yrbaf]

Originariamente inviato da Busone di Higgs

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.

Però dai discorsi di Iron mi sembrava che la RS non c'è ed i pacchetti corrotti sono sempre corretti con ritrasmissione.
Quindi se è corrotto il 99.8% dei pacchetti dovrebbero essere ritrasmessi tutti e quelli che falliscono anche in ritrasmissione fatti ritrasmettere al TCP.
Per UDP o ICMP dovrebbe pure significare pacchetto perso (se fallisce la ritrasmissione hw della vdsl).

Originariamente inviato da papillon56

problema gia' trattato
io ho risolto saldando il doppino in entrata ed eliminando la rj11, ma se non hai una stazione saldante puoi optare per una giunta fatta bene eliminado quindi la rj11 a muro

Però lui si lamenta lato modem e non penso possa saldare sul modem Tim

[S3lfman]

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

Controlla domani su fibra.click se pianificano il tuo armadio così puoi avere qualche certezza in più!

Inviato dal mio MI 5 utilizzando Tapatalk

[Dark_Lord]

Originariamente inviato da Marcospippoz

Salve ragazzi, sono riuscito a scoprire la causa dei tanti errori Fec che avevo, per farla breve il connettore rj11 che entra nel modem Tim, non arriva completamente in fondo, ho fatto la prova mettendo uno stuzzicadenti come fermo, ho rifatto i test e la differenza è impressionante, adesso ho un Fec al secondo, prima ne avevo 10 al secondo.;

Ma esistono dei cavi con connettori rj11 lunghi in modo che vadano inseriti completamente senza ballarci dentro?

magari sono solo i connettori leggermente ossidati, e spingendo la rj11 più in fondo va a fare contatto in una zona più pulita, purtroppo le correnti e le tensioni in gioco sono talmente basse che basta un nulla per degradare il segnale

[BarbaN3rd]

Originariamente inviato da S3lfman

Controlla domani su fibra.click se pianificano il tuo armadio così puoi avere qualche certezza in più!

Inviato dal mio MI 5 utilizzando Tapatalk

Può essere che il mio armadio sia pianificato da una centrale di un comune vicino al mio nonostante dove abito io ce ne sia una?


Inviato dal mio iPhone utilizzando Tapatalk

[fanfa]

Originariamente inviato da babene

Passano anche dei mesi.

Speriamo di no

Ma "tecnicamente" quali sono i prossimi passaggi necessari per arrivare all'attivazione? Altri lavori sull'armadio oppure tutto in centrale?

grazie

[Robecate]

Originariamente inviato da Yrbaf

Però dai discorsi di Iron mi sembrava che la RS non c'è ed i pacchetti corrotti sono sempre corretti con ritrasmissione.
Quindi se è corrotto il 99.8% dei pacchetti dovrebbero essere ritrasmessi tutti e quelli che falliscono anche in ritrasmissione fatti ritrasmettere al TCP.
Per UDP o ICMP dovrebbe pure significare pacchetto perso (se fallisce la ritrasmissione hw della vdsl).


Però lui si lamenta lato modem e non penso possa saldare sul modem Tim

Non mi pare possibile, sarà una RS molto migliorata rispetto a quella originale che ho studiato, ci sarà pure un algoritmo che ottimizza tutto correlandosi con l'interleaving eccetera eccetera, ma una correzione di tipo RS(x,y) cioè con una ridondanza che consente di segnalare in ogni blocco la presenza di x errori e di correggerne al volo y ci deve per forza essere sempre. la distribuzione statistica degli errori è sempre tale per cui la probabilita di più di due errori consecutivi è quasi trascurabile per cui il codice RS è teoricamente di una efficienza mostruosa in caso di disturbi "brevi". C'è in ogni situazione di trasmissione dati: letture da disco fisso, letture da cd e dvd, letture da memoria eccetera.

[Kri3g]

Ma è possibile che su questo sito http://proof.ovh.net/ mi risulti un upload di 26mbs? Che sono 3mb e rotti?

[Busone di Higgs]

Forse stai trasferendo dati comprimibili utilizzando un software che supporta la compressione onfly?
ai tempi dei modem e delle prime connessioni a internet il protocollo ppp supportava la compressione dei dati, e lo steso facevano i modem, in fondo viste le basse velocita' di allora il lavoro richiesto per la compressione era esiguo ance per quelle cpu.

[giovanni69]

Originariamente inviato da Kri3g

Ma è possibile che su questo sito http://proof.ovh.net/ mi risulti un upload di 26mbs? Che sono 3mb e rotti?

Anch'io con quel sito ho un upload che non solo supera il profilo teorico di 21.6 ma è addirittura superiore sia come valore medio (19) e sia massimo (23) rispetto a quello che è il valore reale agganciato di velocità di trasmissione in up (17) dal modem. Il download invece è più realistico.

[Busone di Higgs]

Originariamente inviato da Yrbaf

Quindi se è corrotto il 99.8% dei pacchetti dovrebbero essere ritrasmessi tutti e quelli che falliscono anche in ritrasmissione fatti ritrasmettere al TCP.

E' sempre stato tecnicamente impossibile trasmettere dati attraverso un mezzo non esente da rumore senza ricorrere ad un qualche tipo correzione degli errori.

La differenza sta nel fatto che mentre nelle trasmissioni broadcast o nella lettura di supporti di memorizzazione (nota anche anche hdd e ssd ne necessitano) si deve abbondare con i dati ridondanti, nel caso di una comunicazione bidirezionale e' possibile ridurre i dati ridondanti per incrementare le prestazioni e ritrasmettere i dati persi (o ritrasmettere anche la sola ridondanza) e in questo caso si tratta di cercare il compromesso fra overhead da trasmettere e necessita' di ritrasmissioni per avere la prestazione migliore.

In caso di trasmissioni unicast o lettura di memorie si deve abbondare perche' una mancata correzione e' un errore irreparabile , pensa a un cd con un settore illeggibile, ed ecco che i settori portano 2048 byte di dati e 128+128 di ridondanza, le trasmissioni tv 288/64/64, la Sony sui nastri video broadcast SD vent'anni fa registrava 2 volte e mezza il bitrare del video, etc.

Quanto siano proporzionati questi fattori penso li decida il provider.
Ps: smanettando sui trasmettitori video dvb asi ho trovato le impostazioni per variare tutto questi parametri a piacimento, ma se vuoi inserire il tuo canale in un pacchetto di emittenti tv terrestri non puoi mettere quello che ti pare.

Spero di aver reso il concetto, non e' proprio materia semplicissima e i numeri esatti che si usano spesso te li devi scoprire da solo.

[Robecate]

Originariamente inviato da Busone di Higgs

E' sempre stato tecnicamente impossibile trasmettere dati attraverso un mezzo non esente da rumore senza ricorrere ad un qualche tipo correzione degli errori.

La differenza sta nel fatto che mentre nelle trasmissioni broadcast o nella lettura di supporti di memorizzazione (nota anche anche hdd e ssd ne necessitano) si deve abbondare con i dati ridondanti, nel caso di una comunicazione bidirezionale e' possibile ridurre i dati ridondanti per incrementare le prestazioni e ritrasmettere i dati persi (o ritrasmettere anche la sola ridondanza) e in questo caso si tratta di cercare il compromesso fra overhead da trasmettere e necessita' di ritrasmissioni per avere la prestazione migliore.

In caso di trasmissioni unicast o lettura di memorie si deve abbondare perche' una mancata correzione e' un errore irreparabile , pensa a un cd con un settore illeggibile, ed ecco che i settori portano 2048 byte di dati e 128+128 di ridondanza, le trasmissioni tv 288/64/64, la Sony sui nastri video broadcast SD vent'anni fa registrava 2 volte e mezza il bitrare del video, etc.

Quanto siano proporzionati questi fattori penso li decida il provider.
Ps: smanettando sui trasmettitori video dvb asi ho trovato le impostazioni per variare tutto questi parametri a piacimento, ma se vuoi inserire il tuo canale in un pacchetto di emittenti tv terrestri non puoi mettere quello che ti pare.

Spero di aver reso il concetto, non e' proprio materia semplicissima e i numeri esatti che si usano spesso te li devi scoprire da solo.

Hai perfettamente ragione, lo dicevo anch'io prima, è proprio così.

[MaxFabio93]

Originariamente inviato da Kri3g

Ma è possibile che su questo sito http://proof.ovh.net/ mi risulti un upload di 26mbs? Che sono 3mb e rotti?

Server un pò sballati con i valori, l'unico migliore a parer mio resta il test di Eolo con server a Latina, anche quello nuovo di Google non è male, la qualità Ookla di Speedtest si vede

[Diabolik183]

Ragazzi, forse a settembre (spero prima visto che dovevo essere gia' attivo a luglio) sarò dei vostri.
Vorrei porre a chi è gia' "fibrato" delle domande che purtroppo, pur seguendovi da un sacco di tempo ormai, non mi capita spesso di leggere.
Com'è la navigazione in generale con la fttc? Tipo lo streaming video, ecc.... notate delle sostanziali differenze rispetto a quando eravate in adsl2+?
E per chi li usa, come si comporta la fttc con i software di assistenza remota? Si nota tanto la differenza? Scusate se posto queste domande che per voi possono essere banali ma leggo pagine e pagine di portante che cala di 1000-4000 kbps, ping e diafonia... so che quest'ultime sono cose importanti e vi ringrazio perchè, leggendovi, ho arricchito settori che per me erano sconosciuti ma vorrei (se possibile) avere delle opinioni in merito visto che il mio lavoro consiste anche nel dare teleassistenza a decine di client/server remoti, spesso simultaneamente.
Grazie e buona serata.

[Kri3g]

Originariamente inviato da MaxFabio93

Server un pò sballati con i valori, l'unico migliore a parer mio resta il test di Eolo con server a Latina, anche quello nuovo di Google non è male, la qualità Ookla di Speedtest si vede

Thanks, su quello di Eolo faccio 93.77mbs e 20.21

[Dark_Lord]

Originariamente inviato da Diabolik183

Ragazzi, forse a settembre (spero prima visto che dovevo essere gia' attivo a luglio) sarò dei vostri.
Vorrei porre a chi è gia' "fibrato" delle domande che purtroppo, pur seguendovi da un sacco di tempo ormai, non mi capita spesso di leggere.
Com'è la navigazione in generale con la fttc? Tipo lo streaming video, ecc.... notate delle sostanziali differenze rispetto a quando eravate in adsl2+?
E per chi li usa, come si comporta la fttc con i software di assistenza remota? Si nota tanto la differenza? Scusate se posto queste domande che per voi possono essere banali ma leggo pagine e pagine di portante che cala di 1000-4000 kbps, ping e diafonia... so che quest'ultime sono cose importanti e vi ringrazio perchè, leggendovi, ho arricchito settori che per me erano sconosciuti ma vorrei (se possibile) avere delle opinioni in merito visto che il mio lavoro consiste anche nel dare teleassistenza a decine di client/server remoti, spesso simultaneamente.
Grazie e buona serata.

Boh, io so solo che prima non riuscivo neanche a guardare un video in full hd su youtube senza le pause per il buffer, ora invece posso guardare un video in 4k in realtime senza neanche una pausa

miglioramenti in tutti gli utilizzi, dal gaming al semplice navigare, quindi credo che anche nell'ambito della teleassistenza sia migliore

ovviamente ping molto più bassi

per quanto riguarda la diafonia, personalmente ho da più di un mese la fibra e la portante è rimasta sempre la stessa (93.000 circa) sarà che sono circondato da vecchietti

[Busone di Higgs]

Originariamente inviato da tuxnetwork

Ho fatto un giretto e ho notato delle cose..

Le colonnine rosse a 3 quadrati possono alimentare 1 o 2 armadi
Le colonnine rosse a 4 quadrati servono quando è necessario alimentare più di 2 armadi , Confermate ?

3 scomparti un armadio, 4 scomparti 2 armadi;

poi dove stanno rimpiazzando le onu da 48 porte stanno montato un nuovo tipo di colonnina che ribattezzerei colonnone, di colore nero lucido con l'aspetto di un torpedo rivolto verso l'alto (o a detta di qualcuno di una supposta, un dildo, il serbatoio dello shuttle, ma la parte superiore e' una semisfera perfetta), sara' alto un metro.

[ironmark99]

ERRATA CORRIGE: Ieri ho scritto:
"A 100Mbit/s le DTU sono circa 700/s (ogni DTU contiene 65byte di payload più alcuni byte di overhead)."
Si tratta di un evidente errore di calcolo
65 byte + alcuni byte di overhead (supponiamo 4), tradotti in bit fa (65+4)*8=552 bit. Dunque 100Mbit/s diviso 552 bit fa un po' più di 180000 DTU/s (per far cifra tonda), e dunque il risultato di 700 DTU/s al secondo era palesemente sbagliato (non so proprio da dove mi sia uscito: sarà l'eta? ).
Ho avuto questo dubbio perché mi veniva un overhead per la ritrasmissione decisamente troppo alto. Comunque rileggendo la G.INP per chiarirmi le idee mi sono anche accorto che mi era sfuggito (pure!! ) il fatto che una DTU può contenere anche un numero superiore di byte, purché multiplo di 65 (per diminuire l'impatto dei byte di overhead, probabilmente). Questo giusto per la precisione.

Originariamente inviato da Yrbaf

Però dai discorsi di Iron mi sembrava che la RS non c'è ed i pacchetti corrotti sono sempre corretti con ritrasmissione.
Quindi se è corrotto il 99.8% dei pacchetti dovrebbero essere ritrasmessi tutti e quelli che falliscono anche in ritrasmissione fatti ritrasmettere al TCP.
Per UDP o ICMP dovrebbe pure significare pacchetto perso (se fallisce la ritrasmissione hw della vdsl).

Originariamente inviato da Robecate

Non mi pare possibile, sarà una RS molto migliorata rispetto a quella originale che ho studiato, ci sarà pure un algoritmo che ottimizza tutto correlandosi con l'interleaving eccetera eccetera, ma una correzione di tipo RS(x,y) cioè con una ridondanza che consente di segnalare in ogni blocco la presenza di x errori e di correggerne al volo y ci deve per forza essere sempre. la distribuzione statistica degli errori è sempre tale per cui la probabilita di più di due errori consecutivi è quasi trascurabile per cui il codice RS è teoricamente di una efficienza mostruosa in caso di disturbi "brevi". C'è in ogni situazione di trasmissione dati: letture da disco fisso, letture da cd e dvd, letture da memoria eccetera.

Aspe'... Forse dobbiamo intenderci sui termini. Un Reed-Solomon coding c'è sempre, e contribuisce a stabilire il minimo SNR per poter assegnare almeno 1 bit ad una portante. È un elemento che già da solo dà un bel contributo di correzione (circa 3 dB di guadagno sull'SNR minimo) e aggiunge anche un certo overhead (che sinceramente ora non ricordo) ma che è già annegato nella differenza tra 4.3125 kbit/s al bit x portante di data rate lordo ai 4kbit/s al bit x portante di data rate netto. Tuttavia non credo che le correzioni dovute a questo Reed-Solomon coding appaiano nel conteggio dei FEC, dato che già fanno parte della struttura di framing.

Quello che può esserci o non esserci è il meccanismo di INP-delay che aggiunge un overhead elevato, e cosa più importante FISSO, che ci siano errori o che non ci siano. L'overhead legato a questo meccanismo è:

2xINP/(4000xdelay)

dunque un INP 1 sui canonici 4ms di delay dà un overhead di

2x1/(4000x4x10^-3)= 2/16 =1/8

ossia il 12.5%, che su 100Mbit/s significano 12.5Mbit/s per correggere 1 simbolo errato ogni 4 millisecondi, cioè 250 errori al secondo max, a patto che arrivino equispaziati (come a causa di un REIN), altrimenti la correzione fallisce. Il contatore dei FEC indica (secondo me) solo questi errori, il conteggio dei quali si ricava sempre da un codice di ridondanza ciclica (CRC) applicato al data rete netto (ossia l'ottenibile). Il conteggio dei CRC che appare nelle statistiche del modem (sempre secondo me) è quello dei CRC residui DOPO la correzione (dato non avrebbe molto senso mostrare dei CRC se questi venissero corretti poi dalle ritrasmissioni!).

Questo meccanismo si basa anche lui su un Reed-Solomon coding (è questo che non dovrebbe eserci con il G.INP) per ricavare dai pochi simboli aggiunti (nell'esempio aggiunge 2 simboli ogni 16) per correggere QUALUNQUE simbolo dei 16 ricevuti.

Facendo un conto a spanne, con la ritrasmissione e con 12.5Mbit sottratti al bearer0 e usati dal bearer1, anche calcolando un overhead di 4/65, si riuscirebbero a reinviare più di 11.5Mbit/s di correzioni, comunque arrivino gli errori, contro il Mbit/s (sottoposto a vincolo di non più di un simbolo errato ogni 16) che è in grado di correggere il meccanismo INP-delay (1 simbolo ogni 4ms, ossia 4000 bit 250 volte al secondo). Anche con questo rate di errori sembrerebbe ancora molto conveniente usare la ritrasmissione, e fatico a vedere la convenienza di passare a INP-delay anche con un REIN pesante. A questo punto mi sa che c'è qualcosa che ci sfugge... Se mi capita dovrò fare una chiacchierata con chi ne capisce più di me.