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

[AofSpades]

Le classi IP sono dei modi di dividere gli indirizzi IPv4 in varie sotto reti, non centrano ASSOLUTAMENTE NIENTE con il discorso delle latenze. Solo per il fatto che colleghi queste due cose direi che ti mancano le conoscenze adatte per poter discutere di link tra carrier esterni e reti dei provider.
Leggi questa pagina e se vuoi continuare a tirare fuori storie basate sul nulla, non so che dirti.

[MiloZ]

Originariamente inviato da AofSpades

Le classi IP sono dei modi di dividere gli indirizzi IPv4 in varie sotto reti, non centrano ASSOLUTAMENTE NIENTE con il discorso delle latenze. Solo per il fatto che colleghi queste due cose direi che ti mancano le conoscenze adatte per poter discutere di link tra carrier esterni e reti dei provider.
Leggi questa pagina e se vuoi continuare a tirare fuori storie basate sul nulla, non so che dirti.

Dai lasciamo stare, mi sembra di essere stato chiaro nei post precedenti, se vuoi fare finta di non capire inutile continuare.

L'articolo spiega una cosa ovvia e risaputa, e cioè che durante un traceroute alcuni hop possono aumentare la latenza\non rispondere al ping a causa del carico sulla rete\ bassa priorità imposta sulla quella specifica macchina ai pacchetti ICMP.. Nulla a che vedere con quello di cui stiamo parlando, visto che in questo caso la latenza è alta in maniera duratura sull'ultimo nodo del traceroute in quella fascia oraria, dovuto proprio ad un problema di saturazione sulla rete di trasporto.

Ecco i traceroute seguiti dal ping di alcuni server in saturazione, così potrai constatare che la tua convinzione per cui la latenza tra ping e traceroute fosse diversa , era sbagliata:

Traccia instradamento verso xch.nl [93.184.96.73]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     5 ms     4 ms     4 ms  10.6.131.57
  3     5 ms     4 ms     4 ms  10.250.135.6
  4     6 ms     4 ms     5 ms  10.250.29.194
  5     9 ms     8 ms     8 ms  10.254.11.161
  6     9 ms     9 ms     9 ms  89.97.200.201
  7    13 ms    11 ms    10 ms  89.97.200.233
  8   104 ms   103 ms   107 ms  et3-0-2.roma52.rom.seabone.net [89.221.32.112]
  9   102 ms   109 ms   117 ms  ae20.milano51.mil.seabone.net [195.22.205.13]
 10    19 ms    19 ms    19 ms  ntt-verio.milano51.mil.seabone.net [93.186.128.157]
 11   135 ms   135 ms   131 ms  ae-0.r24.amstnl02.nl.bb.gin.ntt.net [129.250.3.178]
 12   124 ms   115 ms   117 ms  ae-0.a02.amstnl02.nl.bb.gin.ntt.net [129.250.3.55]
 13   136 ms   134 ms   128 ms  212.119.24.218
 14   136 ms   131 ms   133 ms  xe-0-0-0.er-r23.tcn.as31477.net [89.188.4.34]
 15   138 ms   140 ms   139 ms  www.xch.nl [93.184.96.73]

Traccia completata.

C:\Users\Admin>hrping xch.nl -n10
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.178.20; using ICMP echo-request, ID=2c15
Pinging xch.nl [93.184.96.73]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: Tentativo di accesso al socket con modalità non consentite dalle rispettive autorizzazioni di accesso.
From 93.184.96.73: bytes=60 seq=0001 TTL=50 ID=2b43 time=137.958ms
From 93.184.96.73: bytes=60 seq=0002 TTL=50 ID=2b44 time=140.267ms
From 93.184.96.73: bytes=60 seq=0003 TTL=50 ID=2b45 time=126.650ms
From 93.184.96.73: bytes=60 seq=0004 TTL=50 ID=2b46 time=139.646ms
From 93.184.96.73: bytes=60 seq=0005 TTL=50 ID=2b47 time=140.833ms
From 93.184.96.73: bytes=60 seq=0006 TTL=50 ID=2b48 time=133.733ms
From 93.184.96.73: bytes=60 seq=0007 TTL=50 ID=2b49 time=140.915ms
From 93.184.96.73: bytes=60 seq=0008 TTL=50 ID=2b4a time=132.746ms
From 93.184.96.73: bytes=60 seq=0009 TTL=50 ID=2b4b time=136.846ms
From 93.184.96.73: bytes=60 seq=000a TTL=50 ID=2b4c time=140.989ms

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.641551 sec
RTTs in ms: min/avg/max/dev: 126.650 / 137.058 / 140.989 / 4.476
Bandwidth in kbytes/sec: sent=0.129, rcvd=0.129

C:\Users\Admin>ping xch.nl -n 10

Esecuzione di Ping xch.nl [93.184.96.73] con 32 byte di dati:
Risposta da 93.184.96.73: byte=32 durata=130ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=141ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=140ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=140ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=126ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=136ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=141ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=131ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=138ms TTL=50
Risposta da 93.184.96.73: byte=32 durata=116ms TTL=50

Statistiche Ping per 93.184.96.73:
    Pacchetti: Trasmessi = 10, Ricevuti = 10,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 116ms, Massimo =  141ms, Medio =  133ms

----------------------------------------------------------------------------------------------------------------------------------------------------

Traccia instradamento verso multiplay.co.uk [85.236.96.26]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     4 ms     4 ms     4 ms  10.6.131.57
  3     5 ms     4 ms     5 ms  10.250.135.14
  4     5 ms     5 ms     5 ms  10.250.29.194
  5     9 ms     9 ms     8 ms  10.254.11.161
  6     9 ms     9 ms     9 ms  89.97.200.201
  7    10 ms     9 ms     9 ms  93.57.68.222
  8     9 ms     9 ms     8 ms  93.57.68.221
  9    10 ms     9 ms    12 ms  8-1-1.bear1.italy2.level3.net [212.73.241.225]
 10     *        *        *     Richiesta scaduta.
 11   127 ms   129 ms   128 ms  ae-23-3611.ear2.london15.level3.net [4.69.167.162]
 12   132 ms   131 ms   133 ms  195.50.120.99
 13   134 ms   127 ms   123 ms  ha01.multiplay.co.uk [85.236.96.26]

Traccia completata.

C:\Users\Admin>hrping multiplay.co.uk -n10
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.178.20; using ICMP echo-request, ID=d050
Pinging multiplay.co.uk [85.236.96.26]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: Tentativo di accesso al socket con modalità non consentite dalle rispettive autorizzazioni di accesso.
From 85.236.96.26: bytes=60 seq=0001 TTL=53 ID=29ee time=130.502ms
From 85.236.96.26: bytes=60 seq=0002 TTL=53 ID=29f2 time=132.687ms
From 85.236.96.26: bytes=60 seq=0003 TTL=53 ID=2a03 time=131.787ms
From 85.236.96.26: bytes=60 seq=0004 TTL=53 ID=2a0b time=122.642ms
From 85.236.96.26: bytes=60 seq=0005 TTL=53 ID=2a10 time=126.717ms
From 85.236.96.26: bytes=60 seq=0006 TTL=53 ID=2a21 time=133.555ms
From 85.236.96.26: bytes=60 seq=0007 TTL=53 ID=2a2c time=133.094ms
From 85.236.96.26: bytes=60 seq=0008 TTL=53 ID=2a2e time=133.813ms
From 85.236.96.26: bytes=60 seq=0009 TTL=53 ID=2a31 time=133.909ms
From 85.236.96.26: bytes=60 seq=000a TTL=53 ID=2a33 time=129.147ms

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.629254 sec
RTTs in ms: min/avg/max/dev: 122.642 / 130.785 / 133.909 / 3.495
Bandwidth in kbytes/sec: sent=0.129, rcvd=0.129

C:\Users\Admin>ping multiplay.co.uk -n 10

Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=133ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=133ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=125ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=133ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=126ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=135ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=135ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=126ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=127ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=127ms TTL=53

Statistiche Ping per 85.236.96.26:
    Pacchetti: Trasmessi = 10, Ricevuti = 10,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 125ms, Massimo =  135ms, Medio =  130ms

I ping sono stati fatti sia col comando di windows standard che tramite un software più preciso [Hrping]. Stessi risultati.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Di qualche altro server posto solo i ping per far prima:

C:\Users\Admin>hrping dedibox.fr -n10
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.178.20; using ICMP echo-request, ID=a83f
Pinging dedibox.fr [62.210.16.2]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: Tentativo di accesso al socket con modalità non consentite dalle rispettive autorizzazioni di accesso.
From 62.210.16.2: bytes=60 seq=0001 TTL=53 ID=6fec time=130.300ms
From 62.210.16.2: bytes=60 seq=0002 TTL=53 ID=6ffe time=127.905ms
From 62.210.16.2: bytes=60 seq=0003 TTL=53 ID=7020 time=122.016ms
From 62.210.16.2: bytes=60 seq=0004 TTL=53 ID=703f time=116.419ms
From 62.210.16.2: bytes=60 seq=0005 TTL=53 ID=7081 time=126.940ms
From 62.210.16.2: bytes=60 seq=0006 TTL=53 ID=70f7 time=127.817ms
From 62.210.16.2: bytes=60 seq=0007 TTL=53 ID=7148 time=128.800ms
From 62.210.16.2: bytes=60 seq=0008 TTL=53 ID=7171 time=113.451ms
From 62.210.16.2: bytes=60 seq=0009 TTL=53 ID=7172 time=129.809ms
From 62.210.16.2: bytes=60 seq=000a TTL=53 ID=71e9 time=129.483ms

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.629771 sec
RTTs in ms: min/avg/max/dev: 113.451 / 125.294 / 130.300 / 5.665
Bandwidth in kbytes/sec: sent=0.129, rcvd=0.129

C:\Users\Admin>hrping www.gatel.de -n10
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.178.20; using ICMP echo-request, ID=982d
Pinging www.gatel.de [38.100.128.10]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: Tentativo di accesso al socket con modalità non consentite dalle rispettive autorizzazioni di accesso.
From 38.100.128.10: bytes=60 seq=0001 TTL=52 ID=3a16 time=119.235ms
From 38.100.128.10: bytes=60 seq=0002 TTL=52 ID=3b84 time=120.925ms
From 38.100.128.10: bytes=60 seq=0003 TTL=52 ID=3c1f time=125.913ms
From 38.100.128.10: bytes=60 seq=0004 TTL=52 ID=3ca1 time=123.122ms
From 38.100.128.10: bytes=60 seq=0005 TTL=52 ID=3cca time=118.966ms
From 38.100.128.10: bytes=60 seq=0006 TTL=52 ID=3de7 time=125.813ms
From 38.100.128.10: bytes=60 seq=0007 TTL=52 ID=3eb5 time=123.900ms
From 38.100.128.10: bytes=60 seq=0008 TTL=52 ID=3ef6 time=125.998ms
From 38.100.128.10: bytes=60 seq=0009 TTL=52 ID=401e time=124.758ms
From 38.100.128.10: bytes=60 seq=000a TTL=52 ID=4204 time=125.491ms

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.626300 sec
RTTs in ms: min/avg/max/dev: 118.966 / 123.412 / 125.998 / 2.618
Bandwidth in kbytes/sec: sent=0.129, rcvd=0.129

C:\Users\Admin>hrping easo.ea.com -n10
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.178.20; using ICMP echo-request, ID=5c23
Pinging easo.ea.com [159.153.64.173]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: Tentativo di accesso al socket con modalità non consentite dalle rispettive autorizzazioni di accesso.
From 159.153.64.173: bytes=60 seq=0001 TTL=243 ID=730c time=206.361ms
From 159.153.64.173: bytes=60 seq=0002 TTL=243 ID=730d time=206.186ms
From 159.153.64.173: bytes=60 seq=0003 TTL=243 ID=730e time=208.386ms
From 159.153.64.173: bytes=60 seq=0004 TTL=243 ID=730f time=208.321ms
From 159.153.64.173: bytes=60 seq=0005 TTL=243 ID=7310 time=207.606ms
From 159.153.64.173: bytes=60 seq=0006 TTL=243 ID=7311 time=207.044ms
From 159.153.64.173: bytes=60 seq=0007 TTL=243 ID=7312 time=208.114ms
From 159.153.64.173: bytes=60 seq=0008 TTL=243 ID=7313 time=205.297ms
From 159.153.64.173: bytes=60 seq=0009 TTL=243 ID=7314 time=203.559ms
From 159.153.64.173: bytes=60 seq=000a TTL=243 ID=7315 time=207.402ms

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.708407 sec
RTTs in ms: min/avg/max/dev: 203.559 / 206.827 / 208.386 / 1.447
Bandwidth in kbytes/sec: sent=0.127, rcvd=0.127

[jardel]

ma secondo voi chi è passato a fw da tim nel mese di ottobre lo paga il recesso da tim oppure no? viste le rimodulazioni tim che ci sono state...

[AofSpades]

Originariamente inviato da MiloZ

Dai lasciamo stare, mi sembra di essere stato chiaro nei post precedenti, se vuoi fare finta di non capire inutile continuare.

Quindi lasciamo stare il fatto che hai detto una cosa chiaramente sbagliata, ma dobbiamo fidarci del resto?

L'articolo spiega una cosa ovvia e risaputa, e cioè che durante un traceroute alcuni hop possono aumentare la latenza\non rispondere al ping a causa del carico sulla rete\ bassa priorità imposta sulla quella specifica macchina ai pacchetti ICMP.. Nulla a che vedere con quello di cui stiamo parlando, visto che in questo caso la latenza è alta in maniera duratura sull'ultimo nodo del traceroute in quella fascia oraria, dovuto proprio ad un problema di saturazione sulla rete di trasporto.

Hai letto male l'articolo. Approfondisci gli argomenti trattati e ritornaci.
Siccome sembra che stia a difendere a spada tratta FW, ma in realtà non me ne potrebbe fregare di meno, ti ripeterò per l'ultima volta questo:
-I test che hai fatto non sono abbastanza precisi
-Il modo in cui interpreti i test che hai fatto è sbagliato
-Non hai la preparazione tecnica necessaria per poter arrivare alle conclusioni a cui sei arrivato

Forse 20 anni fa si poteva fare un discorso come quello che fai tu, adesso internet è IMMENSAMENTE più complicato.

[virtualj]

Guarda io sono nel campo IT e sinceramente non ho proprio capito dove vuole andare a parare quell'articolo, visto che sia ping che traceroute sono fatti con ICMP. Che poi puoi fare lo stesso trick del TTL anche con udp o tcp e in quel caso vanno a farsi fotte re eventuali politiche di priorità dei pacchetti. Mi pare che con hrping si possa fare

[AofSpades]

So in conclusion, your decision to trust and use data from ICMP based troubleshooting should be based on your relative understanding of the transit path. You should never take a traceroute that has high latency on it and say its a network issue just because hope 7 has latency greater then 250ms. This is no different the a doctor telling you your spleen is the result of your headaches without factual basis.

If you do not have clear factual data when diagnosing a problem and you blame the network because of a traceroute, you may very well be completely missing the root cause of the problem. Think of it as getting tunneled vision when sh!t hits the fan and management is expecting answers and the first thing you notice is high latency on a traceroute. With out completely understanding traceroute you may be fixating on an issue that is really not an issue at all.

Dice che senza conoscere dettagliatamente le reti e l'hardware su sui passano i traceroute, non puoi decidere che esiste un problema solo perché un numerino è più alto di un altro. Si fa una diagnosi errata.

[tolwyn]

devo dire, magari con un tono meno perentorio,che sono d'accordo con spades: la variazione dei valori di traceroute è senza dubbio indicativa di qualche modifica nell'equilibrio della topologia di rete o nella configurazione di alcuni apparati, ma senza avere le mani sul ferro non si può "pontificare" su ciò che realmente sta accadendo

certo una peggioramento sostanzioso di latenza sugli host di riferimento non è piacevole

[virtualj]

Originariamente inviato da jardel

ma secondo voi chi è passato a fw da tim nel mese di ottobre lo paga il recesso da tim oppure no? viste le rimodulazioni tim che ci sono state...

dovevi mandare raccomandata se volevi sfruttare la rimodulazione

[MiloZ]

Originariamente inviato da AofSpades

Hai letto male l'articolo. Approfondisci gli argomenti trattati e ritornaci.
Siccome sembra che stia a difendere a spada tratta FW, ma in realtà non me ne potrebbe fregare di meno, ti ripeterò per l'ultima volta questo:
-I test che hai fatto non sono abbastanza precisi
-Il modo in cui interpreti i test che hai fatto è sbagliato
-Non hai la preparazione tecnica necessaria per poter arrivare alle conclusioni a cui sei arrivato

Forse 20 anni fa si poteva fare un discorso come quello che fai tu, adesso internet è IMMENSAMENTE più complicato.

E' strano che tu voglia fare polemica per il solo guasto di farla, ti ho voluto seguire nel ragionamento con l'idea che lo scopo fosse cercare di appurare ed analizzare in maniera oggettiva le problematiche riscontrate (cioè che la latenza di sera si alza di 100ms verso molte direttrici internazionali quando con altri ISP, magari passando dagli stessi carrier verso gli stessi server, non accade).
Sembra che il tuo unico scopo sia minimizzare e sminuire il problema per difendere Fastweb a spada tratta, barricandoti dietro a discorsi che non si basano su dati di fatto (che nella realtà pratica sono quelli che contano), ma su tue congetture teoriche estrapolate di qua e di la che non evidenziano mai il fulcro della questione ma tendono sempre di girarci intorno.

Devi prendere atto che Fastweb ha un problema (l'entita dello stesso è soggettiva a seconda di come ognuno usa la linea), poi se non vuoi accettarlo per principio cercando di contraddire l'evidenza, allora alzo le mani e smetto prenderti sul serio.

[MiloZ]

Originariamente inviato da AofSpades

Quindi lasciamo stare il fatto che hai detto una cosa chiaramente sbagliata, ma dobbiamo fidarci del resto?

Scusa ma, hai capito quello che ho scritto prima oppure continui ad andare a diritto senza leggere?
Ho tre linee, e tutte quelle con IP dinamico hanno questa peculiarità da anni (tanti altri se ne sono accorti nel forum essendo stato sollevato più volte l'argomento).
Cambiando IP della connessione (la classe IP piuttosto che soltanto alcuni ottetti dell'IP di collegamento), alcune volte cambia la latenza verso un server o un'altro (in particolare verso l'estero ma con certi ISP anche in Italia).
Questo accade nella realtà, da qui ti dicevo che anche con Fastweb avere un certo IP piuttosto che un'altro può far variare le prestazioni\routing che si hanno su di uno stesso server nel medesimo momento da zone diverse.
Non è una questione di fidarsi o meno, basta usare le connessioni ad Internet italiane (almeno parlando dei grandi ISP, di solito più è grossa la rete più è frequente il fatto che possano esserci divergenze di latenza cambiando IP) per rendersi conto di come stanno le cose.

Originariamente inviato da AofSpades

Dice che senza conoscere dettagliatamente le reti e l'hardware su sui passano i traceroute, non puoi decidere che esiste un problema solo perché un numerino è più alto di un altro. Si fa una diagnosi errata.

Dal momento che, se su molti server finchè il traffico non raggiubge una certa soglia il ping è regolare, e poi gradualmente comincia ad aumentare di 100ms circa, significa che evidentemente un problema c'è e dipende da Fastweb. Cioè non è che questo incoveniente si verifica soltanto sul numeretto del traceroute; se entro in un server di gioco che da dos pinga 120ms anche la latenza in-game sarà tale, questo mi sembrava sottinteso, quindi parliamo di un'effetto reale.
Che poi la cosa per te abbia una importanza relativa è un'altro paio di maniche.

Se poi ciò che ti irritava particolarmente è la parola "saturazione" volendo additare la magagna ad altre possibili cause, che sia una mis-configurazione o un qualche guasto su qualche apparato, tutto è possibile, ma il succo cambia di poco, c'è comunque qualcosa da risolvere\sistemare da parte di Fastweb.

[AofSpades]

Originariamente inviato da MiloZ

Cambiando IP della connessione (la classe IP piuttosto che soltanto alcuni ottetti dell'IP di collegamento), alcune volte cambia la latenza verso un server o un'altro (in particolare verso l'estero ma con certi ISP anche in Italia).

Le classi IP NON CENTRANO NIENTE!. Non sono neanche più in uso!
Nel 1993(!) è stato introdotto il CIDR a rimpiazzarle. Smettila di discutere di un argomento di cui evidentemente hai una conoscenza limitata.
Continui a fare ipotesi basate sul sentito dire, testimonianze inaffidabili e test con troppe variabili. Non puoi diagnosticare con una manciata di tracert quello che dici.

[MiloZ]

Originariamente inviato da AofSpades

Le classi IP NON CENTRANO NIENTE!. Non sono neanche più in uso!
Nel 1993(!) è stato introdotto il CIDR a rimpiazzarle. Smettila di discutere di un argomento di cui evidentemente hai una conoscenza limitata.
Continui a fare ipotesi basate sul sentito dire, testimonianze inaffidabili e test con troppe variabili. Non puoi diagnosticare con una manciata di tracert quello che dici.

Ed io che perdo tempo a cercare di spiegarmi piu chiaramente possibile per evitare fraintendimenti...... la tua intenzione non è quella di instaurare una discussione pacifica e costruttiva ma chiaramente soltanto di creare polemica gratuita, peccato.

[AofSpades]

Non ti ho risposto per creare polemica, ti volevo solo dare dei consigli tecnici.
Se dai miei messaggi trapela un tono perentorio o aggressivo, devi scusarmi ma non è questa la mia intenzione. Discutere su un forum è dispersivo e ho voluto scrivere in modo conciso e chiaro. Era mia intenzione farti capire che, sì, le latenze aumentano, ma ciò non vuol dire che ci sia un problema da risolvere.
A parte questo, domani farò dei test su una linea TIM e posterò i risultati in tarda serata.

[jardel]

Originariamente inviato da virtualj

dovevi mandare raccomandata se volevi sfruttare la rimodulazione

eh ma io quando ho fatto il contratto con fw era settembre e non si sapeva ancora delle rimodulazioni e nella bolletta di settembre non c'era scritto nulla, tuttavia il passaggio effettivo è avvenuto a ottobre
cmq non ero nè tuttovoce,ne internet senza limiti,nè tim smart per cui non so se sarebbe valso lo stesso la rimodulazione

[DjLode]

Originariamente inviato da jardel

eh ma io quando ho fatto il contratto con fw era settembre e non si sapeva ancora delle rimodulazioni e nella bolletta di settembre non c'era scritto nulla, tuttavia il passaggio effettivo è avvenuto a ottobre
cmq non ero nè tuttovoce,ne internet senza limiti,nè tim smart per cui non so se sarebbe valso lo stesso la rimodulazione

Se non ti hanno inviato comunicazione per la rimodulazione, uscendo da un gestore se sono previsti costi di recesso li devi pagare.

[alexdz]

Originariamente inviato da jardel

ma secondo voi chi è passato a fw da tim nel mese di ottobre lo paga il recesso da tim oppure no? viste le rimodulazioni tim che ci sono state...

Mi auguro di si.
Io la comunicazione di recesso l'ho fatta, a seguito della rimodulazione notificata in bolletta. La cosa "curiosa" è che io la comunicazione l'ho fatta tramite portale MyTim (è una delle modalità indicate in bolletta), l'hanno ricevuta (ne ho conservato copia), e l'altro giorno mi è arrivata una loro mail nella quale, con riferimento alla mia comunicazione, anzichè prendere atto del recesso, mi ripetono sostanzialmente quello che era indicato nella bolletta, ovvero i termini e le modalità di notifica del recesso (tra cui anche MyTim).
Ci sono o ci fanno?
Non resta che attendere la prossima e ultima bolletta Tim...

[DjLode]

Originariamente inviato da alexdz

Mi auguro di si.
Io la comunicazione di recesso l'ho fatta, a seguito della rimodulazione notificata in bolletta. La cosa "curiosa" è che io la comunicazione l'ho fatta tramite portale MyTim (è una delle modalità indicate in bolletta), l'hanno ricevuta (ne ho conservato copia), e l'altro giorno mi è arrivata una loro mail nella quale, con riferimento alla mia comunicazione, anzichè prendere atto del recesso, mi ripetono sostanzialmente quello che era indicato nella bolletta, ovvero i termini e le modalità di notifica del recesso (tra cui anche MyTim).
Ci sono o ci fanno?
Non resta che attendere la prossima e ultima bolletta Tim...

Nello stato delle richieste, sul sito o su MyTim Fisso, come la vedi? Da me è "evasa",
Io ho fatto dal sito e ho inviato comunque anche la pec.

[alexdz]

Originariamente inviato da DjLode

Nello stato delle richieste, sul sito o su MyTim Fisso, come la vedi? Da me è "evasa",
Io ho fatto dal sito e ho inviato comunque anche la pec.

Nell'area comunicazioni, dove trovo anche la mia, trovo la stessa risposta che ho ricevuto via mail.
Nell'area richieste trovo le pratiche di disattivazione della linea, date per "evase", con data corrispondente a quando la linea TIM di fatto è cessata.

[DjLode]

Originariamente inviato da alexdz

Nell'area comunicazioni, dove trovo anche la mia, trovo la stessa risposta che ho ricevuto via mail.
Nell'area richieste trovo le pratiche di disattivazione della linea, date per "evase", con data corrispondente a quando la linea TIM di fatto è cessata.

Nelle richieste è così anche da me. Nelle comunicazioni devo guardare. Stasera controllo anche solo per curiosità.

[MiloZ]

Originariamente inviato da AofSpades

Non ti ho risposto per creare polemica, ti volevo solo dare dei consigli tecnici.
Se dai miei messaggi trapela un tono perentorio o aggressivo, devi scusarmi ma non è questa la mia intenzione. Discutere su un forum è dispersivo e ho voluto scrivere in modo conciso e chiaro. Era mia intenzione farti capire che, sì, le latenze aumentano, ma ciò non vuol dire che ci sia un problema da risolvere.
A parte questo, domani farò dei test su una linea TIM e posterò i risultati in tarda serata.

Stasera miracolosamente sono le 21:30 e ancora la saturazione non c'è stata, latenze basse e stabili su tutti i server.
Vediamo se è soltanto un caso oppure hanno risolto definitivamente.