I've been using PingPlotter to try to help diagnose why my connection is so poor and I am getting packet loss all of the time. There is a hop on my route that is clearly well overloaded. I don't know how to report it, but here it is:
It's getting hammered and hopefully there is a fix soon.
A good internet connection is important to me - which is why I pay for the VIP package, but I'm getting something worse than many other providers at the moment and need to see it fixed.
Posting a partial ping plot is pointless as it is the final hop that counts. It is not unusal to see high pings\packet loss on single hops as the server could be configured to treat ICMP timeout echo requests as low priority or completely ignore them. The pingplot needs to be looked at as a whole as that server that looks like it is being hammered may just be just due to the server configuration. Some examples of ping plots here.
I cant see where you get the bad hop and packet loss all the way seeing you have 0% packet loss at Hop 16 and around 2% packet loss on subsequent Hops. There may be a 2% packet loss at the end of these trace but as it looks like the target server is configured to ignore ICMP packets or deflect them hard to be sure. It is not unusual for large retail sites like Anazon and gaming sites to ignore ICMP trsffic as a protection against DDOS attacks.
Lets look at your teace step by step.
Hop 2 0% PL fine and dandy
Hop 3 0% PL again, fine and dandy.
Hop 4 100% PL What!!! are you telling me not a single packet is getting through??
Hop 5 100% PL Hang on a minute, you just told me that no packets were getting through on the last hop so how come the packets are making it this far?
Hop 6 100% PL Same as Hop 5
Hop 7 100% PL Same as Hop 6
Hop 8 0.8% PL 98.2% of the packets are making it through now, where did they come from when I was told no packets were making it through the previous hops?
Hop 9 46.7% PL Ok, lets see what happens on the next hop
Hop 10 0% PL All the packets are making it through now, so therefore there couldn't have been any packet loss going through the servers on the previous hops. what is happening?
Pingplotter works by sending sequences of ICMP packets to a target server with an incrementing TTL value.
Internet Control Message Protocol is a support protocol carrying error and operational messages and is often treated with a low priority as it does not carry any data like the TCP and UDP and other protocols. ICMP can be seen as the messenger boys of the Internet.
Pingplotter will send ICMP packets containg essentially, your IP address, a timestamp, a Time To Live value and a polite note requesting that the receiving server will let you know if the ICMP packets die on the server, or a ICMP Timeout Echo Request.
The first sequence of lets say 10 ICMP packets are sent to the target server with a TTL value of 1. The server at hop 1 will reduce the TTL value by 1 to show that the packets have reached a server and serve as a hop count. The server at Hop 1 has received the ICMP packets and reduced the TTL value by 1 so the new TTL value is 0, so the packets die.
This server is a polite server, and has been configured to respond to ICMP timeout echo requests in a timely manner, so it will send you back condolences that your packets have died with a time of death. On receiving the response to the timeout request pingplotter can work out the roundtrip time from the timestamps and the packet loss from the number of responses it receives back. i.e. if you get 10 responses from the 10 packets sent then there is 0 packet loss. Be aware that if you only receieve 5 responses back from the 10 packets doesn't automatically mean you have a 50% packet loss as you have no way of knowing how this server is configured.
The next sequence of packets will be sent to the target server with a TTL value of 2. The packets will pass through the server at hop 1 on their way to the target server with no intervention from the server at hop 1 apart from reducing the TTL value by 1. So the packets will arrive at the server at Hop 2 with a TTL value of 1 which will be reduced by 1 by the server at hop 2 giving a new TTL value of 0, so the packets die.
This server has been told to ignore messenger boys as they are not important enough to talk to. So, you will receive no response from the server that your packets have died so pinglotter cannot work out the roundtrip time and will see 0 responses from 10 timeout requests calculating the packet loss to be 100%
The ICMP packets have still not reached the target server so another sequence of 10 ICMP packets are sent to the target server with a TTL value of 3.The packets will travel through the server at Hop 1 with no interaction apart from reducing the TTL value by 1, through the server at Hop 2 again reducing the TTL value by 1 and onto the next server en route to the target server at Hop 3 where the TTL is again reduced by 1 making the new value 0 again and the packets die.
This server is configured to treat ICMP Timeout Echo Requests as low priority as it has more important thing to do like make the coffee. For example. the first few packets arrive when the server is not busy, so the servers responds to the timeout echo requests in a timely manner. The next few timeout requests arrive at the server when it is busy, so the server will put your timeout echo request at the back of the queue and if it can not respond to the echo request within the default timeout period of 2 seconds then you will effectively see no response to these requests and pingplotter will see it as packet loss.
This process will continue until the target server is reached. This is the important hop as it will not be affected by how the servers at intermediate hops are configures as all they wil do is pass the packets through reducing the TTL value by 1. So if you see 0 packet loss at the final hop the trace is good.
Hop 1 1ms 0% PL Fine, Typical first hop to router with wired connection
Hop 2 **** 100% PL Server configured to ignore ICMP timeout echo reqests
Hop 3 10ms 0% PL Fine, confirms 0 packet loss at hop 2
Hop 4 58ms 50% PL Server configured to treat ICMP timeout echo requests as low priority.
Hop 5 25ms 0% PL Fine confirms server at hop 4 configuration.
Hop 6 100ms 30% PL OK, lets see next hop
Hop 7 125ms 35% PL Looks like it might be actual packet loss at Hop 6
Hop 8 110ms 30% PL Looking more likely actual packet loss at Hop 6
Hop 9 135ms 30% PL Target server 30% packet loss confirmed
Whilst tools like Pingplotter are useful for testing specific servers at that given moment in time it is not really useful for testing the general performance of you Internet connection.
A better tool to test the general performance would be Thinkbroadband's Broadband Quality Monitor here. You will need to enable Respond to ICMP Echo Requests in the advance sectiuon of the hub's GUI first or disable the firewall if you have a Hub 3.
Thank you for taking the time to reply. My issue is that not only are my speeds slow, but I am experiencing higher pings and packet loss in games. For the above IP I would normally get around 50ms of smooth play, but it goes over 120ms (for a whole game, not just a peak) with the PL.
I am well aware that this could be the Amazon hosting providers, but clearly there is some issue with the infrastructure in providing me with my connection because the speed is slow.
Late on Saturday night, everything was smooth again and I downloaded at 160Mbps (That's with wireless ac and so not even wired) instead of 10-35Mbps and the ping was back to normal.
I'll try the thinkbroadband thing but will also be calling to get a discount for the poor service.