vamp è strano più che altro in notturna
Con cosa esegui le misure ?
Riprova banalmente da terminale con il Ping classico ICMP
vamp è strano più che altro in notturna
Con cosa esegui le misure ?
Riprova banalmente da terminale con il Ping classico ICMP
Temporanei.
Solitamente in qualche settimana si torna alla normalità.
vamp Con traceroute si vedono i percorsi?
Il trasporto OpenStream è trasparente, ma si vedrebbe la differenza fra gli hop di quando arrivi al MIX e poi passi sulla rete Dimensione per raggiungere destinazione.
gandalf2016 è strano più che altro in notturna
Se il nuovo percorso è "di fortuna" io mi aspetterei problemi anche in notturna a rete scarica.
@TheMarsican Ho aggiunto 2 traceroute al post, non so se sono sufficienti per capire
gandalf2016 speedtest cli direttamente dal router (anche da pc collegato con ethernet stessi problemi)
vamp
Fai come dice Gandalf2016, ping classico da CLI.
Ma da PC.
@gandalf2016 TheMarsican Grazie per tutte le informazioni, da pc ecco due test
14:21:20 ╰─❯ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=18.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=9.30 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=21.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=9.68 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=8.83 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=6.81 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=5.75 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=5.61 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=5.03 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=5.51 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=8.36 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=7.16 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=6.58 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=119 time=4.82 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=119 time=18.9 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=119 time=22.2 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=119 time=5.40 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=119 time=9.63 ms
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 18988ms
rtt min/avg/max/mdev = 4.823/9.839/22.183/5.481 ms
╰─❯ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=4.94 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=6.39 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=8.63 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=5.52 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=8.64 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=7.51 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=5.15 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=5.50 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=5.48 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=59 time=9.25 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=59 time=15.2 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=59 time=12.2 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=59 time=37.0 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=59 time=8.34 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=59 time=9.13 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=59 time=7.25 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=59 time=9.83 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=59 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=59 time=6.41 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=59 time=42.9 ms
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 18995ms
rtt min/avg/max/mdev = 4.936/11.352/42.891/9.914 ms
vamp
Non c'è perdita ma comunque una bella variabilità nei risultati.
Sinceramente non saprei a sto punto...
TheMarsican Già Ho provato a contattare il supporto di DImensione, ma hanno risposto che, se non rilevano disconnessioni o perdite di pacchetti, non possono inoltrare la segnalazione a Open Fiber, altrimenti i costi verrebbero addebitati a loro e, di conseguenza, anche a me. Mi hanno detto che potrebbero esserci degli instradamenti da parte di Open Fiber ma che non hanno modo di verificare. Non sono un esperto ma dai traceroute che ho postato si vedevano cose strane?
vamp Non sono un esperto ma dai traceroute che ho postato si vedevano cose strane?
Non particolarmente.
Sarebbe da confrontarli con quelli pre-problema, se ne hai.
vamp Mi hanno detto che potrebbero esserci degli instradamenti da parte di Open Fiber
Purtroppo a noi il trasporto OF è trasparente, quindi non possiamo vedere se si impiglia qualcosa.
@giusgius scusami se ti taggo, ma ho davvero bisogno del tuo aiuto.
Da diversi giorni sto riscontrando problemi con la mia connessione. Nonostante le velocità di download e upload siano generalmente buone, la latenza è estremamente instabile, con ping molto ballerino e valori di jitter elevati.
Questa situazione rende impossibile il gaming o svolgere qualsiasi attività che richieda una latenza stabile.
Ho eseguito numerosi test (che allego di seguito), tutti effettuati da un PC collegato via cavo Ethernet o direttamente al router.
Ho anche aperto un ticket, ma il tecnico ha minimizzato la questione, affermando che senza perdita di pacchetti "va bene così". Tuttavia, spesso i picchi di ping superano i 150 ms verso server situati a Milano, nonostante io viva vicino a Bergamo. Prima di questo problema avevo valori stabili di 3-4 ms con jitter sotto lo 0.3.
A mio avviso, questa situazione è davvero troppo compromettente. Potresti dare un’occhiata e verificare cosa sta succedendo?
Grazie mille in anticipo per la disponibilità!
Il ticket che avevo aperto ha il numero identificativo #487177
Da un mese che ho problemi, adesso questa è la situazione, ho provato a scrivere a @giusgius via mail ma nessuna risposta, il supporto dimensione minimizza. Non capisco, guardano solo la banda senza valutare la latenza.
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=77.925 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=136.520 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=184.890 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=55.227 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=59 time=119.977 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=59 time=209.226 ms
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
64 bytes from 1.1.1.1: icmp_seq=23 ttl=59 time=154.025 ms
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
64 bytes from 1.1.1.1: icmp_seq=25 ttl=59 time=1071.625 ms
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
Request timeout for icmp_seq 29
Request timeout for icmp_seq 30
Request timeout for icmp_seq 31
64 bytes from 1.1.1.1: icmp_seq=32 ttl=59 time=778.360 ms
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
64 bytes from 1.1.1.1: icmp_seq=35 ttl=59 time=880.036 ms
Request timeout for icmp_seq 36
64 bytes from 1.1.1.1: icmp_seq=37 ttl=59 time=475.404 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
64 bytes from 1.1.1.1: icmp_seq=41 ttl=59 time=1383.355 ms
64 bytes from 1.1.1.1: icmp_seq=43 ttl=59 time=851.812 ms
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
Request timeout for icmp_seq 47
64 bytes from 1.1.1.1: icmp_seq=48 ttl=59 time=865.657 ms
64 bytes from 1.1.1.1: icmp_seq=49 ttl=59 time=604.673 ms
64 bytes from 1.1.1.1: icmp_seq=50 ttl=59 time=759.955 ms
Request timeout for icmp_seq 51
64 bytes from 1.1.1.1: icmp_seq=51 ttl=59 time=1508.847 ms
^C
--- 1.1.1.1 ping statistics ---
54 packets transmitted, 17 packets received, 68.5% packet loss
round-trip min/avg/max/stddev = 55.227/595.148/1508.847/452.803 ms
vamp
Ma anche su altre destinazioni (ad esempio: 8.8.8.8 ed altri IP) hai questa situazione?
TheMarsican la storia del jitter alto sì, provato tanti server diversi verso milano, ma questa sera è tragica, come vedi continua a disconnettersi, due giorni fa per 3 ore niente internet. Ho provato anche a cambiare tutti i cavi ethernet ma stesso risultato
vamp Fai una misura con NeMeSys dovrebbe includere anche la latenza tra i parametri.
vamp
Intendevo che se fai ping o MTR verso altri server, come 8.8.8.8 appunto, se ottieni un packet loss alto e latenze alte.
Lorenzo1635 Grazie, provo
TheMarsican Sì, su tutti i server. Di solito il packet loss è inferiore rispetto a stasera, ma le latenze sono sempre elevate e, soprattutto, molto instabili
vamp
Segui il consiglio di @Lorenzo1635 ed in più raccogli le informazioni in maniera puntuale con i test fatti come si deve, crea un PDF e poi mandalo per PEC a Dimensione chiedendo delucidazioni in merito.
Non può essere che hai questa situazione.
In più visto che sei su BUL perchè non chiedi a qualcun altro attivo sempre su BUL se puoi effettuare qualche test?
Almeno vedi se è una cosa comune anche con ISP differenti.
TheMarsican Scusa il disturbo, la scorsa settimana Dimensione ha aperto una segnalazione con Open Fiber. Questa mattina sono arrivati i tecnici e, secondo loro, è tutto a posto. Hanno controllato solo la banda, ignorando completamente il problema della latenza, e hanno detto che su questo non possono intervenire. Durante i test, ho mostrato loro un ping verso Milano con picchi di 80ms, mentre prima era sui 3-4ms. La loro risposta è stata che dovrei cambiare operatore. Ma la rete non è comunque la stessa? Cambiando operatore pensi che qualcosa potrebbe migliorare?
@giusgius non mi ha mai risposto, quindi non so cosa bene cosa fare, adesso richiamo subito il supporto dimensione, ma la situazione è assurda.
Inoltre, i tecnici non sembravano molto competenti: continuavano a chiamare "modem" il router e sostenevano che il problema fosse quello. Ho spiegato che ho già testato collegandomi direttamente all'ONT per escludere il router, ma sembravano non capire. Sinceramente, sto perdendo le speranze.
vamp Sinceramente, sto perdendo le speranze.
Ci riprovo, hai fatto un test con NeMeSys? Quello che dura 2/3 giorni...
Perché il tuo problema è il packet loss
Lorenzo1635 sì, la situazione packet loss è migliorata, ci sono stati solo quei due giorni, non perdo più i pacchetti, ma la latenza bergamo-milano è altissima, soprattutto il jitter, non è per niente stabile. Ho fatto girare per 1 giorno nemesys e mi hanno anche rilasciato il certificato con scritto "Riscontrata violazione degli impegni contrattuali sul parametro: banda minima in download .. " ma in realtà sembra che la banda non l'abbia misurata correttamente (è l'unica cosa su cui non ho mai avuto problemi)
vamp è l'unica cosa su cui non ho mai avuto problemi
Non se NeMeSys và continuamente in timeout a quel punto 0 è valore corretto
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