TIM FTTC, lentezza atroce da qualche giorno

mariomario · 2024-07-10T21:29:43+00:00

Ho una connessione TIM FTTC attiva dalla notte dei tempi, 200 Mbit nominali con allineamento a 60 Mbit in downstream e 18 in up. Da qualche giorno ho notato...

mariomario

gandalf2016

Assolutamente nessuna variazione o modifica. Queste sono le statistiche del Tim Hub:

Queste le statistiche di un rapido test su packetlosstest.com, server in Germania e dimensione dei pacchetti massima (2440 e 2456 Byte):

E per finire, uno speed test notturno a caso (ho volutamente lasciato il grafico con l'andamento delle velocità):

TheMarsican

In teoria ricado in una zona "grigio/nera", ma ad oggi al mio civico è attivo un solo operatore con "Banda Ultralarga - 30Mbit/s -100Mbit/s - FTTC - Rame". Il sito di Infratel da rete TIM non riesco neppure ad aprirlo, dopo vari minuti di attesa, invece da connessione mobile Fastweb (che è sempre un MVNO appogiato a TIM..) funziona regolarmente. Niente tracciato purtroppo.

Certo che è un bell'enigma, questo problema..

TheMarsican

mariomario In teoria ricado in una zona "grigio/nera", ma ad oggi al mio civico è attivo un solo operatore con "Banda Ultralarga - 30Mbit/s -100Mbit/s - FTTC - Rame".

Ti dice "intervento privato" o "intervento pubblico piano Italia 1G”?

Se intervento privato dovrai aspettare che nei prossimi tempi/anni Fibercop ti copra tramite suoi investimenti privati.

Se Piano Italia 1G entro il 2026 avrai FTTH tramite bando pubblico Piano Italia 1G (già in realizzazione e si possono avere alcune info)

Se vuoi avere altre info riguardante questa questione nel caso apri una nuova discussione così non andiamo off topic qui😊

Per il resto ti lascio a consigli di più esperti!

MiloZ

mariomario Assolutamente nessuna variazione o modifica. Queste sono le statistiche del Tim Hub:

Non sono quelle le statistiche che chiedeva gandalf2016 , devi cercare una schermata tipo questa: https://i.fibra.click/2019/08/1566726739_1312_0.jpg

gandalf2016

mariomario
Il packetloss probabilmente lo vedi appena la linea incomncia a fare un po’ di traffico, per quello non viene rilevato dai tool normali che lo misurano a linea scarica

Ome suggerito da Miloz, servono le statistiche xDSL
Se il problema non è lì, si sposta sulla rete TIM e devono risolvere loro. Se c’è un ticket aperto comunque prima o poi ne verranno a capo.

Sul cambiare gestore è da capire:
1) Se hai gestori in VULA
2) su che tratta tim è il peoblema, Se è a tra cabinet e olt ti rimane.
Io, molto a sentimento, tnederei a dirti che se non è nelle tratta utene-casa è in quello che collega la tua centrale a quella più grande (detto molto semplicemente).

Aspetterei la gestione del ticket da TIM.
Prova a vedere se altri in zona hanno il tuo stesso problema.
PS:mattina presto e sera stesso problema ? È una città che si popola di turisti d’estate?

handymenny

gandalf2016 ul perché alcuni server vadano ed altri no la rispsora è bbr, hai una connessione con una moderata perdita di pacchetti e quelli sono gli effetti: tcp rallenta di molto, tranne sui server che adottano come congestion control bbr

Aggiungerei che sicuramente anche la latenza incide, con un uplink così problematico

@mariomario so che può essere noioso e un po' fastidioso, ma senti bene.
Prima cosa mettici una benda sopra , ignora il risultato in download. Fin quando non vedi 10Mbps in upload hai un gravissimo problema sulla tua linea. Quindi dai tuoi test direi che il gravissimo problema è indipendente da tipo di traffico e destinazione.

Ora per portare a un risultato così disastroso ci possono essere tantissime cause, te ne elenco alcune:

Device finali. Puoi sincerarti che non sia colpa loro, scollegando tutti i device dalla tua rete, connettendone uno per volta sia via cavo che via wifi (se possibile) e facendo i test. Se almeno due hanno il problema e lo riscontri sia via cavo che wifi, sicuramente non sono i device finali il problema.
Router/Modem guasto. Per questo non c'è alternativa, dovresti prenderne un altro e sostituirlo temporaneamente. Se non ne hai o non ne puoi chiederne in prestito, su ebay ne trovi di più che validi anche sotto i 20€, chiaramente è tua la scelta se ne valga la pena.
Tratta rame tra modem e ONUcab/ARL (l'armadietto in strada). Se fosse quello il problema dovresti vedere valori di attenuazione anomali, variazioni significative della portante durante il giorno o tanti errori CRC (più di 15 al minuto sono un grosso problema).
Porta dslam rotta (nell'onucab, in armadio). Qui non c'è molto che puoi fare, dovresti convincere TIM a fare un reset della porta o a provare a cambiarla.
Uplink del dslam "guasto". Questa è facile, se fosse quello parte del vicinato avrebbe lo stesso problema, cerca se hai vicini in FTTC con lo stesso problema di uplink inferiore a 5-10Mbps.
Uplink della centrale "guasto". Questo è ancora più facile, parte del comune (se non tutto) con FTTC TIM avrebbe lo stesso problema, quindi come sopra cerca tra vicini/conoscenti.

00db

handymenny

Aggiungi areazione onu in blocco.

Rete garr tutto ok. Per favore fatemi dormire notti tranquille.

Aperock

Scusate se mi intrometto. Io punterei il dito su device connessi che stanno generando eccessive connessioni in up. Non tanto come volume dati (lo storico in 11 ore non mostrava troppi Mb scambiati) ma come quantità. Dice che lo stesso Nemesys rileva traffico anomalo (fantasma) e quindi non completa la misurazione. Se saturi l'up con richieste di connessione, anche se non vanno a buon fine e non generano realmente traffico, il download può risentirne... mi era successo una cosa simile con Emule perchè avevo messo un numero eccessivo di connessioni massime e il download si era ridotto drasticamente.

mariomario

Aperock

Punti il dito proprio su quello che avevo già escluso in prima istanza. Tutti i test sono stati effettuati dagli unici device di volta in volta collegati direttamente al router via cavo e escludo categoricamente vi siano processi in background che possano generare traffico anomalo.

mariomario

Nella serata di ieri la situazione sembrava leggermente migliorata: non ho avuto tempo di effettuare test approfonditi, ma verso server TIM almeno raggiungevo i 10 MBit in upload), ma nella notte il problema è tornato tale e quale.

Noto che a fronte di un traffico in upload notevolmente inferiore (com'è naturalmente di norma) a quello in down, il numero di FEC è in proporzione enormemente più alto.

La situazione tuttavia lato connettività verso altri ISP mi sembra anzi peggiorata, dato che non riesco ad esempio neppure a raggiungere Iliad e Lepida. Da traceroute sembrerebbe tutto ok, ma da browser è praticamente impossibile accedere ai relativi siti, dato che ogni tentativo finisce in timeout.

Hadx

mariomario numero di FEC è in proporzione enormemente più alto

I tuoi FEC (se ti riferisci all’immagine postata) sono pressoché assenti (possono iniziare ad essere problematici quando diventano milioni al giorno), in generale la linea dal punto di vista fisico è pressoché perfetta per quello che si può vedere da ciò che hai postato.

mariomario

Ho effettuato qualche altra prova, con risultati che mi lasciano davvero perplesso. Indico il sommario e poi i singoli test, consistenti nel download di un file di 14.73M, di dimensioni adeguate per valutare la velocità senza attese troppo prolungate. Ho effettuato tali download da una workstation connessa via cavo al Tim Hub senza nessun altro (sottolineo "nessun altro") device collegato. I risultati sono consistenti anche ripetendo la singola prova.

1) ftp.at.debian.org (76.9 KB/s)
2) ftp.be.debian.org (85.9 KB/s)
3) ftp.de.debian.org (54.1 KB/s)
4) ftp.it.debian.org (159 KB/s)
5) ftp.fr.debian.org (71.4 KB/s)
6) ftp.fi.debian.org (3.24 MB/s)
7) ftp.dk.debian.org (4.48 MB/s)
8) ftp.pl.debian.org (Giving up)

1) ftp.at.debian.org (76.9 KB/s)
http://ftp.at.debian.org/debian/ls-lR.gz
Resolving ftp.at.debian.org (ftp.at.debian.org)... 213.129.232.18, 2001:858:2:1::10
100%[=>] 14.73M 76.9KB/s in 3m 50s

Traccia instradamento verso debian.sil.at [213.129.232.18]
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 7 ms 8 ms 172.18.48.144
4 8 ms 8 ms 9 ms 172.18.48.178
5 11 ms 10 ms 10 ms 172.19.184.96
6 16 ms 15 ms 15 ms 172.19.177.18
7 15 ms 15 ms 14 ms 195.22.196.170
8 17 ms 17 ms 16 ms 195.22.212.149
9 16 ms 16 ms 16 ms 80.150.168.132
10 35 ms 35 ms 35 ms vie-sb5-i.VIE.AT.NET.DTAG.DE [217.239.49.98]
11 36 ms 36 ms 36 ms 80.157.201.201
12 37 ms 37 ms 37 ms c72wsued4-gi0-1.net.uta.at [212.152.193.178]
13 39 ms 39 ms 39 ms debian.sil.at [213.129.232.18]

2) ftp.be.debian.org (85.9 KB/s)
http://ftp.be.debian.org/debian/ls-lR.gz
Resolving ftp.be.debian.org (ftp.be.debian.org)... 195.234.45.114, 2a05:7300:0:100:195:234:45:114
100%[=>] 14.73M 85.9KB/s in 3m 31s

Traccia instradamento verso mirror.as35701.net [195.234.45.114]
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 8 ms 8 ms 172.18.48.148
4 8 ms 8 ms 8 ms 172.18.48.188
5 12 ms 12 ms 13 ms 172.19.184.102
6 14 ms 13 ms 17 ms 172.19.177.26
7 17 ms 16 ms 15 ms 195.22.205.98
8 30 ms 29 ms 30 ms 195.22.210.120
9 29 ms 28 ms 29 ms 213.144.168.33
10 34 ms 34 ms 34 ms edg01.lcldg.bra.be.verixi.net [62.112.29.168]
11 35 ms 35 ms 35 ms edg01.intx1.bra.be.verixi.net [87.238.225.4]
12 35 ms 35 ms 35 ms as35701.edg01.intx1.bra.be.verixi.net [62.112.29.75]
13 37 ms 38 ms 38 ms vl10.access-01.bru.as35701.net [195.234.45.44]
14 35 ms 36 ms 36 ms mirror.as35701.net [195.234.45.114]

3) ftp.de.debian.org (54.1 KB/s)
http://ftp.de.debian.org/debian/ls-lR.gz
Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
100%[=>] 14.73M 54.1KB/s in 5m 18s

Traccia instradamento verso ftp.de.debian.org [141.76.2.4]
1 <1 ms <1 ms 1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 7 ms 8 ms 172.18.48.148
4 9 ms 8 ms 8 ms 172.18.48.182
5 12 ms 12 ms 12 ms 172.19.184.98
6 17 ms 16 ms 16 ms 172.19.177.16
7 15 ms 14 ms 15 ms 195.22.205.116
8 15 ms 15 ms 15 ms 195.22.196.71
9 17 ms 16 ms 17 ms ae-5.edge1.Milan1.Level3.net [4.68.73.37]
10 33 ms 37 ms 33 ms ae1.3122.edge9.frf1.neo.colt.net [171.75.10.131]
11 39 ms 39 ms 39 ms VEREIN-ZUR.edge9.Frankfurt1.Level3.net [62.67.67.154]
12 35 ms 35 ms 34 ms cr-han2-be6.x-win.dfn.de [188.1.144.134]
13 38 ms 38 ms 38 ms cr-tub2-be9.x-win.dfn.de [188.1.144.138]
14 40 ms 40 ms 40 ms kr-dre151-0.x-win.dfn.de [188.1.243.30]
15 41 ms 41 ms 41 ms 141.76.0.31
16 46 ms 45 ms 45 ms 141.30.1.22
17 53 ms 53 ms 52 ms 141.30.2.138
18 53 ms 52 ms 54 ms debian.inf.tu-dresden.de [141.76.2.4]

4) ftp.it.debian.org (159 KB/s)
http://ftp.it.debian.org/debian/ls-lR.gz
Resolving ftp.it.debian.org (ftp.it.debian.org)... 85.94.199.210, 2001:4b78:2000:1::1
100%[=>] 14.73M 159KB/s in 2m 4s

Traccia instradamento verso 85.94.199.210 su un massimo di 30 punti di passaggio
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 8 ms 8 ms 172.18.48.148
4 17 ms 16 ms 16 ms 172.18.48.182
5 15 ms 15 ms 15 ms 172.19.184.96
6 17 ms 16 ms 15 ms 172.19.177.80
7 14 ms 14 ms 14 ms 172.19.177.25
8 14 ms 14 ms 13 ms 172.17.18.171
9 20 ms 14 ms 14 ms host-31-199-18-30.business.telecomitalia.it [31.199.18.30]
10 14 ms 14 ms 13 ms 85.94.199.210

5) ftp.fr.debian.org (71.4 KB/s)
http://ftp.fr.debian.org/debian/ls-lR.gz
Resolving ftp.fr.debian.org (ftp.fr.debian.org)... 212.27.32.66, 2a01:e0c:1:1598::2
100%[=>] 14.72M 71.4KB/s in 3m 28s

Traccia instradamento verso debian.proxad.net [212.27.32.66]
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 8 ms 7 ms 172.18.48.148
4 8 ms 8 ms 9 ms 172.18.48.188
5 10 ms 10 ms 10 ms 172.19.184.100
6 17 ms 18 ms 17 ms 172.19.177.76
7 15 ms 15 ms 15 ms 195.22.196.170
8 32 ms 33 ms 32 ms 195.22.196.137
9 * * * Richiesta scaduta.
10 37 ms 38 ms 37 ms be2800.ccr42.par01.atlas.cogentco.com [154.54.58.238]
11 38 ms 38 ms 38 ms be3184.ccr31.par04.atlas.cogentco.com [154.54.38.158]
12 37 ms 37 ms 37 ms iliad.demarc.cogentco.com [149.11.175.170]
13 36 ms 36 ms 36 ms p19-6k-2-v918.intf.nra.proxad.net [78.254.254.166]
14 38 ms 38 ms 38 ms bzn-9k-2-sys-be2001.intf.routers.proxad.net [194.149.161.246]
15 37 ms 36 ms 37 ms debian.proxad.net [212.27.32.66]

6) ftp.fi.debian.org (3.24 MB/s)
http://ftp.fi.debian.org/debian/ls-lR.gz
Resolving ftp.fi.debian.org (ftp.fi.debian.org)... 194.71.11.173, 194.71.11.163, 194.71.11.165, ...
Location: http://saimei.ftp.acc.umu.se/debian/ls-lR.gz [following]
Resolving saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)... 194.71.11.138, 2001:6b0:19::138
100%[=>] 14.73M 3.24MB/s in 5.8s

Traccia instradamento verso saimei.ftp.acc.umu.se [194.71.11.138]
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 8 ms 8 ms 172.18.48.148
4 8 ms 8 ms 8 ms 172.18.48.188
5 12 ms 12 ms 12 ms 172.19.184.102
6 13 ms 13 ms 14 ms 172.19.177.26
7 16 ms 15 ms 16 ms 195.22.192.144
8 42 ms 36 ms 36 ms 185.100.113.147
9 42 ms 35 ms 47 ms nl-ams.nordu.net [80.249.209.203]
10 42 ms 42 ms 59 ms dk-esbj.nordu.net [109.105.97.74]
11 51 ms 46 ms 87 ms dk-bal2.nordu.net [109.105.102.2]
12 49 ms 49 ms 49 ms lnd88-r1.sunet.se [109.105.102.3]
13 51 ms 51 ms 51 ms vaxjo-vxj-r11.sunet.se [86.104.202.109]
14 50 ms 51 ms 50 ms jonkoping-jkg-r11.sunet.se [86.104.202.54]
15 57 ms 57 ms 57 ms linkoping-lin3-r11.sunet.se [86.104.202.57]
16 56 ms 56 ms 55 ms norrkoping-nkg188-r11.sunet.se [86.104.202.97]
17 57 ms 56 ms 56 ms stockholm-tug-r12.sunet.se [86.104.203.67]
18 57 ms 57 ms 57 ms stockholm-tug-r11.sunet.se [86.104.202.140]
19 59 ms 59 ms 59 ms uppsala-upa-r11.sunet.se [86.104.202.143]
20 58 ms 58 ms 58 ms gavle-sbo-r11.sunet.se [86.104.202.16]
21 61 ms 60 ms 61 ms sundsvall-sva-r11.sunet.se [86.104.202.19]
22 62 ms 62 ms 62 ms umea-umu-r22.sunet.se [86.104.202.153]
23 65 ms 64 ms 64 ms umea-umu-r21.sunet.se [86.104.202.248]
24 62 ms 62 ms 62 ms saimei.ftp.acc.umu.se [194.71.11.138]

7) ftp.dk.debian.org (4.48 MB/s)
http://ftp.dk.debian.org/debian/ls-lR.gz
Resolving ftp.dk.debian.org (ftp.dk.debian.org)... 130.225.254.116, 001:878:346::116
100%[=>] 14.73M 4.48MB/s in 3.3s

Traccia instradamento verso mirrors.dotsrc.org [130.225.254.116]
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 8 ms 8 ms 8 ms 172.18.48.148
4 9 ms 9 ms 9 ms 172.18.48.188
5 12 ms 12 ms 12 ms 172.19.184.102
6 316 ms 65 ms 19 ms 172.19.177.78
7 16 ms 16 ms 16 ms 195.22.196.170
8 34 ms 34 ms 34 ms 185.100.113.149
9 33 ms 33 ms 33 ms nl-ams.nordu.net [80.249.209.203]
10 40 ms 40 ms 39 ms dk-esbj.nordu.net [109.105.97.74]
11 44 ms 43 ms 43 ms dk-bal2.nordu.net [109.105.97.2]
12 45 ms 45 ms 46 ms dk-ore.nordu.net [109.105.102.160]
13 50 ms 49 ms 49 ms ore.core.fsknet.dk [109.105.102.161]
14 52 ms 52 ms 56 ms 130.225.242.198
15 51 ms 51 ms 51 ms mirrors.dotsrc.org [130.225.254.116]

8) ftp.pl.debian.org (n/a)
http://ftp.pl.debian.org/debian/ls-lR.gz
Resolving ftp.pl.debian.org (ftp.pl.debian.org)... 153.19.251.221, 2001:4070:1:2::3
2024-07-13 16:09:27 (58.4 KB/s) - Read error at byte 332254/15450504 (Connection reset by peer). Retrying.
2024-07-13 16:09:46 (62.9 KB/s) - Read error at byte 1493562/15450504 (Connection reset by peer). Retrying.
2024-07-13 16:09:54 (59.7 KB/s) - Read error at byte 1821421/15450504 (Connection reset by peer). Retrying.
..
2024-07-13 16:14:04 (50.2 KB/s) - Read error at byte 9303547/15450504 (Connection reset by peer). Retrying.
2024-07-13 16:14:17 (42.3 KB/s) - Read error at byte 9447003/15450504 (Connection reset by peer). Retrying.
2024-07-13 16:14:36 (64.3 KB/s) - Read error at byte 10010087/15450504 (Connection reset by peer). Giving up.

Traccia instradamento verso ftp.pl.debian.org [153.19.251.221]
1 <1 ms <1 ms 1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 9 ms 9 ms 8 ms 172.18.48.144
4 8 ms 8 ms 8 ms 172.18.48.178
5 13 ms 13 ms 12 ms 172.19.184.98
6 14 ms 14 ms 14 ms 172.19.177.82
7 16 ms 16 ms 16 ms 195.22.205.98
8 15 ms 15 ms 15 ms 195.22.192.139
9 21 ms 16 ms 17 ms 195.22.212.223
10 35 ms 33 ms 32 ms ae2.3602.edge3.ber1.neo.colt.net [171.75.9.134]
11 37 ms 37 ms 37 ms 212.162.10.82
12 45 ms 44 ms 48 ms z-poznan-gw3.gdansk.10Gb.rtr.pionier.gov.pl [212.191.224.206]
13 43 ms 44 ms 43 ms grot-cio4.task.gda.pl [153.19.252.25]
14 44 ms 44 ms 44 ms ftp.pl.debian.org [153.19.251.221]

E' evidente che da qualche parte ci sia un serio problema, parte che sicuramente non è la mia.

mariomario

L'unica buona notizia è che finalmente sono riuscito ad effettuare il numero minimo di misurazioni valide traminte Nemesys per ottenere il certificato Agcom di inadempienza di Tim. Vediamo se l'avere una "carta" in mano può servire a qualcosa, quantomeno a migrare verso altri operatori in maniera relativamente indolore.

Allego un collage delle risultanze. Tra l'altro Nemesys ha già rilasciato l'apposito certificato dopo una manciata di misurazioni anziché le 96 canoniche.

Siete ancora sicuri che la teoria del throttling sia solo becero complottismo..?

DragonMaz

mariomario Credo Tim abbia di meglio da fare che limitare gli utenti a caso, hai provato con altri protocolli tipo torrent a scaricare una ISO di Debian? Va lento uguale?

GdiunG

mariomario a me con la fttc ,quando e stata attivata andava a 15 sia down che up
Il problema pensavo fosse un throttling ma era un problema di linea
Io credo che ci sia qualche altro problema
Al massimo o è nell'armadio o in centrale se proprio
Sicuramente le linee tim non sono le migliori al mondo,ma da qui a limitare la tua fttc perché sennò "i loro sistemi vanno in sovvracarico" credo ce ne vuole
Dovrebbero limitare le ftth oltretutto, su quelle puoi fare più traffico

mariomario

DragonMaz

Quindi se secondo te "Tim ha di meglio da fare", a prescindere da altre prove e test quale causa ipotizzi per i problemi sopra ampiamente documentati?

0.18 Mbps in up, dici che sia per colpa di una saturazione transitoria (che va avanti almeno da due settimane)?

Saturazione anche verso Wind, giusto? Si tratta solamente di un caso fortuito, specialmente con quel chart della velocità durante il test?

Sature anche le linee del GARR? Dici che forse i 43,6 KB (kilobyte) in download sono giustificabili per via del traffico della domenica sera?

Eh, anche 2.9 Mbps in down e 0.7 in up verso Xfinity sono perfettamente giustificabili: da qui agli USA (Woodstock in Georgia per la precisione) c'è un oceano di mezzo, no?

C'è del marcio in Danimarca (speedtest.dk), invece le linee Tim brillano e sfavillano che è una meraviglia. Osserva bene il grafico della velocità in up: vedi anche tu quello che vedo io o ho le traveggole? Poi, 3,5 Mbps da Wind a Milano e 50 Mbps da un qualche server dall'altro capo dell'Europa, anche qui, un lancio di dadi casuale?

Eppure con Nemesys quasi sfioro i 10 Mbit in up, in un singolo test.. anche qui, soltanto coincidenze?

Alla fine si scoprirà che è colpa della mia linea, con zero - letteralmente zero - errori CRC e un numero di FEC relativamente normale, no?

DragonMaz

mariomario Semplicemente dubito che siano costretti a limitarti visto che normalmente arrivi a 60 mega, dubito tu possa fare cosi tanto traffico da causare danni 😂. E' chiaro che c'è un problema, mah non avrei idea onestamente, sono stato anni con Tim e ho scaricato sempre e comunque a banda piena.

mariomario

GdiunG

All'"armadio" che differenza può fare se i pacchetti transitano da e verso reti a Milano, a Roma, a Woodstock o in qualsiasi altra parte dell'orbe terracqueo? E' evidente che non possa trattarsi di un problema fisico.

Se fosse un problema di saturazione transitorio non credo che sarei stato il solo a lamentarmene, ne tantomeno è ragionevole sostenere che possa perdurare per così tanto tempo. Detesto visceralmente complotti e complottari, ma sono davvero convinto sia un throttling intenzionale.

eutampieri

mariomario non mi sembra tu abbia fatto un MTR mentre fai lo Speedtest. Sarebbe molto utile farlo. Se ti può essere utile, cerca TCP congestion control.

mariomario

Gli operatori di TIM continuano imperterriti a chiudere i miei ticket dopo avere semplicemente verificato l'assenza di problematiche sul collegamento fisico (che sono ovviamente assenti), e propongono con insistenza di "pagare il pizzo" avvalendomi di tale servizio doctorTIM con la giustificazione che "i problemi sulla rete vengono gestiti dal dipartimento di informatica e non dagli addetti del 187" [cit].

Alla fine ho già effettuato richiesta di nuova attivazione con un operatore differente che so per certo non viaggi su EasyIP TIM e dato che ho un po' di tempo libero continuo a raccogliere materiale da presentare in sede di inevitabile futura conciliazione.

« Pagina precedente Pagina successiva »

Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈 🇵🇸
P.I. IT16712091004 - info@fibraclick.it

♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile