Witam. Ostatnimi dniami internet znacząco spowolnił. Podczas wizyty na ts’ie zobaczyłem, że tracę dużo pakietów. Dostawcą jest Vectra. Jak sprawdzić czy wina leży po mojej czy dostawcy zanim do nich zadzwonię? Pozdrawiam! 
Spinguj dowolny serwer i zobacz czy są jakieś straty pakietów.
Wyskoczyło mi takie coś. Czyli coś tam tracę. Tylko teraz jak sprawdzić czy to vectra je gubi, czy może ja mam coś zepsute?
Z góry wielkie dzięki za zainteresowanie!
Badanie google.com [173.194.112.206] z 32 bajtami danych:
Odpowiedź z 173.194.112.206: bajtów=32 czas=52ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=57ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=51ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=64ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=68ms TTL=54
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 173.194.112.206: bajtów=32 czas=56ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=61ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=50ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=64ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=64ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=55ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=51ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=56ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=50ms TTL=54
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 173.194.112.206: bajtów=32 czas=58ms TTL=54
Odpowiedź z 173.194.112.206: bajtów=32 czas=58ms TTL=54
Statystyka badania ping dla 173.194.112.206:
Pakiety: Wysłane = 20, Odebrane = 16, Utracone = 4
(20% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 50 ms, Maksimum = 68 ms, Czas średni = 57 msUżyj tracert i zobacz gdzie giną pakiety
Tracert dla google i dobrepogramy. Nic z tego nie rozumiem. Mam nadzieję, że wy jesteście w stanie to odszyfrować 
Śledzenie trasy do google.com [173.194.116.103]
z maksymalną liczbą 30 przeskoków:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 6 ms * * 10.137.0.1
3 * * * Upłynął limit czasu żądania.
4 24 ms 24 ms * 172.17.28.14
5 * 28 ms 28 ms 172.17.28.14
6 * 51 ms 53 ms core2.ams.net.google.com [80.249.209.100]
7 * * * Upłynął limit czasu żądania.
8 50 ms * * 72.14.238.153
9 53 ms 56 ms 62 ms 209.85.240.143
10 * 77 ms * 209.85.251.249
11 53 ms * * 64.233.175.143
12 56 ms 58 ms 61 ms 173.194.116.103
Śledzenie zakończone.
C:\Users\Rafi>tracert dobrepogramy.pl
Śledzenie trasy do dobrepogramy.pl [185.53.178.18]
z maksymalną liczbą 30 przeskoków:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * 5 ms 5 ms 10.137.0.1
3 6 ms 6 ms * 172.17.148.9
4 * * * Upłynął limit czasu żądania.
5 * 22 ms 27 ms 172.17.28.214
6 21 ms 23 ms 20 ms te-4-3.car1.Warsaw3.Level3.net [213.242.118.5]
7 50 ms * * be3356.agr21.ams03.atlas.cogentco.com [130.117.14.41]
8 * * * Upłynął limit czasu żądania.
9 * 55 ms 52 ms be2261.ccr41.fra03.atlas.cogentco.com [154.54.37.30]
10 54 ms 54 ms 55 ms be2228.ccr21.muc01.atlas.cogentco.com [154.54.38.50]
11 56 ms 57 ms 56 ms te0-0-0-2.agr11.muc01.atlas.cogentco.com [130.117.50.10]
12 * 58 ms 56 ms 154.25.2.217
13 * 55 ms * 149.6.156.194
14 56 ms 56 ms 58 ms 185.53.178.18
Śledzenie zakończone.Jeśli router nie odrzuca pakietów icmp, to problem leży po stronie ISP. Strata pakietów jest na trzecim skoku. Możesz użyć jeszcze programu WinMTR do dokładniejszego pomiaru.
Oczywiście zakładam, że na trzecim skoku jest router ISP, a nie Twój.
Podłączenie u mnie wygląda tak:
kablem do modemu Cisco EPC3008 od Vectry, potem ethernet’em do routeru TP-LINK WR941N, później ethernetem do PC.
Jeżeli jest to wina dostawcy, to proszę o napisanie. Zadzwonię jeszcze dzisiaj.
google:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 42 | 42 | 0 | 0 | 0 | 0 |
| 10.137.0.1 - 39 | 18 | 11 | 7 | 15 | 32 | 32 |
| 172.17.148.9 - 47 | 15 | 8 | 6 | 10 | 22 | 6 |
| 172.17.28.14 - 42 | 17 | 10 | 26 | 34 | 58 | 35 |
| 172.17.28.14 - 42 | 17 | 10 | 22 | 33 | 58 | 36 |
| google.plix.pl - 32 | 19 | 13 | 23 | 31 | 47 | 38 |
| 46.28.247.114 - 39 | 18 | 11 | 26 | 33 | 50 | 50 |
| ________________________________________________|______ | ______|______ | ______|______ | ______ |
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
dobreprogramy:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 20 | 20 | 0 | 0 | 0 | 0 |
| 10.137.0.1 - 38 | 8 | 5 | 5 | 17 | 28 | 20 |
| 172.17.148.9 - 38 | 8 | 5 | 9 | 19 | 29 | 21 |
| 172.17.28.14 - 58 | 7 | 3 | 27 | 33 | 37 | 36 |
| 172.17.28.14 - 38 | 8 | 5 | 25 | 37 | 48 | 48 |
| xenium.plix.pl - 58 | 7 | 3 | 24 | 31 | 35 | 35 |
| nlb-web.xenium.pl - 38 | 8 | 5 | 27 | 37 | 47 | 38 |
| ________________________________________________|______ | ______|______ | ______|______ | ______ |
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud ProviderStraty pakietów wg tracert zaczynają się na drugim skoku. WinMTR również pokazuje utraty pakietów. Według połączenia, które opisałeś, wynika że straty pakietów są między TP Linkiem, a modemem. Spinguj adres 10.137.0.1 i zobacz czy będą jakieś straty pakietów. Jeśli tak, to odłącz TP Linka i sprawdź przy połączeniu modem > PC. Jeśli i tu będą straty pakietów, sprawdź na innym kablu sieciowym. Jeśli nadal będą, odłącz na parę minut modem z prądu i podłącz ponownie. Jeśli nic z tych rzeczy nie pomoże, to modem prawdopodobnie do wymiany.
Trzeba brać pod uwagę, że routery dostawcy mogą celowo odrzucać część pakietów icmp, WinMTR dość intensywnie testuje połączenie.