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

[Silent killer]

ma riavviate staccando la corrente al router?

[DYNAMIC+]

Originariamente inviato da Silent killer

ma riavviate staccando la corrente al router?

eh si,
quando l'interfaccia non risponde (praticamente si riavvia per questo) non c'è altro modo!

[diaretto]

Basta usare il tasto dietro....

[enzu89]

Dopo quasi 5 mesi !! 😉 👍🏼






Inviato dal mio iPhone utilizzando Tapatalk

[Cr4z33]

Originariamente inviato da ironmark99

No, ovviamente senza il Run-time engine non funziona!

Però sei il primo, su centinaia di installazioni, a cui è successa una cosa simile.
Ho anche appena provato a scaricare l'installer e eseguirlo su una macchina (virtuale) pulita, e funziona perfettamente.

Che versione di Windows hai? Hai unzippato in una dir qualunque il file .zip scaricato prima di lanciare il setup.exe?

Prova magari a riscaricare l'installer, non vorrei che non fosse andato a buon fine il download. Fammi sapere.

Windows 10 Pro 64 bit e l'unica protezione attiva è Kasperky Anti-Virus 2016.
Lo scompattamento con WinRAR non ha dato errori, ma ho scoperto adesso che succede perché non ho voluto disattivare il "Fast Start" di Windows (e francamente non voglio farne a meno).
Grazie comunque per il supporto.

[Cr4z33]

Originariamente inviato da diaretto

Basta usare il tasto dietro....

Sì OK, ma che ciofega è?

[baron]

Originariamente inviato da Cr4z33

Sì OK, ma che ciofega è?

[MiloZ]

Originariamente inviato da giovanni69

Guardate un po' stamattina cosa mi ritrovo con la pioggia: quasi 7 db disponibili in US, guadagna 1dB SNR eppure il modem non li sfrutta per cercare agganciare di più ma si ferma a 2Mbit in meno rispetto al bel tempo. Attenuazione US sempre a 2.8 dB.

Nell'unità di tempo durante la prova con i giorni di sole ho avuto anche più FEC, pure SES. 3:1 i CRC.



Il tutto con la RJ11 NMU705813. FW fibra 5.3.1.

Possibile che sia il modem fibra pigro (ed usato quando il tecnico me l'ha installato, non nuovo) nell'agganciare l'US e non sfrutti al meglio SRA?!

Prendendo il primo screen non riesco a capire come possano esserci 27 ES \ 10 SES e 3 CRC. In teoria non è possibile che gli ES ed i SES siano maggiori dei CRC. O è un bug nella rilevazione degli errori oppure c'è qualcos'altro che non quadra.
Tra l'altro non è la pima volta che mi capita di vedere il Technicolor mostrare una situazione anomala come questa relativamente agli errori di linea.
Per curiosità: in entrambi i casi in cui hai scattato gli screenshot, lo SRA era già intervenuto almeno una volta per rimodulare la portante o no?

[diaretto]

Originariamente inviato da Cr4z33

Sì OK, ma che ciofega è?

Certo perchè la ciofeca di VF che manco ti fa vedere i valori è molto meglio?

Non c'è da difendere nessuno, basta guardare le cose in modo obiettivo!

[maverikkk86]

ma oggi sciopero dei file aggiornati?

[commandos[ita]]

Originariamente inviato da maverikkk86

ma oggi sciopero dei file aggiornati?

chi si occupa della pianificazione avrà fatto un 1 maggio allungato

[LamerTex]

Originariamente inviato da MiloZ

Prendendo il primo screen non riesco a capire come possano esserci 27 ES \ 10 SES e 3 CRC. In teoria non è possibile che gli ES ed i SES siano maggiori dei CRC. O è un bug nella rilevazione degli errori oppure c'è qualcos'altro che non quadra.
Tra l'altro non è la pima volta che mi capita di vedere il Technicolor mostrare una situazione anomala come questa relativamente agli errori di linea.
Per curiosità: in entrambi i casi in cui hai scattato gli screenshot, lo SRA era già intervenuto almeno una volta per rimodulare la portante o no?

Semplicemente i FEC e i CRC si azzerano quando cade e viene ripresa la portante come succede per l'uptime, mentre gli ES e i SES non vengono azzerati, quindi ci sono questi casi che in teoria non dovrebbero esistere

[commandos[ita]]

Non so se avete notato ma da tipo stamattina
su http://www.impresasemplice.it/verifica-copertura

Stiamo aggiornando il servizio di verifica copertura.
Il servizio è momentaneamente sospeso.

Chissà...forse per questo stanno tardando i files

[alanfibra]

Originariamente inviato da Silent killer

ma riavviate staccando la corrente al router?

Io utilizzo l'interruttore sul retro.

[kbios]

Originariamente inviato da ironmark99

Grazie, sei troppo buono...

(Grazie molte anche per il "ragazzo"... Magari!!! )

Iron, mi è sorto un dubbio puramente teorico (probabilmente mi manca qualcosa riguardo a ciò che so sul DMT): se ho capito bene in vdsl (17a) ognuna delle 4095 portanti, spaziate di 4.3125 khz, ha un symbol rate costante di 4000/s. Da questo dovrebbe seguire che per esempio la portante centrata sui 25khz ha ogni simbolo mantenuto per poco più di 6 oscillazioni, quindi appena abbastanza per essere riconosciuto. Ma se consideriamo la portante centrata sui 17Mhz, ogni simbolo viene mantenuto per addirittura 17M/4000=4250 oscillazioni giusto? Intuitivamente non sarebbe possibile aumentare il symbol rate linearmente con la frequenza della rispettiva portante in modo da mantenere costante il numero di oscillazioni per simbolo (e aumentare il bitrate disponibile)? Grazie mille

[MiloZ]

Originariamente inviato da LamerTex

Semplicemente i FEC e i CRC si azzerano quando cade e viene ripresa la portante come succede per l'uptime, mentre gli ES e i SES non vengono azzerati, quindi ci sono questi casi che in teoria non dovrebbero esistere

Ah non si azzero gli ES\SES? Pardon, non lo sapevo dato che non accendo il Technicolor da tempo immemore. Allora tutto ok.

[giovanni69]

Originariamente inviato da MiloZ

Prendendo il primo screen non riesco a capire come possano esserci 27 ES \ 10 SES e 3 CRC. In teoria non è possibile che gli ES ed i SES siano maggiori dei CRC. O è un bug nella rilevazione degli errori oppure c'è qualcos'altro che non quadra.
Tra l'altro non è la pima volta che mi capita di vedere il Technicolor mostrare una situazione anomala come questa relativamente agli errori di linea.
Per curiosità: in entrambi i casi in cui hai scattato gli screenshot, lo SRA era già intervenuto almeno una volta per rimodulare la portante o no?

Grazie molte per il tuo intervento, Miloz!

Non capisco bene la tua domanda, ma temo di no... infatti quello che ti posso già mostrare dopo altre 6 ore ho registrato alle 17 di oggi (rispetto al grafico PIOGGIA) la seguente immagine in cui si vede che SNR UP è migliorato ancora da 6.9 a 7.3db (a parità di ogni altra condizione) mentre non è stata rimodulata alcuna portante, se è quello che intendevi. Nulla del ripristino del SNR in UP viene convertito in miglioramento dell'US. E nel frattempo è uscito il sole da un paio d'ore...



In generale non ho mai visto una modulazione SRA intervenire nel corso del tra un giorno e l'altro anche se di fatto alle 23 di ieri sera prima che iniziasse la pioggia i valori di portante DS/US erano comparabili al grafico SOLE a sx.
Quindi poi qualche evento è accaduto che ha tagliato la portante, come accennato in un precedente post da ironmark. Ed ora non si torna più al punto di prima.

[fk0]

Originariamente inviato da kbios

Iron, mi è sorto un dubbio puramente teorico (probabilmente mi manca qualcosa riguardo a ciò che so sul DMT): se ho capito bene in vdsl (17a) ognuna delle 4095 portanti, spaziate di 4.3125 khz, ha un symbol rate costante di 4000/s. Da questo dovrebbe seguire che per esempio la portante centrata sui 25khz ha ogni simbolo mantenuto per poco più di 6 oscillazioni, quindi appena abbastanza per essere riconosciuto. Ma se consideriamo la portante centrata sui 17Mhz, ogni simbolo viene mantenuto per addirittura 17M/4000=4250 oscillazioni giusto? Intuitivamente non sarebbe possibile aumentare il symbol rate linearmente con la frequenza della rispettiva portante in modo da mantenere costante il numero di oscillazioni per simbolo (e aumentare il bitrate disponibile)? Grazie mille

se aumenti il symbol rate aumenti anche lo spettro occupato;
piu' symbol rate, piu' spettro necessario, uguale quantita' di dati trasportati, e se sali di molto subisci i danni per la differente attenuazione alle varie frequenze; non scendo nei dettagli perche' e' lunga.

[CrustyDemon]

Originariamente inviato da giovanni69

Grazie molte per il tuo intervento, Miloz!

Non capisco bene la tua domanda, ma temo di no... infatti quello che ti posso già mostrare dopo altre 6 ore ho registrato alle 17 di oggi (rispetto al grafico PIOGGIA) la seguente immagine in cui si vede che SNR UP è migliorato ancora da 6.9 a 7.3db (a parità di ogni altra condizione) mentre non è stata rimodulata alcuna portante, se è quello che intendevi. Nulla del ripristino del SNR in UP viene convertito in miglioramento dell'US. E nel frattempo è uscito il sole da un paio d'ore...



In generale non ho mai visto una modulazione SRA intervenire nel corso del tra un giorno e l'altro anche se di fatto alle 23 di ieri sera prima che iniziasse la pioggia i valori di portante DS/US erano comparabili al grafico SOLE a sx.
Quindi poi qualche evento è accaduto che ha tagliato la portante, come accennato in un precedente post da ironmark. Ed ora non si torna più al punto di prima.

ma come mai non becchi UP a 20

[MiloZ]

Originariamente inviato da giovanni69

Grazie molte per il tuo intervento, Miloz!

Non capisco bene la tua domanda...ma quello che ti posso già mostrare dopo altre 6 ore registrato alle 17 di oggi (rispetto al grafico PIOGGIA) è la seguente immagine in cui si vede che SNR UP è migliorato da 6.9 a 7.3db ancora mentre non è stata rimodulata alcuna portante, se è quello che intendevi. Nulla del ripristino del SNR in UP viene convertito in miglioramento dell'US. E nel frattempo è uscito il sole da un paio d'ore...

Riguardo il discorso degli errori credo che abbia già chiarito LamerTex, cioè se non si azzerano gli ES\SES quando la linea si disconnette, è normale che il contatore possa risultare più alto dei CRC.
Ti chiedevo dello SRA perchè io ho notato dei comportamenti piuttosto strani quando interviene per rimodulare la portante (provando su 4 modem con chipset broadcom).

Nello specifico succede che in TUTTI i modem la latenza, se eventualmente era aumentata dei fatidici 3\4ms per via del G.INP, ritorna al minimo sul gateway (tipo 4\5ms) e così rimane per sempre senza risalire più, fino a che non viene riavviato il modem o risincronizzata la portante.
Su alcuni modem soltanto (sempre con chipset broadcom), oltre a questo fatto della latenza che si riabbassa, succede anche un'altra cosa contestualmente: appena rimodulata la portante in downstream iniziano ad aumentare i FEC in downstream all'infinito senza senso, fino a superare il miliardo dopo una giornata, e la situazione continua cosi perennemente fino a quando non viene riavviato il modem o risincronizzata la portante.

L'impressione che ho avuto è che l'intervento dello SRA vada ad "impallare" qualcosa nel buffer della ritrasmissione , ma non ho idea di come mai avvenga ciò, nè se la cosa succeda anche su ONU diversi.

Di certo il ping non si riabbassa a causa del fatto che la portante diminuisce di 1-2mbit e quindi magari ci sono meno ritrasmissioni, dato che se riavvio subito il modem riagganciando un bitrate analogo, dopo qualche minuto di connessione la latenza si è già rialzata nuovamente di 3\4ms, mentre senza riavviare rimane bassa fissa.
E' proprio lo SRA che produce qualche effetto, non saprei se positivo da questo punto di vista.