networking - How can I find the source of packet loss in a traceroute?
2014-04
Earlz
Whenever I ping my website, I get 5% packet loss consistently. However, pinging other sites such as google produce no packet loss. I'm really not fond of my webserver dropping packets, but I'm not sure if it's just the route or my server or something to contact my hosting provider about.
What I basically needs is something like traceroute, but that also checks for packet loss. Is there such a tool on Linux and/or OpenBSD?
scherand
Simon
Traceroute only shows 1/2 the path: the path from the host doing the traceroute to the destination. To get the full path, one must log into the remote server, and do a traceroute back to the local system. Should you have root privs on the webserver, doing a tcpdump to watch for ICMP echo-requests from your local host will tell you if they're all getting there. Then, send pings from the web server back to your local host, and count those.
If the server's CPU is high, it will not respond to ICMP requests. RSVP and other protocols may have ICMP's QoS at a very low priority, so it might be worthwhile to check how actual traffic transfers between your two hosts are performing. A loss of a packet will cause a perceptible hang in the data stream; If there's no pause in a file transfer, then no packet loss exists.
Psyconn
I've run Ping Plotter and here are the results with high packet loss on all hops (around 12%). I find hard to believe Google's routers are faulty, is it my network card to blame?
Click the screenshots to enlarge them.
Picture of the ping plotter screen (closed all network traffic except World of Tanks, removed local router):
I've also run winMTR (with radio and starcraft2 running), I've added my home router too.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| my.router - 0 | 1631 | 1631 | 0 | 0 | 3 | 1 |
| 10.0.0.1 - 5 | 1413 | 1356 | 1 | 11 | 41 | 3 |
| qr90.bucuresti.rdsnet.ro - 5 | 1379 | 1313 | 1 | 12 | 78 | 3 |
| cr01.bucuresti.rdsnet.ro - 4 | 1436 | 1385 | 2 | 18 | 50 | 3 |
| xr01.budapesta.rdsnet.ro - 5 | 1407 | 1348 | 13 | 24 | 70 | 14 |
| xr01.budapesta.rdsnet.ro - 4 | 1430 | 1377 | 13 | 24 | 125 | 15 |
| 213-154-130-234.rdsnet.ro - 4 | 1422 | 1367 | 13 | 27 | 122 | 14 |
| 209.85.242.228 - 4 | 1429 | 1376 | 13 | 26 | 121 | 14 |
| 72.14.232.102 - 4 | 1421 | 1366 | 30 | 44 | 142 | 45 |
| 72.14.236.21 - 4 | 1440 | 1390 | 28 | 45 | 204 | 29 |
| 209.85.254.57 - 5 | 1402 | 1342 | 31 | 46 | 86 | 32 |
| www.google.com - 4 | 1441 | 1391 | 29 | 40 | 69 | 31 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Traffic around 4 AM with torrents and all stuff on my machine working:
Upon adding my home router I noticed it is packet loss free so i guess the problem is in the 10.0.0.1 router. Guys from the ISP came and checked connectivity and said it's ok, but the plague of lag spikes is still there. One thing I noticed is that in the morning and late night the connection is ok.
David Schwartz
This seems perfectly normal. There are two things you have to keep in mind.
First, if a particular connection shows packet loss, you will see that same packet loss on any path that includes that connection. So if your connection to your ISP is dropping packets, every point past that will show that same packet loss. The packet loss is measured by sending a packet out and seeing if you get a packet back.
Second, packet loss is normal. This is how multiple TCP streams figure out how to share a connection without any specific "you get X, you get Y" mechanism. Since you're running a torrent program, you probably have a fairly large number of TCP connections, and they're all trying to figure out how much bandwidth they can get. TCP connections ramp up their speed until packets start dropping and then back down.
Suppose one of those connections suddenly slows down. How could the others figure out that more bandwidth is available? The only way is if they periodically try to increase their transmission rate. And if the connections are fully utilizing your connection and one of them tries to increase its transmission rate, what do you think will happen? Yep, a few packets will drop. If no packets ever dropped, then all the TCP connections would be increasing their bandwidth consumption. How would that work?
If this is an issue for you because you're also trying to run applications that are sensitive to packet loss, configure a limit in the inbound and outbound traffic your torrent program allows. Make it about 85% of the maximum traffic level you see in the program. This will only cause a 15% performance drop in the torrent program and it should keep the packet loss level generally at 0. (Except when some other program creates traffic and then that program has to figure out how to share with the torrents.)
Ray
Torrents use large numbers of TCP and UDP connections, which could, depending on your router, using all of the router's RAM while doing its thing. Since I see packet loss to the 10.x.x.x network, that tells me that something is up between your router and that network, change your Ethernet cords, if you are on DSL change your phone cord and make sure that phone cord it no longer than 3 feet. Standard phone cords are not shielded and do not use twisted pairs so they are very sensitive to electrical and magnetic interference.
Also If you are on a DSL connection, a lot of neighborhoods have a problem called "Local Saturation", basically there are too many people for the DSLAM to handle which will cause packet loss.
As for the remote networks experiencing packet loss per the plotter, not sure, but those networks are way out side of the control of your ISP.