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

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

[Diabolik183]

Originariamente inviato da Dark_Lord

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

Grazie per la tua risposta, era ciò che mi interessava sapere.

[ironmark99]

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.

Mi sembra di ricordare che ne discutemmo qualche tempo fa (probabilmente in PM). Era con te??

Comunque ciò che dici è vero, ma solo se si accetta esclusivamente un tasso di errore NULLO. In una trasmissione come quella VDSL un tasso di errore è implicito, e infatti si parla di SNRm, dove la "m" sta per "margine", ossia margine al tasso di errore di 1E-7 (implicito con 0dB di SNRm). Il tasso di errore diminuisce molto approssimativamente di un fattore 10 per ogni dB aggiuntivo di margine, ma non arriva mai a zero. I 6dB canonici di SNRm comunque già bastano a raggiungere un tasso di errore più che accettabile, in questa tipologia di trasmissioni, tanto è vero che tra i gamer in ADSL molti sceglievano il profilo fast (e alcuni lo sceglierebbero anche in VDSL se non gli venisse impedito ). Se anche non ci fosse il Reed-Solomon, si otterrebbero gli stessi risultati con 3dB in più di SNR minimo per portante.

Come giustamente dici tu, un conto è dover memorizzare dei dati, dove l'errore non è tollerabile, un altro è guardare un video in streaming dove uno squadrettamento al giorno può anche andare bene.

Poi ovviamente i meccanismi di protezione ci sono, vedi i vari Reed-Solomon, e INP-delay, ma di per sé trasmettere senza alcun codice di protezione dall'errore è tecnicamente possibile, accettando il compromesso di avere qualche errore ogni tanto.

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

Scusa se ti chiedo un'altra cosa, magari a te potrebbe risultare ovvia, ma il vectoring risolverebbe, almeno in parte, questo problema delle derivazioni?
Mi risponderei da solo ma non ho realmente capito in cosa consistano fisicamente queste derivazioni (ho cercato su google, e anche sul forum, ma evidentemente non abbastanza bene)

[stefanoasr]

Originariamente inviato da tuxnetwork

Nel mio paese ho 3 coppie (2 - 2 - 2) di armadi alimentate dalla 3 torrette..
Quindi la 3 torrette alimenta tranquillamente 2 armadi posso dirlo per certo...
Ero convinto anche io del contrario..

Da me non ci sono le torrette di alimentazione a più sportelli con tetto rosso, però tutti gli armadi fibrati hanno di fianco la propria palina, mentre solo alcuni hanno ANCHE l'armadietto Enel, e ancora non riesco a capire il significato di questa differenza.

[Yrbaf]

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.

Io non stavo asserendo che la correzione ci sia non ci sia.
Stavo solo riportato che secondo l'analisi di Iron il contatore dei FEC con G.Inp è il contatore delle ritrasmissioni perché la RS non ci dovrebbe essere (anche perché se i FEC sono corretti da RS, come da loro nome, la ritrasmissione non è mica avvenuta).
A maggiore ragione vista la bassa latenza (solo 4-5ms).

Diciamo che ci sono due gruppi:

- Quello che pensa che la RS ci sia e quindi G.INP ritrasmette solo i CRC o in genere gli errori non FEC
Ed il costo della RS sta nei 4-5ms

- Quello che pensa che la RS completa non ci sia (perché non computabile nei 4-5ms) e quando il protocollo FEC (alleggerito) rileva l'errore lo fa correggere non alla RS ma al G.Inp con ritrasmissione (e se fallisce pure questa al TCP o altrimenti pacchetto perso se non c'è TCP).

Io propendevo per il primo gruppo ma se Iron propende per il secondo mi mette in dubbio e non sono più molto convinto delle mie idee

PS
Post scritto senza aver ancora letto i posti di oggi di Iron

[S3lfman]

Originariamente inviato da BarbaN3rd

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

Si certo può essere. Di che zona sei visto che magari siamo vicini?

[Psyred]

Per me i FEC sono..... FEC oltretutto le ritrasmissioni hanno il loro counter indipendente (non mostrato nella GUI del Technicolor).

Anche sui forum UK danno per scontato che ci sia una protezione FEC a monte, in quanto più efficace sul rumore REIN, mentre lo SHINE è ben gestito dalla ritrasmissione.

[commandos[ita]]

Io continuo ad avere INP a 11300...ho aperto segnalazione al 1949 , mi ha contattato il reparto "configuratori" che mi ha risposto con "non so di queste cose informatiche...i profili sull'ONUCab non si possono toccare"
Fatto sta che il i2010_2 ha il range dell'INP anomalo visto che non sono l'unico utente con INP a 11300.
Non so a chi far segnalazione....
@ironmark
con INP così alto, c'è un aumento dell'overhead sulla banda giusto?

[ironmark99]

Originariamente inviato da commandos[ita]

Io continuo ad avere INP a 11300...ho aperto segnalazione al 1949 , mi ha contattato il reparto "configuratori" che mi ha risposto con "non so di queste cose informatiche...i profili sull'ONUCab non si possono toccare"
Fatto sta che il i2010_2 ha il range dell'INP anomalo visto che non sono l'unico utente con INP a 11300.
Non so a chi far segnalazione....
@ironmark
con INP così alto, c'è un aumento dell'overhead sulla banda giusto?

No, che io sappia... Poi c'è da dire che in questi giorni sul G.INP sono più le cose confuse che quelle sulle quali ho le idee chiare...

[commandos[ita]]

Originariamente inviato da ironmark99

No, che io sappia... Poi c'è da dire che in questi giorni sul G.INP sono più le cose confuse che quelle sulle quali ho le idee chiare...

Cosa cambia in termini di prestazioni/portante da un INP a 5900 a un INP a 11300?
Col 1949 mi ha provato il profilo con INP a 200 ma avevo portante inferiore e ping +13ms ad esempio...

[ironmark99]

Originariamente inviato da commandos[ita]

Cosa cambia in termini di prestazioni/portante da un INP a 5900 a un INP a 11300?
Col 1949 mi ha provato il profilo con INP a 200 ma avevo portante inferiore e ping +13ms ad esempio...

Beh, penso che il profilo con INP a 200 sia quello senza ritrasmissione (G.INP) e sia quindi il profilo interleaved, che aggiunge sia overhead pesante che ritardo costante. La differenza in termini di prestazioni tra INP 5900 e INP 13000 (che dovrebbero essere entrambi con ritrasmissione) invece dovrebbe essere minima e aggiundere un delay solo in presenza di ritrasmissioni.

[Rizzy]

Originariamente inviato da tuxnetwork

eviterei questo balzello del noleggio obbligatorio.

Vendita, dal 1 agosto e' vendita... in 48 rate, sempre obbligatoria.

Posta il riferimento che hai trovato, cosi' serve a tutti

[terlino]

Poco fa mi ha chiamto una operatrice che mi ha comunicato che c'è un aumento di costo mensile
IO ho la 3x2 a 49 mensili e per il primo anno a 39.
Possono aumentare un offerta?
Chiedendo lumi mi ha detto di contattare il 187 per offerte....
Diceva che la comuinicazione dobrebbe essere arrivata per mail ma non a tutti e per questo chiamano.
Cosa vi risulta?