WindTre Packet Loss

Fhom · 30-11-2023, 20:06

Ciao a tutti, prima di tutto due domande generiche:

- Da una settimana circa qualcuno ha problemi di packet loss (che non aveva prima) con WindTre?
- C'è un modo per far sì che WindTre calcoli e risolva questo problema quando si fanno le segnalazioni?

Ho un'ADSL ULL a Perugia, non ho quasi mai avuto problemi e di solito si sono risolti con intervento di un tecnico in centrale o dopo che hanno terminato lavori di zona. Siccome soddisfatto di questa linea e per "non rischiare" non mi sono azzardato a passare ad una FTTc (100) anche se sarei coperto.

Da una settimana però ho packet loss, circa 2% misurandolo verso 8.8.8.8, i valori della linea sono sempre quelli classici e non ho altri problemi (disconnessioni ad esempio) che mi possano far pensare che sia un problema "fisico". Ho fatto due segnalazioni a WindTre ma non ho avuto successo, ci riproverò ma dubito che prendano in considerazione la cosa e l'unica speranza che ho è che sia un problema generale che verrà risolto a breve o, cosa che sto valutando, passare ad FTTc, ovviamente di altro operatore. Qualcuno sa dirmi qualcosa in merito o può fare qualcosa di più concreto?

grazie

Psyred · 01-12-2023, 09:53

Io non rilevo problemi particolari verso 8.8.8.8. Considera però che i DNS google sono anycast, quindi a qull'indirizzo IP possono essere associati più server differenti, in località differenti con instradamenti differenti.

Ergo il mio server e il mio percorso potrebbero essere del tutto differenti dai tuoi, con possibili criticità a seconda del routing.

Se sei di Perugia, come vedo dal profilo, è peraltro probabile che server e percorsi siano identici dato che WindTre instrada le utenze di quella zona verso il POP/BRAS di Firenze.

Al limite prova a testare un indirizzo unicast tipo aruba.it (AR) o telnet.it (MI).

Mio esito di ping iterato:

Codice:

Esecuzione di Ping 8.8.8.8 con 32 byte di dati:
Risposta da 8.8.8.8: byte=32 durata=9ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=9ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117
Risposta da 8.8.8.8: byte=32 durata=8ms TTL=117

Statistiche Ping per 8.8.8.8:
    Pacchetti: Trasmessi = 200, Ricevuti = 200,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 8ms, Massimo =  9ms, Medio =  8ms

P.S. che ci fai in ADSL? Ormai quella tecnologia è roba da museo. A meno che tu non sia molto distante dal cabinet valuta seriamente un passaggio verso FTTC.

OUTATIME · 02-12-2023, 07:09

Già detto più di una volta: la perdita di pacchetti non è indicativa di problemi, comunque una segnalazione per il DSLAM ADSL non la prendono neppure in considerazione, si e no che abbiano ancora i ricambi.
Passa in FTTC, e vista l'imminente dismissione del rame, se sei coperto in FTTH ti conviene fare il passaggio una volta del rame.

Fhom · 02-12-2023, 17:51

Quote:

Originariamente inviato da Psyred

Io non rilevo problemi particolari verso 8.8.8.8. Considera però che i DNS google sono anycast, quindi a qull'indirizzo IP possono essere associati più server differenti, in località differenti con instradamenti differenti.

Ergo il mio server e il mio percorso potrebbero essere del tutto differenti dai tuoi, con possibili criticità a seconda del routing.

Se sei di Perugia, come vedo dal profilo, è peraltro probabile che server e percorsi siano identici dato che WindTre instrada le utenze di quella zona verso il POP/BRAS di Firenze.

Al limite prova a testare un indirizzo unicast tipo aruba.it (AR) o telnet.it (MI).

P.S. che ci fai in ADSL? Ormai quella tecnologia è roba da museo. A meno che tu non sia molto distante dal cabinet valuta seriamente un passaggio verso FTTC.

Grazie per la risposta, quindi non hai consigli da dirmi per come fare una efficace segnalazione per questo problema?
Verso gli altri indirizzi non ho perdite ma solo qualche pacchetto che ogni tanto schizza a 300+ ms (da 20-30 ms).

Sono ancora in ADSL per due motivi, il primo è che ho paura che il ping e la qualità peggiori, ho sempre avuto sui 20 ms circa verso 8.8.8.8 (che stranamente ora che ho il problema sono scesi a 16-17, ma ogni tanto ci sono pacchetti che vanno a 300-400ms), non sono lontano per FTTc (200 metri dalla centralina di strada, secondo fibermap) ma una stima con TIM mi dava 18 ms e una stima con WindTre mi dava 25 ms (le altre compagnie non mi danno una stima del ping o almeno non l'ho trovato), visto che entrambi hanno fatto la porcata dell'aumento dei prezzi in base all'inflazione e che con qualsiasi operatore in wholesale ho paura che se ne sbattano un po' dell'assistenza (ora sono in ULL e le poche volte l'assistenza è stata abbastanza celere, a parte una volta che hanno fatto pena), lavorando comunque in un operatore internet di zona ho notato che TIM non è che sia (probabilmente giustamente) poi così attenta ai clienti in wholesale, infatti la mia scelta per il cambio era proprio TIM. Ovviamente ci guadagnerei in prestazioni down/up, non lo metto in dubbio, ma visto anche i dubbi sulla qualità del mio impianto o di quello di strada (vedi dopo) ho paura di ritrovarmi con un ping peggiorato e magari con altri problemi, quello che mi interessava era la stabilità ed un ping decente.

Il secondo motivo è che ho la presa principale lontana dal telefono, che devo mantenere, quindi con la FTTc devo riportare un cavo sull'impianto telefonico, e no non posso mettere il cordless dove starebbe il modem perchè deve stare in altre parti della casa, in più sia l'impianto telefonico interno che temo quello esterno sono un po' datati (ci sono state un po' di vicende per cui hanno dovuto usare un altro cavo che in realtà era dell'ISDN il cui stato non è però dei migliori passando per una stanza dove c'è molta umidità... dovrei insomma rimettere mano ad un po' di cose).

Insomma finora mi andava bene il servizio per quello che era per non dover rischiare di andare in contro a peggioramenti o sbattimenti vari, di solito si rischia di peggiorare le situazioni a meno di non fare le cose ex novo.

Quote:

Originariamente inviato da OUTATIME

Già detto più di una volta: la perdita di pacchetti non è indicativa di problemi, comunque una segnalazione per il DSLAM ADSL non la prendono neppure in considerazione, si e no che abbiano ancora i ricambi.
Passa in FTTC, e vista l'imminente dismissione del rame, se sei coperto in FTTH ti conviene fare il passaggio una volta del rame.

Nel mio caso è indicativa di problemi visto che mi sono accorto prima dei problemi su GW2 (abilità che non partivano con la stessa rapidità, qualche "ritorno indietro" del personaggio e poi ho controllato la perdita di pacchetti, dopo anni in cui ho avuto NGI che ogni pochi mesi aveva questo problema noto subito quando c'è un problema del genere, inoltre fino alla settimana scorsa potevo tranquillamente tenere più dispositivi collegati (che facevano traffico) e non avere problemi di ping (o di utilizzo) quindi ti assicuro che la differenza si vede.

Per il fatto di non essere passato all'FTTc le spiegazioni le ho riportate sopra, ad aver avuto la FTTH lo avrei già fatto, proprio per evitare i "rischi" o complicazioni dei motivi di cui sopra, purtroppo pur avendola a poche centinaia di metri si sono fermati proprio nella zona dove sto io (sia da un lato che da un'altro).

Grazie comunque per il tuo punto di vista e per le informazioni che mi hai fornito.

Psyred · 02-12-2023, 19:57

Prova a testare l'IP del server di GW2 (se lo conosci) con tool tipo WinMTR, magari riesci ad individuare i nodi con i picchi di latenza, o che perdono pacchetti.

Se noti PL che si propaga dai primi hop fino al server di destinazione è possibile che si tratti di saturazione della rete W3 nella tua zona.

D'altra parte con le ADSL in via di dismissione è normale che quella tecnologia sia trascurata. Se il DSLAM è saturo te lo tieni diciamo... Oppure passi a FTTC sperando che i problemi si risolvano.

OUTATIME · 02-12-2023, 20:37

Quote:

Originariamente inviato da Fhom

Nel mio caso è indicativa di problemi visto che mi sono accorto prima dei problemi su GW2 [...]

Non mi sono spiegato.
I pacchetti ICMP hanno bassa priorità in rete, di conseguenza tutti gli apparati che attraversano, compreso il DSLAM, PRIMA fa il suo lavoro per cui è progettato, POI, se rimangono tempo e risorse, risponde o fa passare un ping.

Quote:

Originariamente inviato da Fhom

Sono ancora in ADSL per due motivi, il primo è che ho paura che il ping e la qualità peggiori, ho sempre avuto sui 20 ms circa verso 8.8.8.8 (che stranamente ora che ho il problema sono scesi a 16-17, ma ogni tanto ci sono pacchetti che vanno a 300-400ms)

Apounto, proprio per il motivo che ho appena scritto.

Tornando al tuo caso, poco importa se il DSLAM è saturo, ha la CPU perennemente al 100% o semplicemente TIM ha riconfigurato la fibra in centrale per dare priorità alle FTTC, qualsiasi sia il problema sei fortunato se non ti è ancora arrivata la lettera di dismissione della centrale ADSL, figurati se prendono in considerazione segnalazione di perdita di pacchetti.

Fhom · 02-12-2023, 22:04

Quote:

Originariamente inviato da Psyred

Prova a testare l'IP del server di GW2 (se lo conosci) con tool tipo WinMTR, magari riesci ad individuare i nodi con i picchi di latenza, o che perdono pacchetti.

Se noti PL che si propaga dai primi hop fino al server di destinazione è possibile che si tratti di saturazione della rete W3 nella tua zona.

Sì avevo fatto (era uno dei programmi consigliati proprio da GW2 per diagnosticare eventuali problemi di rete), grazie comunque per la dritta, da lì avevo infatti visto che la perdita iniziava già dal primo hop
Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
151.7.198.30 - 1 | 505 | 501 | 10 | 31 | 1083 | 11 |
151.7.198.12 - 1 | 508 | 505 | 10 | 27 | 1027 | 12 |
151.6.7.34 - 1 | 512 | 510 | 15 | 28 | 1082 | 16 |
151.7.112.5 - 1 | 508 | 505 | 16 | 31 | 785 | 36 |

Stasera non sembra così pessimo, anche se ci sono picchi che poi in gioco si riflettono parecchio, un'ora fa insieme al gioco stavo guardando anche uno stream Twitch a 160p (quindi consumo quasi nullo) e l'ho dovuto chiudere perchè era ingiocabile, considerando che prima di questo problema riuscivo tranquillamente a vedere uno stream twitch sempre bassa-media qualità, un video youtube e anche un paio di client aggiuntivi di GW2 avendo 0 problemi, la differenza si sente.

Quote:

D'altra parte con le ADSL in via di dismissione è normale che quella tecnologia sia trascurata. Se il DSLAM è saturo te lo tieni diciamo... Oppure passi a FTTC sperando che i problemi si risolvano.

Il dato da Fibermap può essere utile? Vale solo per quelle TIM o per tutte le ADSL in quella centrale? In questo ultimo caso l'ADSL ETH non è segnata come satura.

Quote:

Originariamente inviato da OUTATIME

Non mi sono spiegato.
I pacchetti ICMP hanno bassa priorità in rete, di conseguenza tutti gli apparati che attraversano, compreso il DSLAM, PRIMA fa il suo lavoro per cui è progettato, POI, se rimangono tempo e risorse, risponde o fa passare un ping.

Sicuramente lavori sul campo o hai informazioni più precise, personalmente non ho mai avuto problemi prima d'ora quando il packet loss era a posto, quindi per me è stato naturale associare questo comportamento al problema, come per altro è successo altre volte.

Quote:

Apounto, proprio per il motivo che ho appena scritto.

Tornando al tuo caso, poco importa se il DSLAM è saturo, ha la CPU perennemente al 100% o semplicemente TIM ha riconfigurato la fibra in centrale per dare priorità alle FTTC, qualsiasi sia il problema sei fortunato se non ti è ancora arrivata la lettera di dismissione della centrale ADSL, figurati se prendono in considerazione segnalazione di perdita di pacchetti.

Faremo di necessità virtù.

Psyred · 02-12-2023, 22:49

Quote:

Originariamente inviato da Fhom

Sì avevo fatto (era uno dei programmi consigliati proprio da GW2 per diagnosticare eventuali problemi di rete), grazie comunque per la dritta, da lì avevo infatti visto che la perdita iniziava già dal primo hop
Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
151.7.198.30 - 1 | 505 | 501 | 10 | 31 | 1083 | 11 |
151.7.198.12 - 1 | 508 | 505 | 10 | 27 | 1027 | 12 |
151.6.7.34 - 1 | 512 | 510 | 15 | 28 | 1082 | 16 |
151.7.112.5 - 1 | 508 | 505 | 16 | 31 | 785 | 36 |

Stasera non sembra così pessimo, anche se ci sono picchi che poi in gioco si riflettono parecchio, un'ora fa insieme al gioco stavo guardando anche uno stream Twitch a 160p (quindi consumo quasi nullo) e l'ho dovuto chiudere perchè era ingiocabile, considerando che prima di questo problema riuscivo tranquillamente a vedere uno stream twitch sempre bassa-media qualità, un video youtube e anche un paio di client aggiuntivi di GW2 avendo 0 problemi, la differenza si sente.

Se il PL si propaga fino al server di destinazione probabile sia saturazione a livello di DSLAM. Anche quegli spike di 1000 ms e passa sono spia di possibile congestione. Stasera in effetti il PL (se di PL effettivo si tratta) è limitato al 1%.

Il DSLAM se sei in ULL è di Wind, quindi TIM non c'entra. Anche le info di Fibermap fanno riferimento all'infrastruttura TIM.

OUTATIME · 03-12-2023, 06:50

Quote:

Originariamente inviato da Fhom

Sicuramente lavori sul campo o hai informazioni più precise, personalmente non ho mai avuto problemi prima d'ora quando il packet loss era a posto, quindi per me è stato naturale associare questo comportamento al problema, come per altro è successo altre volte.

Faremo di necessità virtù.

Continuo a non spiegarmi.
Provo così: il packet loss non è la causa, ma un sintomo, quindi non so esattamente cos'hai segnalato a Wind, ma non puoi segnalare che hai delle perdite di ping per quanto ho scritto sopra, sarebbe come andare all'ospedale dicendo che si ha la camicia sporca di sangue. A parte questo, il massimo che fa il provider è verificare i valori di attenuazione della linea, di sicuro non si mette a giocare con le tabelle di routing o a sostituire apparati, specialmente su un DSLAM ADSL.

Ma in tutto questo, vedo che non hai mai parlato del tuo router. Marca e modello? Hai provato con un altro router?
Altra cosa, puoi scrivere qui l'IP del server che stai testando?

OUTATIME · 03-12-2023, 07:05

Quote:

Originariamente inviato da Psyred

Se il PL si propaga fino al server di destinazione probabile sia saturazione a livello di DSLAM.

Dipende, vedo che lui ha dei risultati tipo i miei, cioè un host successivo che ha meno PL di un host precedente:

Codice:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    3 |   41 |   40 |    2 |    5 |   35 |    2 |
|                   No response from host -  100 |    9 |    0 |    0 |    0 |    0 |    0 |
|                           172.17.80.150 -    3 |   41 |   40 |    6 |   10 |   57 |    6 |
|                            172.17.80.64 -    3 |   41 |   40 |   12 |   18 |  152 |   13 |
|                          172.19.184.138 -    0 |   44 |   44 |   12 |   14 |   47 |   14 |
|                           172.19.177.16 -    0 |   44 |   44 |    9 |   16 |  151 |   10 |
|                           172.19.177.11 -    3 |   41 |   40 |   10 |   15 |   76 |   11 |
|                            172.17.18.22 -    3 |   41 |   40 |    9 |   16 |   76 |   19 |
|host-217-141-21-30.business.telecomitalia     3 |   41 |   40 |   12 |   17 |   76 |   15 |
|                cr2-be2-701.it1.aruba.it -    0 |   44 |   44 |   17 |   19 |   45 |   18 |
|                    er2-be2.it1.aruba.it -    3 |   41 |   40 |   19 |   24 |   65 |   23 |
|host180-189-149-62.serverdedicati.aruba.it    3 |   41 |   40 |   17 |   20 |   57 |   20 |
|                          62.149.188.200 -    0 |   44 |   44 |   16 |   18 |   41 |   18 |

Addirittura io sulla destinazione (aruba.it) ho 0% di PL.

Psyred · 03-12-2023, 07:40

Quote:

Originariamente inviato da OUTATIME

Dipende, vedo che lui ha dei risultati tipo i miei, cioè un host successivo che ha meno PL di un host precedente:

Codice:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    3 |   41 |   40 |    2 |    5 |   35 |    2 |
|                   No response from host -  100 |    9 |    0 |    0 |    0 |    0 |    0 |
|                           172.17.80.150 -    3 |   41 |   40 |    6 |   10 |   57 |    6 |
|                            172.17.80.64 -    3 |   41 |   40 |   12 |   18 |  152 |   13 |
|                          172.19.184.138 -    0 |   44 |   44 |   12 |   14 |   47 |   14 |
|                           172.19.177.16 -    0 |   44 |   44 |    9 |   16 |  151 |   10 |
|                           172.19.177.11 -    3 |   41 |   40 |   10 |   15 |   76 |   11 |
|                            172.17.18.22 -    3 |   41 |   40 |    9 |   16 |   76 |   19 |
|host-217-141-21-30.business.telecomitalia     3 |   41 |   40 |   12 |   17 |   76 |   15 |
|                cr2-be2-701.it1.aruba.it -    0 |   44 |   44 |   17 |   19 |   45 |   18 |
|                    er2-be2.it1.aruba.it -    3 |   41 |   40 |   19 |   24 |   65 |   23 |
|host180-189-149-62.serverdedicati.aruba.it    3 |   41 |   40 |   17 |   20 |   57 |   20 |
|                          62.149.188.200 -    0 |   44 |   44 |   16 |   18 |   41 |   18 |

Addirittura io sulla destinazione (aruba.it) ho 0% di PL.

Nel tuo caso però il PL non si propaga fino al server di destinazione, quindi gli host precedenti sono probabilmente solo router che filtrano/accodano gli ICMP. Da quel che ho capito lui riscontra PL anche sul server di gioco. Per riprova potrebbe lanciare un ping ripetuto verso quel server (se non lo ha già fatto); immagino che il gioco stesso abbia un tool integrato che monitori la qualità della connessione.

OUTATIME · 03-12-2023, 08:09

Quote:

Originariamente inviato da Psyred

Nel tuo caso però il PL non si propaga fino al server di destinazione, quindi gli host precedenti sono probabilmente solo router che filtrano/accodano gli ICMP. Da quel che ho capito lui riscontra PL anche sul server di gioco. Per riprova potrebbe lanciare un ping ripetuto verso quel server (se non lo ha già fatto); immagino che il gioco stesso abbia un tool integrato che monitori la qualità della connessione.

Non so esattamente come funziona WinMTR, ma immagino che lanci una serie di ping tutti insieme verso tutti gli hop, almeno dal refresh sembrerebbe così. Vero è anche che un apparato da priorità ai pacchetti ICMP che passano, rispetto a quelli a cui deve rispondere lui stesso, ma mi aspetterei di vedere che in caso di "guasti" riscontrare PL su tutta la route in un determinato momento.
E per lo stesso motivo, ovvero il filtraggio degli ICMP, potrebbe accadere anche con ping verso il server di gioco.

Boh, ripeto, posso capire il disappunto per qualcosa che prima andava bene e poi no, ma IMHO il ping non è lo strumento idoneo per analizzare problemi di questo tipo, io inizierei dalle prove classiche:
- speedtest e raffronto dello stesso con la banda agganciata dal router
- reset del router
- test con un router differente
- verifica dell'antivirus e possibilmente test con antivirus disattivato

Psyred · 03-12-2023, 08:29

Quote:

Originariamente inviato da OUTATIME

E per lo stesso motivo, ovvero il filtraggio degli ICMP, potrebbe accadere anche con ping verso il server di gioco.

No di solito i game server non li filtrano. Per esperienza il packet loss rilevato dal gioco stesso nel 99% dei casi lo riscontri anche tramite un ping iterato verso il server in questione.

Io WinMTR lo uso principalmente per avere informazioni sulla possibile origine del PL, ma i risultati possono essere fuorvianti se non interpretati.

30-11-2023, 20:06	#1
Fhom Senior Member Iscritto dal: Nov 2006 Città: Perugia Messaggi: 429	WindTre Packet Loss Ciao a tutti, prima di tutto due domande generiche: - Da una settimana circa qualcuno ha problemi di packet loss (che non aveva prima) con WindTre? - C'è un modo per far sì che WindTre calcoli e risolva questo problema quando si fanno le segnalazioni? Ho un'ADSL ULL a Perugia, non ho quasi mai avuto problemi e di solito si sono risolti con intervento di un tecnico in centrale o dopo che hanno terminato lavori di zona. Siccome soddisfatto di questa linea e per "non rischiare" non mi sono azzardato a passare ad una FTTc (100) anche se sarei coperto. Da una settimana però ho packet loss, circa 2% misurandolo verso 8.8.8.8, i valori della linea sono sempre quelli classici e non ho altri problemi (disconnessioni ad esempio) che mi possano far pensare che sia un problema "fisico". Ho fatto due segnalazioni a WindTre ma non ho avuto successo, ci riproverò ma dubito che prendano in considerazione la cosa e l'unica speranza che ho è che sia un problema generale che verrà risolto a breve o, cosa che sto valutando, passare ad FTTc, ovviamente di altro operatore. Qualcuno sa dirmi qualcosa in merito o può fare qualcosa di più concreto? grazie

02-12-2023, 07:09	#3
OUTATIME Senior Member Iscritto dal: Dec 2007 Città: LIDV Messaggi: 11480	Già detto più di una volta: la perdita di pacchetti non è indicativa di problemi, comunque una segnalazione per il DSLAM ADSL non la prendono neppure in considerazione, si e no che abbiano ancora i ricambi. Passa in FTTC, e vista l'imminente dismissione del rame, se sei coperto in FTTH ti conviene fare il passaggio una volta del rame. __________________ Si stava meglio quando si stava peggio Ultima modifica di OUTATIME : 02-12-2023 alle 07:12.

02-12-2023, 19:57	#5
Psyred Senior Member Iscritto dal: Dec 2004 Messaggi: 15614	Prova a testare l'IP del server di GW2 (se lo conosci) con tool tipo WinMTR, magari riesci ad individuare i nodi con i picchi di latenza, o che perdono pacchetti. Se noti PL che si propaga dai primi hop fino al server di destinazione è possibile che si tratti di saturazione della rete W3 nella tua zona. D'altra parte con le ADSL in via di dismissione è normale che quella tecnologia sia trascurata. Se il DSLAM è saturo te lo tieni diciamo... Oppure passi a FTTC sperando che i problemi si risolvano. __________________ WindTre FTTH 2500/500 Mb (OF) - Fritz!Box 5590 Fiber [TEST][Latenze/Routing]

Strumenti
Mostra una versione stampabile Invia questa pagina per email