Ping spikes

carwiz said:

Oh there is indeed a connection; Otherwise, the server(s) wouldn't respond. While the ICMP special message is handled differently, it's still a message. The option to respond is server based.

By connection-less I am referring to whether an identifiable connection can be established. Another post suggested that Google may be performing traffic shaping techniques by queing the traffic before processing. In a connection-less application like ICMP there is no way to uniquely identify each echo request and reply. If traffic shaping techniques had been enforced then other people who ping Google would experience the same spikes. I didn't which makes the validity of this questionable but not completely invalid. This is the reason why I sent the ping messages myself. My intentions had nothing to do with the path taken to the server.

If you look at a wire capture of a ping you can see that no uniquely identifiable information is exchanged and no keep-alive messages are sent either since there is no formal connection being made.



This is as opposed to TCP based applications which does establish a unique session (Also known as a Socket). This would then make QoS enforcement on a particular connection more feasible. An example of a TCP connection being established can be seen below:



A traceroute is good option however when using it on the internet it can be rather decieving and will not show the full picture. For example, a traceroute for me says that Google is 7 hops away. So that would mean that my ISP has less than 7 routers in the path to Google? No possible. Traceroute relies on the TTL being decremented in order to offer an accurate reading. As for the latency times... it could offer a suitable reading to see if a router in the path is causing extortionate high spikes in latency however again not all routers are recorded in a trace. Additionally, traceroute works by sending ICMP messages with low TTLs and receives feedback based on the ICMP TTL Expiration messages. The latency involved would not be accurate to a routing lookup as the router involved would need to create a new packet to send back where as in normal transit traffic it will just need to perform a route lookup and send the original packet on its way.



As for my suggestion on testing drivers first it would seem the next logical step as we test each variable that could affect latency. Why start blaming a router on the internet when you haven't tested if there is an issue within the local network to begin with?

We've first established this is application independent from the OP's response that it happens when playing online games as well as the noticeable spikes when pinging Google.

First check would be to see if a third party application or anti-virus software may be causing the issue? The OP stated that they attempted in safe mode however the issue still existed?

What is still enabled during safe mode that could affect latency? Could be malware which is a potential culprit however drivers are still involved so could also be a potential culprit?

Moving up away from the local machine we could say that it is the internal router at the home that is the cause? Well yes it could be however the OP stated that no other devices on the network experience the same issue so would be unlikely. What about the uplink to the ISP? Again, the issue is apparently local to this device...

Then we enter the internet where ability to test things with precise accuracy becomes near impossible. As the OP stated, this is application independent therefore the chances of there being a constant latency spike for different destination servers would be unlikely. It could be the ISP itself however again, no other devices apparently experience this. A good way to test would be to possible test latency on a different network ... maybe a friend or family's or a public hotspot?

Another reason for attempting to rule out drivers is that I have seen it been a culprit before. Take the following thread as an example:

Random Ping Spikes

Very similar symptoms.

While a ping can't tell you everything it doesn't mean you can't break down the path that is being taken and identifying potential variables that could cause the issue. Starting from within the local network helps to prevent unnecessary calls to an ISP on fixing an issue that may be local to a particular machine.

Just my thought process, if you have a better idea then please share. I may have missed something :)

Josh :)

You'll have to explain what you mean by a "formal connection". You don't need a session for a server to respond to a frame but there is a connection established. The server will respond to a frame. That frame has a source address and a destination address. The response is really an error response (time to live = 0) but the server does respond. It's in your example called a "reply". It can't respond without knowing where to send it. Formal or not, that's a connection. The ping software just doesn't pull a number out of a hat.

carwiz said:

You'll have to explain what you mean by a "formal connection". You don't need a session for a server to respond to a frame but there is a connection established. The server will respond to a frame. That frame has a source address and a destination address. The response is really an error response (time to live = 0) but the server does respond. It's in your example called a "reply". It can't respond without knowing where to send it. Formal or not, that's a connection. The ping software just doesn't pull a number out of a hat.

By a "formal connection" I mean a full session being made between client and server with record of that happening. The second image in my previous post shows a TCP three way handshake taking place and causing a connection to be established. If you run the following command in a command prompt it will show the various connections that are established.

Code:

netstat -a

ICMP doesn't appear because it doesn't establish a session before sending the echo requests and is therefore known as a connection-less protocol. If you've ever had any experience with UDP you will notice that it is also known as a connection-less protocol since a connection isn't technically established. For example, consider DNS which uses UDP port 53.



The response is a designated type of ICMP message dedicated for echo-reply functions (ICMP type 0). TTL Expiration messages are of type 11. The reason the server replies was because the destination IP address and layer 2 address on the other side matched the one of the server therefore it read the whole packet. The only time a TTL expiration error message is legitimately used is in traceroute



TTL expiration is used for traceroute messages as that is how it determines what hops are in the path.



The server knows what IP address to send the reply message to but an IP address isn't 100% unique. Consider the implantation of NAT (Network Address Translation). Many devices could be using one public IP address when accessing a server. With ICMP the unique information is handled via NAT but from a server perspective it will not know the NAT table mapping and therefore only has an IP address to go by.

With something like TCP, which establishes a connection, there is a unique source port generated by the client in the process and therefore offers something that can uniquely identify each individual connection. For example, a session from the following socket:

200.12.35.6:34562

Can be seen as a different connection than:

200.12.35.6:40023

With ICMP there is no source port made therefore two pings coming from the same IP address cannot be distinguished from each other.

Josh :)

Shadowjk sure is a lot of neat information but I have some question I think you could help with.
From computer A a signal leaves and goes through all the hardware, cables, fiber, switches and possibly a satellite to reach computer B and back to computer A.

1. Can a 2 or 3 na variation be noticed by a user of computer A?
2. Can the exact external device be pinpointed where the 2 or 3 ns are lost with all the things that a signal has to go through?
3. If one could pinpoint the location of the dropped 2 or 3 ns somewhere in the world what could they do about it?

Keep in mind I only have 3 brain cells so it's easy to get me lost.
I'm thinking one could loose a ns just entering a Google Server Complex and then doing all the things that need to be done with the signal before it leaves again.

Layback Bear said:

1. Can a 2 or 3 na variation be noticed by a user of computer A?

Depends on the application in question. If you were using something like HTTP or web browsing then absolutely not. If you were playing an online game or streaming live video then yes the effect could be seen. As to whether or not it could be noticeable? Most likely not :) At least I couldn't.

2. Can the exact external device be pinpointed where the 2 or 3 ns are lost with all the things that a signal has to go through?

Packets go through potentially hundreds of different paths and routers and switches in order to get to their destination. Determining where the potential latency is being caused is difficult when there is only 2 or 3 ms of variation that we are talking about. For example, when making a tracert to Google UK I see that the time it takes for my traffic to reach Google is cumulative across the board with no hop causing considerable increase in latency



However when performing a trace to a device that is far away from me, For example, Sevenforums which resides in the US, you can see a clear difference in the path that shows when my traffic left my geographical region and went across the pacific to get to the US.

As you can see the latency between hop 4 and hop 5 increases by about 50 ms.



In terms of exact pin-point of where the increase began at a link level... not possible. At least not on the internet. For an enterprise network there are management and reporting tools that tell us about the link statuses for us. On the internet no one single entity owns a particular link therefore no-one is authorised to monitor its status.

Additionally, traceroute doesn't show every hop in the path to reach sevenforums. There were probably close to 100 different routers used to get to sevenforums it is just that a lot of them in the path didn't decrement the TTL value therefore it wasn't recorded as being a hop.

3. If one could pinpoint the location of the dropped 2 or 3 ns somewhere in the world what could they do about it?

Absolutely nothing. There is a rule on the internet that all ISPs follow.... You cannot tell someone how they should route their traffic. Equally, no-one else can tell YOU how to route your traffic.

Essentially, as traffic flows between different ISPs on the internet the path it takes inside and ISP is up to them. If an ISP wanted to they could force all traffic going to Google through a 64Kbps connection and end up with drop-outs. The funny thing is, no-one could do anything about it if that happened.

Hopefully this helps,
Josh :)

Thank you very much for the great information. Yes it does help my 3 brain cells understand a lot better.

Then I'm missing the whole point of the thread that keyboardface started.
If one could find the problem except in their own equipment (maybe) their is nothing one can do about it. It is what it is.
Is that correct.

Layback Bear said:

Thank you very much for the great information. Yes it does help my 3 brain cells understand a lot better.

Then I'm missing the whole point of the thread that keyboardface started.
If one could find the problem except in their own equipment (maybe) their is nothing one can do about it. It is what it is.
Is that correct.

Aye, could be. I just wanted the OP to test variables that are under their own control to see if that was the issue. Test drivers... Third party apps etc...

If after testing the internal network and devices that he has authoritative control over doesn't resolve the issue then it may well be something out of his control.

Josh :)