View Full Version : Problema di instradamento, a chi compete?
Saluti a tutti.
Breve riassunto della vicenda:
paesino in provincia di Udine in piena zona anti-digital-divide.
Dopo tre anni di schifo telecom finalmente compaiono i primi fornitori wimax.
Ne scelgo uno molto popolare che generalmente riceve recensioni molto positive e attivo.
Tutto bene per nove mesi, poi comincia lo schifo pure con loro.
Io uso la connessione principalmente per videogiochi online e chat voip, seguiti da navigazione/video. Download poca roba.
Quindi le mie priorità sono ping e perdita dati.
Un mesetto fa comincio a notare gravi problemi di lag e rubberbanding giocando a battlefield 4 e, pur essendo piuttosto ignorante in materia, almeno sono in grado di fare qualche test con pingplotter.
Il risultato lascia pochi dubbi:
http://i.imgur.com/Z7G2bdO.png (http://imgur.com/Z7G2bdO)
Le colonnine rosse nel grafico orizzontale in basso indicano time-out e perdita dati completa sul secondo nodo (10.40.8.69). Rilevo inoltre una perdita dati costante, sullo stesso nodo, del 10-20%.
L'immagine allegata è un test fatto su google.it per mezzora con invio ping ogni 5 secondi. I risultati sono uguali con qualsiasi altra destinazione: il problema è sempre sul secondo passaggio.
Ovviamente chiamo l'assistenza e, dopo un mese di boiate "per noi è tutto a posto, ping perfetto, perdita dati nulla", finalmente un tecnico (ridicolo definirli tecnici) mi dice che quel passaggio è un server internazionale su una tratta non di loro competenza. Non mi è dato sapere dove.
In pratica, i test che loro fanno verso di me non passano da lì e risulta tutto a posto. La mia connessione, invece, verso OVUNQUE, passa sempre da quell'ip, perdendo continuamente dati.
Veniamo alle domande:
-perchè tutti i miei dati passano di la?
-come faccio a capire dov'è quell'ip?
-perchè la mia connessione viene dirottata chissà dove, nel passaggio immediatamente successivo alla tratta di competenza del fornitore?
-se il problema non dipende da me e non dipende dal fornitore, da chi dipende?
-come lo risolvo?
-è normale una cosa del genere?
Grazie a tutti
lorenzo.c
17-04-2014, 18:43
10.40.8.69 e' un IP privato che collega il primo hop al secondo (il gateway di Eolo all'internet exchange), e' una pratica che si utilizza per non sprecare IP pubblici sui transiti. Non puoi intervenire per risolvere, quel che viene dopo "eolo-gw.net.ngi.it" non e' di competenza tua ma del provider. :)
Loro dicono che non è loro competenza e che è un ip internazionale.
Mi pare abbastanza evidente che sia una boiata colossale, dato che anche il ping sul loro server di test (tre passaggi totali) passa di la.
Come faccio a farglielo capire?
Mi stanno prendendo in giro?
Loro dicono che non è loro competenza e che è un ip internazionale.
Mi pare abbastanza evidente che sia una boiata colossale, dato che anche il ping sul loro server di test (tre passaggi totali) passa di la.
Come faccio a farglielo capire?
Mi stanno prendendo in giro?
ip internazionale? :asd:
Più che farglielo capire (spiegare ad un ISP come funziona il routing, paradossale), ti tocca "alzare i toni" e dargli un ultimatum, che se il problema non viene risolto, passerai alla concorrenza. Mandagli tutti i rilevamenti che hai effettuato e un resoconto dettagliato del disagio provocato.
Tanto per chiarire se ho capito bene io. Correggetemi se ho capito cazzate.
I primi due ip sono sempre gli stessi, a prescindere dalla destinazione (questo è certo).
Il primo ip è il loro gateway.
Il secondo ip è un loro ip privato di transito (cercando con google mi è addirittura uscito che è nel golfo di guinea :rolleyes: ).
Il terzo è un internet exchange e dal terzo a seguire il percorso varia a seconda della destinazione ed è fuori dalla loro competenza.
Cambiando destinazione dei test, è corretto presumere che tutti i passaggi da me al dns primario siano di loro competenza?
Questo è il test verso il dns primario (il terzo è 100% pl fisso perchè è protetto, giusto?):
http://i.imgur.com/C3AVH3m.png (http://imgur.com/C3AVH3m)
Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?
Quel ip privato...sembra quasi che di transito ci sia la rete di un altro ISP (fastweb?) e il punto in questione risulta congestionato (aka i pacet loss) o semplicemente degradato layer 1/2 (meno probabile). Dato che è un punto di passaggio obbligatorio a quanto sembra, non instraderanno su altri percorsi, o perlomeno non hanno necessità di scomodare il provider di transito (?), a cui potrebbero dover pagare altri punti di transito verso il sistema autonomo di NGI (il suo core).
A parte la supercazzola, il shield con loss 100% sembra il firewall di bordo (edge firewall), dove nel prossimo hop segue il core di NGI ( dove si trova il dns nsr1).
Solo ipotesi, ma se vere, non risolverai il problema nemmeno minacciandoli.
Beh, le strade possono essere diverse, dipende dalle policy che usano lì gli ISP.
Dovrebbero fare il test da te. Altro caso potrebbe essere un NAT sempre configurato a livello ISP e a questo punto a loro risulta un altro indirizzo, che dalla tua parte viene invece tradotto.
Oppure semplicemente l' ip privato è dentro la loro rete e fanno finta di nulla, visto che probabilmente siete in pochi a lamentarvi e loro sicuramente non modificheranno la configurazione per 4 gatti.
wizard1993
17-04-2014, 22:53
Cambiando destinazione dei test, è corretto presumere che tutti i passaggi da me al dns primario siano di loro competenza?
no. Anzi, assolutamente improbabile. Da Udine a Milano (Dove mi risulta abbia fisicamente sede ngi con i propri server) non credo proprio abbiano le loro dorsali. Al 99% passano da Telecom che seguirà percorsi e politiche di traffico proprie
Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?
Non necessariamente... Può anche essere che il gateway "locale" della tua zona sia connesso a più nodi differenti come bilanciamento del carico o che so io
lorenzo.c
17-04-2014, 23:00
Il secondo ip è un loro ip privato di transito (cercando con google mi è addirittura uscito che è nel golfo di guinea ).
E' un IP privato nel senso che non e' pubblicamente indirizzabile. E' un indirizzo di una rete privata, come il tuo 192.168.1.1 per capirci.
Quoto il fatto che sia semplicemente quel link ad essere congestionato, pare anche a me sia su Fastweb (di solito loro usano 10.x.x.x). :)
Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?
Non necessariamente, i percorsi per il traffico verso eolo-gw.net.ngi.it possono essere multipli. E comunque piano con gli insulti :p
Intanto grazie a tutti. Il terzo hop fisso al 100% non l'ho proprio considerato dato che è sicuramente protetto.
Dopo l'ultimo ticket di ieri sera hanno finalmente ammesso (testuale): "c'è una possibilità che la mia diagnosia sia stata errata".
E mi hanno chiesto di mandargli i risultati dei test fatti verso 8.8.8.8 per ricostruire che giri fa la mia linea.
Sto vedendo ora e mi sembra un dns pubblico di google. Cambia poco, tanto i primi due hop sono sempre gli stessi: gateway e l'ip intasato, che continua ad andare in time-out.
Sono episodi come questo che mi stanno veramente disgustando. Pare che su questo mercato non ci sia niente di regolamentato in modo chiaro e univoco. Impossibile capire da chi dipende un problema. Impossibile avere una garanzia su ping e packet loss, come se la banda fosse l'unica cosa che conta.
Gli insulti se li meritano tutti. Vogliono passare come alternativa "giovane" ai grossi provider mafiosi ma usano esattamente gli stessi metodi.
wizard1993
18-04-2014, 13:08
Sto vedendo ora e mi sembra un dns pubblico di google. Cambia poco, tanto i primi due hop sono sempre gli stessi: gateway e l'ip intasato, che continua ad andare in time-out.
Non vorrei "smontarti" ma è piuttosto normale che gli apparati non rispondano al ping (e quindi ad un traceroute)... glielo si disabilita volutamente per motivi di sicurezza
Penso che se fosse una questione di sicurezza mi segnerebbe perdita 100% costante ad ogni ping, come il terzo hop.
Esempio:
http://i.imgur.com/NbaRvGC.png (http://imgur.com/NbaRvGC)
Sul secondo invece è casuale. Non è in time-out perenne. A volte passa, a volte perde il 10-20%, a volte va in time-out.
Sbaglio?
Ci posti le statistiche dopo qualche ora, di mtr?
http://www.bitwizard.nl/mtr/
Sul mio linux -> apt-get install mtr
e poi lanci mtr www.google.it
e lasci andare un paio d'ore.
Poi ci posti lo screenshot.
Sul secondo invece è casuale. Non è in time-out perenne. A volte passa, a volte perde il 10-20%, a volte va in time-out.
Sbaglio?
O link congestionato oppure icmp traffic limiter impostato.
lorenzo.c
18-04-2014, 15:58
Sembra anche a me che shield1-ext limiti l'ICMP, questo un traceroute verso maya.ngi.it:
http://s2.postimg.org/47ym0rs6h/ping.png
Thread opener, procuraci i dati anche da http://netalyzr.icsi.berkeley.edu/
Aspetta che completi il test e posta.
Scusa se sono incapace io, ma non sto capendo cosa devo fare per usare mtr.
Netanalyzr avevo completato il test ma ho chiuso la pagina per sbaglio e ora non mi apre più un razzo.
Intanto l'ultima risposta che ho avuto dal'assistenza NGI (tanto ormai si è capito che sono loro), dopo che gli ho mandato i test fatti verso 8.8.8.8
da verifiche incrociate con i colleghi del reparto di networking è emerso che non vi sono nostre anomalie sulla tratta. In questi giorni si sta verificando una saturazione verso il mix di google che falsa i risultati. Inoltre quello che avevo erroneamente indicato come un ip esterno è l'ip di un nostro apparato che smista le nostre connettività. Quello è il suo compito e il fatto che eseguendo ping o ping flood verso di esso scarti non implica nessun anomalia, semplicemente non è la sua priorità rispondere alle azioni prima citate. La cosa attendibile al momento è semplicemente effettuare un test all'indirizzo http://test.ngi.it e verificarne latenza e prestazioni di banda, ma dovrebbe funzionare correttamente difatti nel grafico che ci ha riportato non vi sono mai packet loss o latenze anomale verso l'indirizzo finale 88.149.128.130
Mi sa tanto di presa per il culo, ma ditemi se sto capendo male io.
Prima parte:
prima mi fanno fare un test verso un dns google, poi mi dicono che guarda caso questi giorni il mix di google ha problemi.
Questo è il test:
http://i.imgur.com/hfkmSou.png (http://imgur.com/hfkmSou)
Qua le cagate mi sembrano due, e belle grosse:
1- sul mix di google rilevo problemi molto sporadici
2- la mia connesione fa schifo verso ovunque, non solo google
Seconda parte:
intanto ammettono di avermi rifilato una cazzata (l'ip internazionale). Poi praticamente vogliono farmi credere che gli unici problemi seri che rilevo sono su roba loro, ma i test non sono attendili perchè non è priorità di quell'apparato rispondere ai ping.
Io posso misurare verso qualsiasi destinazione e rilevare problemi SOLO LI. Ma sono problemi immaginari perchè non è compito di quell'apparato.
Quindi io per quale motivo non riesco a farmi mezzo round di battlefield senza farmi venire la nausea?
Io ho bisogno dei dati che ti ho chiesto.
Rifai il netalyzer con altro browser/su altro dispositivo e posta la pagina.
Per mtr. Sei su linux, mac o windows?
Per windows qui http://winmtr.net/
Comunque è realistico ciò che dicono a proposito del router 10.x.x.x
Non è proprio tenuto a rispondere a tutti i ping, aka, applicano il QoS dando priorità ad altro traffico e limitando di conseguenza ICMP.
Poi dimenticavo, per le domande:
1. Infatti. Mi sembra normale.
2. Probabilmente fa schifo verso ovunque. Ma è da testare.
Inoltre quello che avevo erroneamente indicato come un ip esterno è l'ip di un nostro apparato che smista le nostre connettività.
Intanto mi rifaccio due risate :asd:
Windows, scaricato.
Verso dove vuoi che misuro con mtr?
L'altro vedo di rifarlo.
Ti mando pm con i risultati di netalyzr, che mi sembrano un po' troppo dettagliati per pubblicarli per tutti.
Intanto faccio partire mtr.
Ma ho anche fatto un'altro test, sempre con pingplotter ma verso un server tedesco di battlefield 4.
Direi che anche il loro core ha qualche problemino :rolleyes:
http://i.imgur.com/JkpfcSf.png (http://imgur.com/JkpfcSf)
EDIT: ovviamente nessuna fretta nella risposta, tanto con questi se ne parla martedì
Uhm, da questo grafico di pingplotter sembra abbiano qualche problema di congestione.
Escludendo ovviamente il icmp traffic limiting. Ma il fatto che lo stiano limitando lascerebbe presupporre che effettivamente la congestione ci potrebbe anche essere. Per ora ipotesi.
Dopo ti aggiorno sul resto delle osservazioni.
Fai anche uno speedtest, occulta l'indirizzo ip quando mi posti lo screenshot.
Fallo qui il test http://speedtest.mclink.it/
Allora netalyzer è regolare in quanto a latenze e il resto. Hai poca banda, dw 4,8 mega e up 0,200 mega, ma quello ci puoi fare poco.
Testiamo un po' la mtu. Lì mi dice che è settata a 1492, ma a livello di ngi avviene la frammentazione del pacchetto (su ip 81.174.0.238).
Vai su Start -> Esegui -> CMD -> Invio
Poi comando: ping www.google.it -f -l 1492 a scendere (minimo 1400, max 1500)
Fermati quando non ti dà più il "fragmentation required" e ti segnala solo "Risposta da ipxxxx".
Hai letto anche qui?
http://bf4central.com/2014/03/battlefield-4-rubber-banding/
E' andato a 1452
Esecuzione di Ping www.google.it [173.194.70.94] con 1452 byte di dati:
Risposta da 173.194.70.94: byte=64 (inviato 1452) durata=27ms TTL=52
Risposta da 173.194.70.94: byte=64 (inviato 1452) durata=29ms TTL=52
Risposta da 173.194.70.94: byte=64 (inviato 1452) durata=27ms TTL=52
Risposta da 173.194.70.94: byte=64 (inviato 1452) durata=56ms TTL=52
Statistiche Ping per 173.194.70.94:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 27ms, Massimo = 56ms, Medio = 34ms
Sulla banda poco da dire, rispetta i valori contrattuali:
http://i.imgur.com/INz3NRG.jpg (http://imgur.com/INz3NRG)
EDIT: si, so che battlefield ha seri problemi per conto suo e li ha sempre avuti. Ma da un mesetto mi è peggiorato di brutto e sto avendo problemi anche su altri giochi. Ad esempio le due ore che ho resistito su elder scrolls online.
Ok, prova a impostare quel mtu sul router. Occhio, che forse dovrai riavviarlo.
Lo speedtest è ok. Il ping è nella norma.
Hai verificato il pc per eventuali virus e altri ladri di banda (es. torrent)?
Vai su cmd, e fai netstat. Posta il risultato o mandamelo in pvt.
Fammi una serie di ping verso google.
cmd -> ping www.google.it -t
Dopo 1 minuto ferma il test e postami il risultato.
Non ho router, ho il cavo dell'antenna collegato direttamente al pc.
Niente virus e la banda è libera (solo un paio di pagine aperte senza video).
Netstat sto tentando di capire come copiare tutto (quando finisce non riesco a scrollare su fino all'inizio)
Questi intanto sono i ping su google.it:
Esecuzione di Ping www.google.it [173.194.70.94] con 32 byte di dati:
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=29ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=29ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=31ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=47ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=61ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=127ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=41ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=40ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=38ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=29ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=36ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=34ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=41ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=29ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=32ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=36ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=38ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=36ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=32ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=34ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=39ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=67ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=39ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=41ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=30ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=39ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=34ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=36ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=33ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=28ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=33ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=47ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=34ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=30ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=27ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=34ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=43ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=35ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=22ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=23ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=30ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=24ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=26ms TTL=52
Risposta da 173.194.70.94: byte=32 durata=25ms TTL=52
A parte lo sbalzo dei 127ms, il ping è ok.
Vediamo il netstat.
Senti un po', ma bf4 lagga sempre? Ci sono momenti particolari in cui è peggiore?
EDIT, dimenticavo.
setta la mtu sul windows. Segui la guida http://my.bergersoft.net/2010/05/13/how-to-change-mtu-size-on-windows-xpvista72008/
Mandato netstat via pm.
Bf4 ha sempre avuto problemi, in particolare sulle mappe dell'ultima espansione.
Ma è peggiorato di brutto nell'ultimo mese. E' evidente che non sono i soliti problemi del gioco, anche perchè per me è ingiocabile anche nelle modalità che agli altri non danno problemi.
Nel mio caso è stato un peggioramento improvviso. Parlo di roba evidente, tipo pg che corre sul posto o mi schizza indietro.
Poi mi è diventata ingiocabile anche altra roba tipo elder scrolls online (quel poco che ho resistito, veramente pessimo).
Sembra regolare.
Hai mica avast installato?
Si, avast.
Dato che devo riavviare per cambiare la mtu, ho stoppato mtr.
Risultati:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| eolo-gw.net.ngi.it - 0 | 5653 | 5653 | 11 | 20 | 337 | 31 |
| 10.40.8.69 - 10 | 4047 | 3645 | 11 | 20 | 263 | 16 |
| garr.mix-it.net - 1 | 5646 | 5644 | 11 | 23 | 339 | 20 |
| r-mi2-r-rm2.rm2.garr.net - 1 | 5638 | 5634 | 11 | 30 | 441 | 28 |
| rx2-mi2-rx2-rm2.rm2.garr.net - 1 | 5642 | 5639 | 22 | 34 | 205 | 28 |
| rx2-rm2-ru-dir-l1.rm2.garr.net - 1 | 5642 | 5639 | 24 | 32 | 404 | 38 |
| lx1.dir.garr.it - 1 | 5631 | 5625 | 24 | 34 | 400 | 39 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Uhm, si legge malino. Hai modo di postare lo screen di mtr?
Dopo disinstalla avast e prova bf4.
http://i.imgur.com/GYv5jWW.jpg (http://imgur.com/GYv5jWW)
Provo a togliere avast.
EDIT: mtu cambiata e avast disinstallato. Pingplotter mi rileva il solito disastro, ora provo 2 minuti su battlefield
MTR tutto a posto.
Se pinghi da cmd l' ip 10.40.8.69, vedi dei ping che falliscono?
Provato bf4, mi pareva meglio del solito. Sempre pessimo, ma potrebbero essere i problemi suoi e non della connessione.
Col ping tutto ok a parte l'occasionale laggata:
Microsoft Windows [Versione 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.
C:\Users\Andrea>ping 10.40.8.69 -t
Esecuzione di Ping 10.40.8.69 con 32 byte di dati:
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=13ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=12ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=12ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=17ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=109ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=18ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=12ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=12ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=22ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=17ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=22ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=13ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=22ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=25ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=14ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=28ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=27ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=34ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=16ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=13ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=13ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=15ms TTL=254
Risposta da 10.40.8.69: byte=32 durata=19ms TTL=254
Ma pingplotter continua a rilevarmi un disastro sul core ngi.
Ti confermo che per il core e il 10.xxxxx viene usato il limiter su icmp. Praticamente ti rispondono quando non sono troppo occupati a passare il traffico.
Ovviamente gli icmp echo request passano, ma non ti viene garantita la risposta al ping, il icmp echo reply.
Ping sopra nella norma.
PS. In parole povere, non sussiste alcun disastro nel loro core.
Ok, quindi pure se pingplotter mi rileva un macello su quei due passaggi, non dimostra niente.
Mi resta da provare per qualche giorno come va con la mtu reimpostata e senza avast. Vedo da qui a lunedì come va, poi eventualmente torno con altri aggiornamenti.
Intanto grazie per l'aiuto e per il tempo perso.
Ultima cosa: che antivirus consigli?
Prego ;)
Uhm con gli antivirus ho un rapporto strano io. Per esempio, il mio pc gaming non ha antivirus perchè potrebbe rallentarmi.
Dipende. Kaspersky chiappa quasi tutto, ma è un macigno. Il nuovo antivir sembra discreto. Avast mi pare pesantuccio e avg chiappa poco. Microsoft essential è minimale ma leggero, così come immunet e panda cloud. Io consiglio NOD32, un discreto rapporto protezione/prestazioni.
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.