NetDiag+
Prove che il tuo operatore non può liquidare
«La sera internet è lento» è una sensazione, e l'assistenza è addestrata a rispondere alle sensazioni con un riavvio del router. Un numero con un luogo e un'ora è un'altra conversazione: la perdita di pacchetti inizia al mio terzo hop ogni sera dopo le nove, ecco le esecuzioni. Tre misure fanno quel lavoro — dove inizia la perdita, come si comporta la latenza sotto carico e quanto sono lontani e instabili i server che usi davvero — e da NetDiag+ 1.4.6 ognuna si esporta come testo semplice da incollare in un ticket, in un forum o nel modulo dell'autorità.
Tre misure che indicano un luogo e un'ora
- Localizza la perdita con MTR. Un traceroute che continua a pingare ogni hop mostra dove i pacchetti iniziano a sparire. La perdita che inizia a un hop e persiste fino alla fine è reale, e quell'hop indica la rete responsabile. La perdita su un solo hop che sparisce al successivo è quel router che limita le proprie risposte — normale, non è una prova. Eseguilo nell'ora cattiva e annota l'hop.
- Aggiungi la latenza sotto carico e la tabella della latenza. Un test di bufferbloat dice di quanto sale la latenza con la linea occupata e in che direzione: un picco in upload punta al tuo router, un picco in download alle apparecchiature dell'operatore — e quella direzione decide di chi è il problema. Il Pannello latenza aggiunge mediana, jitter e perdita verso i server che usi, misurando prima il tuo router così nessuno può incolpare il tuo Wi-Fi se è pulito.
- Esporta come testo, alle ore giuste, più di una volta. Ogni strumento ha Condividi → report testuale: destinazioni, orari, ogni numero. Un'esecuzione non dimostra nulla; tre nell'ora cattiva in giorni diversi più una in un'ora tranquilla come controllo sono uno schema. Il grafico di tendenza del bufferbloat conserva il picco peggiore di ogni esecuzione su 7, 30 o 90 giorni, così lo schema si vede senza prendere appunti. La cronologia conserva tutto ciò che hai eseguito.
Gratis · 27 strumenti · acquisto singolo per togliere la pubblicità · nessun abbonamento
Domande che la gente fa davvero
Cosa deve contenere esattamente il ticket?
Date e orari di ogni esecuzione. L'hop dove inizia la perdita e la sua percentuale. Latenza a riposo contro latenza in download e in upload. Mediana e jitter verso due o tre server che la tua casa usa. Quale test era il controllo. Tutto incollato come testo, non descritto — un tecnico può agire su una lista di hop, non su «scatta».
L'assistenza dice che la linea è a posto. Mentono?
Di solito no. I loro test controllano livelli di segnale, contatori di errori e throughput, e tutto ciò può essere perfetto mentre una coda aggiunge 300 ms o un link di peering congestionato scarta il 2% dei pacchetti alle nove di sera. Stai misurando qualcosa che loro non misurano. Dillo, e passa loro i numeri.
Screenshot o testo?
Testo. Si può cercare, citare, incollare in uno strumento interno e inoltrare all'ingegnere che ripara davvero; uno screenshot no. Il testo sopravvive anche alla compressione delle immagini di un forum e al modulo web di un'autorità. Gli screenshot tienili per te.
Quante esecuzioni fanno un caso?
Abbastanza per mostrare che il problema è ripetibile e legato all'ora. Tre esecuzioni nell'ora cattiva in due o tre giorni, più una in un'ora buona che torna pulita, è il minimo che trasforma una lamentela in un rapporto. Se anche quella nell'ora buona è cattiva, la causa non è la congestione — utile anche questo.
Serve davvero a far riparare qualcosa?
Sposta il ticket dal primo livello a qualcuno che sa leggere una lista di hop, che è il passaggio dove di solito si blocca. Dove esiste un'autorità, i moduli di reclamo chiedono esattamente questo: date, misure, cosa ha risposto l'operatore. Le prove non garantiscono una riparazione; tolgono le ragioni per dire no.
Il singolo numero più forte in tutto questo è la latenza sotto carico. Prossimo: quale server è lontano e quale instabile →