Lassú internet kimutatása

Web, mail, IRC, IM, hálózatok

Sziasztok!

Az utóbbi időben egyre lassabb az internet elérésem. Azaz egy oldal akár fél percig is töltődik, ekkor a firefox azt írja ki, hogy looking up xy.hu, majd hirtelen betölt.
A sebességmérő oldalak nem mutatnak kirívó lassúságot, valahogy nekem az a benyomásom, hogy a kapcsolat létrehozása ami nem gördülékeny. Bár a youtube videóknak is több idő kell töltődéshez, akadoznak.

Mivel mutathatnám ezt ki?

A google névszervereit használom. Őket pingelve a válasz 30-160 ms között mozog.

  • 7642 megtekintés

( bucko | 2014. 12. 06., szo – 00:39 )

Elég körmönfont teszt a névszervert pingetni. :)
De álljon itt egy példa:
ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=9.562 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=7.702 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=10.194 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=7.335 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=7.565 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.335/8.472/10.194/1.171 ms

Persze ebből nem derül ki semmi!

Viszont volt hasonló esetem.
Pont ilyen történik, ha a gateway latency 8-10ms helyett súrolja az (akár) 1000ms-ot is.

( XMI | 2014. 12. 06., szo – 00:52 )

Ha a looking up-ban var sokat, akkor en DNS lassusagra (esetleg timeoutra) gyanakodnek elsore.

Hogy pontosan hol mennyi idot tolt, azt ezzel a paranccsal le lehet kovetni: 


curl --location -v http://google.com 2>&1 | while read line; do echo "$(date '+%H:%M:%S.%N' ) $line"; done | less

A google-t ertelemszeruen le lehet cserlni az aktualisan lassu weboldalra, de nyilvan nem celszeru index.hu es hasonlo tobb MB-os kezdooldallal rendelkezo site-okkal kiserletezni.

(valoszinuleg lehetne szebben is, kevesebb overheaddel is, most kb 1 percet szantam ra)
---
Régóta vágyok én, az androidok mezonkincsére már!

"Ha a looking up-ban var sokat, akkor en DNS lassusagra (esetleg timeoutra) gyanakodnek elsore."

+1

Kerdezo: probald a gugli DNS-et hasznalni: https://developers.google.com/speed/public-dns/

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( Sanya v | 2014. 12. 06., szo – 06:48 )

hálókártya-router típusa?
indíts el a háttérben egy "ping átjáró -t"
valamint egy ping "DNS SZERVER" -t
és egy ping "hup.hu" -t parancsot. mely kezd el hibázni és húzza magával a többit? ( sry trey a hup pingeltetésért :)

A router egy modem-router, D-link a szolgáltatótól (T-).

Van a hálón két switch, az egyik TP-link (Openwrt) a másikat nem tudom, de a lan okés:
--- 192.168.1.1 ping statistics ---
2000 packets transmitted, 2000 received, 0% packet loss, time 1999010ms
rtt min/avg/max/mdev = 0.496/1.122/54.519/3.392 ms

Viszont a net felé:
--- 8.8.4.4 ping statistics ---
1000 packets transmitted, 857 received, 14% packet loss, time 1001257ms
rtt min/avg/max/mdev = 4.637/22.210/323.149/28.238 ms

Ez a modem a padláson volt és arra gyanakodtunk, hogy a hideg lehet az oka, de lehozva sem javult a helyzet.

( zeller | 2014. 12. 06., szo – 14:06 )

Melyik szolgáltató, milyen OS, a böngésző melyik verziója, milyen plusz sallangok vannak a tudtoddal hozzáadva (és mik a tudtod nélkül), stb.

( answ | 2014. 12. 07., v – 10:34 )

Ugye nincsen IPv6 sehol sem a hálózatodban (még tunnelként sem)?

( bigacsiga | 2014. 12. 10., sze – 10:45 )

A padláson, hideg helyen vannak szűrők, mert a TV és az internet egy koax kábelen jön be a házba.
Ott ágazódik szét adatra és TV-re (ezek a feliratok a szűrőn).

Lehet az, hogy ez a cucc hidegben hibázik?
LAN-on nem tudok hálózati hibát kimutatni, a net felé viszont folyamatos a veszteség.
(Smokepingből adatsorok hamarosan! :) )

"Lehet az, hogy ez a cucc hidegben hibázik?
LAN-on nem tudok hálózati hibát kimutatni, a net felé viszont folyamatos a veszteség."
Előzőleg ezt írtad: "Ha Windowsos (8) gépet rákötök direktben a szolgáltató D-link Modemrouterére, akkor a ping csomagveszteség nélkül végigmegy."
Ebből az következne, hogy sem a szűrő, sem a D-Link router nem befolyásolja negatívan.

"rtt min/avg/max/mdev = 0.496/1.122/54.519/3.392 ms"
Azért az a maximumérték (54,5 msec), és a 3,4 körüli szórás kicsit soknak tűnik LAN-on. Ha ezt az előző megállapítással (közvetlen D-Link - Windows kapcsolatnál jó) összevetjük, mégis felmerülhet a LAN megfelelőségének kérdése.

  


--- 8.8.4.4 ping statistics ---
1000 packets transmitted, 857 received, 14% packet loss, time 1001257ms
rtt min/avg/max/mdev = 4.637/22.210/323.149/28.238 ms

Ezt ugye terheletlen vonal mellett mérted? Tudnál nézni egy traceroute-ot vagy mtr-t?

Ha már felmerült az MTU/PMTU/PMTUD/MSS kérdés. Megnézhetnéd pl.: traceroute --mtu, vagy tracepath. De az MSS esetleges korrekciója a vélhetően jóval PMTU alatti pingelésednél előforduló 14% csomagvesztést nem fogja meggyógyítani. Továbbá ennek még mindig ellentmond az első állítás, miszerint a LAN-on lévő switcheket kihagyva tökéletesen működik.

( trey | 2014. 12. 10., sze – 11:47 )

Nekem is volt ilyesmi otthon a T-s előfizetésemen. Újraszámoltam az optimális MTU értéket, beállítottam a router-en és csodák-csodája, megszűnt a probléma. Nem tudom, neked milyen előfizetésed van. Worksforme.

--
trey @ gépház

Ezt így nem lehet kimondani.

Determining and setting up the correct MTU size
How to find the proper MTU size for my network

Összefoglalva, pingelni megfelelő paraméterrel, amíg a nem fragmentálódik, majd hozzáadni 28-at (IP / ICMP header-ek).

Nekem így jött ki valami 1484.

--
trey @ gépház

( bigacsiga | 2015. 04. 08., sze – 10:04 )

Nos hónapokkal a probléma jelentkezése után, rájöttem a megoldásra. Semmiféle racionális okot nem találtam rá, de ha a szolgáltató modemén kikapcsolom a tűzfalat, mintha megtáltosodna az internetelérés. ( http://i.imgur.com/pdKIOSD.png )

Ez különös, mondjuk egy D-Link modemnél meg sem lepődök ilyesmin. :)

Egyébként tegnap este én is tapasztaltam lassulásokat a névfeloldással (szintén Google DNS szerverekkel), átálltam inkább a szolgáltató DNS-szervereire, rögtön meg is oldódott a probléma.

MTU probléma lesz...
A tűzfal valószínüleg blokkolja az ICMP csomagokat, ezért nem megy a path mtu discovery, és valahol a hálózaton van 1500-nál kissebb MTU-s szakasz. Például valamilyen taggelés vagy packet encapsulation miatt lehet néhol pár byte-tal kevesebb MTU.

Úgy lehet kipróbálni, hogy elkezded kézzel levenni az MTU-t és nézed, hogy valamilyen értéknél látványosan javul-e.
---
Régóta vágyok én, az androidok mezonkincsére már!