WOW

[Noir]

[SilverZ06]

....

[guncrasher]

you are lucky 2 days ago we had pings of between 300 to 600 in world of tanks.  it made for some interesting battles as you couldnt control the tank. nor even know where the enemy was.  according to wot it was our computers.  all 30 of us that were in each match had crappy computers and crappy connections.  that lasted for a whole day.


semp

[Noir]

  no wonder I was getting rubber bullet and stuff...can't the packets where I get hit get lost also?

[MrRiplEy[H]]

no wonder I was getting rubber bullet and stuff...can't the packets where I get hit get lost also?

If you put a return address to the packets, they come back after they get lost. That's why you get hit 

[715]

no wonder I was getting rubber bullet and stuff...can't the packets where I get hit get lost also?

One of the intermediate servers occasionally couldn't be bothered to return your ping packets because, perhaps, it had better things to do, but the AH servers never lost any of your packets and that intermediate server apparently correctly forwarded all of them to and from AH.  Someone can correct me if I am wrong, but I thought the only time you'll have problems is when the final hop, i.e. AH, shows packet losses.

[Skuzzy]

Actually, when the final hop is us (not a router), it means the problem is on the return trip.  The routes to and from your computer are asynchronous, meaning the path to the servers is not the path back to your computer from the servers.

Traceroutes/Ping Plots cannot show both paths.  When the error is on the return trip, the last or next to the last hop will show problems in the Ping Plot.  Those last two hops cannot have packet loss as they are not routers.  The server will never lose a packet (nature of the beast) and a properly configured switch does not lose packets either.

When I see the problem is in the last two hops, I run the trace back to the source IP so we can tell where the problem is.