Question Latency/Ping Spikes Randomly throghout the day

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.

digitalgriffin

Distinguished
Jan 29, 2008
356
42
18,820
2
If the ISP had congestion on their side then other people would have the same issues. Most of the time they don't have bottlenecks in the last mile. They might oversell really high speed plans and then a bunch of people start downloading + a ton of people watching videos. If they fully utilize their contracts to outside networks then everyone on that ISP would get bufferbloat on that line.

For testing have you tried multiple computers and also are you monitoring your network traffic while you test? You need to rule out your computer as the issue. Using a live boot ubuntu would rule out software side of your pc if you can't test from another pc. If you had malware it could be on all your windows machines.
He has a point. If your neighbor has a 1 gig connection and then all the sudden buffers a 4K Dolby Vision movie, or invokes an unlimited bandwidth game/torrent download, that would cause latency spikes.
 

There are multiple levels of error recovery. I generically used NAK to describe a condition in which the datapacket is bad. This is why we have a "data symbol errors" "data symbols recovered" and "data symbols not fixable" on cable modem pages. I get non-recoverable data symbols a couple dozen times a day. TCP data packets contain a checksum to validate if the data is good or not. If there were not a recovery mechanism, then a lot of my apps would just crash. A lot of this stuff happens transparently. It happens point to point on a local level on the backbone.

Understand that these error correction protocols in no way guarantee your connection will not crap out. TCP/IP is not a guaranteed communication protocol. So in a sense you are correct. There's no guarantee that you will get a re-transmission of said data packet. This is handled by the hardware as the data is reformed. But this is getting down into the weeds of it.
This is why you ONLY test network with ping ie ICMP ECHO. It is a very simple protocol. It lets you test the network and not the application. That is one of the key benefits to ICMP that no retransmission's takes place

Using any other protocol hides the network layer more than it needs. You can have issue at the tcp level or the application levels. Everything you wrote is correct but is the key reason you do not use things like this to test networks. You might as well get into the nasty business of how games that do not use ICMP measure delay they call "ping"

When you use ICMP to test you can sure that delays are due to equipment in the path and not because of retransmission due to data loss. This of course does not apply when you have a wireless connection in the path but pretty much every other protocol just discards data.

This is actually why his problem is different. If he has a poor signal level on his cable modem he would see packet loss not delays. Something is holding data memory the problem is his ISP is not be helpful in locating this device.
 
Apr 15, 2019
16
0
10
0
Packet loss = delay. If there's a NAK on a packet, then that packet must be retransmitted which leads to ping delays.

Nighteyes, your signal strength is indeed low. Are you running your cable through a surge suppressor? Most of them use simple diode arrangements, and are quite frankly, junk. They work, but it's sticking a FRAM oil filter on a Ferrari. It lowers signal strength.

If this does not fix your issue, please contact your cable company. They can access your cable modem signal strength and verify your issue over the phone. They will then send a tech out to measure your signal strength. He may want to enter your home. But he should start by impedance matching the signal to 75Ohm at the signal box.

This is trivia of how this all works btw:
TCP/IP packets are numbered. They have an IP and a port number. The port number determines to which app/device on your home network it gets transmitted to. Now there is a maximum size of packet for TCP/IP (software) and a maximum size for an ethernet packet (hardware). So sometimes if one exceeds the other, there needs to be some repackaging to break it into smaller chunks.

That said, packets are broken into chunks. So lets say you have 64K of data you need to receive, and this needs to be broken down into 3 packets of ~21K each. (Packet 1 and Packet 2 and Packet 3). So the TCP/IP sits there and waits for all the packets to arrive in order before it sends them off to you. This means you have to have packet 1 and packet 2 and packet 3.

Now due to the nature of the internet, sometimes these packets arrive out of order. If Packet 3 arrives before packet 2, then the router is going to sit there and wait for packet 2 to arrive before sending your computer packet 3. Again, it packet 3, or 2 arrive before packet 1, then those two pieces of data will wait till packet 1 arrives. (After all data has to be complete and in order.) So all this data hangs around in memory till all packets arrive. This can create "memory" issues and every router is different on how they handle delayed TCP/IP packets. Some dump the packets sooner than later or send a NAK (Not acknowledged) automatically for the missing packet. This will force a retransmit on said packet.

Now UDP on the other hand (Universal Datagram Protocol) keeps things simple. "My data is small and contained to 1 packet, and I don't care what order it arrives, just hand it to me, even if out of order" This is useful for things like video streaming, or in your case video games. It doesn't matter if player position at 5 seconds arrives before player position at 4.2 seconds. Because the 5 second position is the most recent. The game might not be as smooth, but contains the most accurate data of the current situation.

Some DNS's will get pinged RELENTLESSLY for UDP DNS services. And because they aren't local and traffic can get quite heavy, the ping time MIGHT actually be higher than TCP/IP. Overall the average might be lower (Cloudflare) but every once in a while you might see a spike. That's why I was asking. Also, my personal firewall when using UPlay (UbiSoft) downloader, was using UDP. And it would crash because it's UDP DNS was timing out due to DPI and causing buffer bloat as the commands built up in the buffer on the firewall.
I am not really sure if I am using a surge compressor. I don't think so but I don't know 100%. I don't know how to identify it if I do have one plus I wouldn't know where too look. I also am having my ISP come out next Friday. I am hoping I can have a thing or two for them to check. It seems my upstream levels might be one thing to check.
 
Apr 15, 2019
16
0
10
0
So just a general update on my internet status and this thread. So my ISP is sending a tech out next Friday to check things again... and I am going to see what new things I can ask him to check. It seems like I should have him check my upstream/downstream levels to see if that may be a problem. Also, after talking about these levels and something digital griffin said about them made me think maybe my modem is getting too hot (pretty random though) but somewhere I believe I read where a modem that's too hot can cause issues. I took my modem and am currently using a fan to blow air on it. Preliminary results showed that it didn't fix the problem but in my opinion made it not as bad, though this is after just a few hours and it could just be random luck. I also have a friend about 2 blocks away who has a similar situation to me, I had him test his ping and it looked like mine(though he has had bad internet for way longer then me so might just be him). Also, I appreciate all the replies you guys spammed this morning, even though half of it went over my head and I will try to sift through it later. Finally, unfortunately at this point I am only going to be able to reply minimally until next Thursday as I have 3 semester projects and 3 finals all within the next 6 days. So I will probably keep an eye out and respond when I can until next Thursday.

I also forgot but griffin suggested first comment wireshark to monitor packets and since it seems we might be dealing with paket loss I just wanted to say I have wireshark and have tried monitoring packets but really have no idea how if the few black or red packets I'm seeing are bad or not really out the ordinary.
 
Last edited:
Most people would love to have low numbers like you do on the upstream side. I am not sure what actually happens if it is too low. The upstream numbers are kinda fake in a way. They only tell what you are outputting there is not way to tell how much the cable company is receiving.

A overly simplistic description is that the ISP equipment adjusts the level your modem transmits at until it gets good SNR numbers The big problems come when the ISP equipment can not hear your modem well and keep increasing the power. It can only go to something like 55 and there are major issues once you get much above 50.

I am not sure why your level is so low and if it really is a issue or not.

What you will see if you have transmission issues is lots of messages in the log saying your modem is losing sync or it reboots. This is very different than the symptoms you report.

The only time I remember seeing modems being the cause of delays was related to the intel puma bug. I get my threads confused sometimes but I though that was ruled out in your case.
 
Apr 15, 2019
16
0
10
0
If the ISP had congestion on their side then other people would have the same issues. Most of the time they don't have bottlenecks in the last mile. They might oversell really high speed plans and then a bunch of people start downloading + a ton of people watching videos. If they fully utilize their contracts to outside networks then everyone on that ISP would get bufferbloat on that line.

For testing have you tried multiple computers and also are you monitoring your network traffic while you test? You need to rule out your computer as the issue. Using a live boot ubuntu would rule out software side of your pc if you can't test from another pc. If you had malware it could be on all your windows machines.
I have run the ping test, at the same time, to google I mentioned earlier on 4 different computers and they all show the same general ping spikes to varying degrees.
 

digitalgriffin

Distinguished
Jan 29, 2008
356
42
18,820
2
This is why you ONLY test network with ping ie ICMP ECHO. It is a very simple protocol. It lets you test the network and not the application. That is one of the key benefits to ICMP that no retransmission's takes place

Using any other protocol hides the network layer more than it needs. You can have issue at the tcp level or the application levels. Everything you wrote is correct but is the key reason you do not use things like this to test networks. You might as well get into the nasty business of how games that do not use ICMP measure delay they call "ping"

When you use ICMP to test you can sure that delays are due to equipment in the path and not because of retransmission due to data loss. This of course does not apply when you have a wireless connection in the path but pretty much every other protocol just discards data.

This is actually why his problem is different. If he has a poor signal level on his cable modem he would see packet loss not delays. Something is holding data memory the problem is his ISP is not be helpful in locating this device.
Pings go point to point like any other traffic. The backend hardware can corrupt the data between peers. The backend hardware is responsible for correcting point to point deficiencies. It's transparent, you don't see it. But re transmissions do occur. So a retransmit does occur, even with ping. But again it doesn't guarentee you are going to get it.

You can think of it this way: RS422 has a balanced output at the electrical level. One signal positive, one negative. It's a form of checking data redundancy when transmitting. It in NO WAY affects the data in the packets. But it can be rejected and the hardware will transmit a NAK. (Again I use this generically to describe a bad data packet situation) You don't see it because it's handled at a hardware level. A lot of high speed communication on peers involves a lot of bleeding edge high speed interconnects that are subject to error. You can employ error correction at this level and it doesn't affect the data is wraps. But it does take more time to fix. (Think of it like error recovery on a HDD/RAID array) Takes a little longer to get you the data, but it does. It does not gaurantee that it can be recovered however. Like I said, sometimes things just "barf"
 
Pings go point to point like any other traffic. The backend hardware can corrupt the data between peers. The backend hardware is responsible for correcting point to point deficiencies. It's transparent, you don't see it. But re transmissions do occur. So a retransmit does occur, even with ping. But again it doesn't guarentee you are going to get it.

You can think of it this way: RS422 has a balanced output at the electrical level. One signal positive, one negative. It's a form of checking data redundancy when transmitting. It in NO WAY affects the data in the packets. But it can be rejected and the hardware will transmit a NAK. (Again I use this generically to describe a bad data packet situation) You don't see it because it's handled at a hardware level. A lot of high speed communication on peers involves a lot of bleeding edge high speed interconnects that are subject to error. You can employ error correction at this level and it doesn't affect the data is wraps. But it does take more time to fix. (Think of it like error recovery on a HDD/RAID array) Takes a little longer to get you the data, but it does. It does not gaurantee that it can be recovered however. Like I said, sometimes things just "barf"
How does RS422 apply it is a old serial based protocol. In this case we have ethernet docsis and likely a bunch of different fiber based protocols in the path None of these do any form of data retransmissions. Docsis has some limited ability to correct data errors but it does not retransmit or delay the data if it can correct it with the extra bits that are transmitted

I am not saying I know everything about networking but I am pretty sure on this one. I would be happy to see any documents that show data retrasmission at the hardware level. I am well aware of old stuff like token ring does retransmission but what modern network technology does data retransmissions.
 

digitalgriffin

Distinguished
Jan 29, 2008
356
42
18,820
2
How does RS422 apply it is a old serial based protocol. In this case we have ethernet docsis and likely a bunch of different fiber based protocols in the path None of these do any form of data retransmissions. Docsis has some limited ability to correct data errors but it does not retransmit or delay the data if it can correct it with the extra bits that are transmitted

I am not saying I know everything about networking but I am pretty sure on this one. I would be happy to see any documents that show data retrasmission at the hardware level. I am well aware of old stuff like token ring does retransmission but what modern network technology does data retransmissions.
It does on a peer to peer basis. Multiplexed fiber layers different wavelengths on top of one another to increase the bitdepth (and therefore bandwidth). Various issues can cause frequency shifts in the light/lambda attenuation/timing issues due to things like wind/temperature change which leads to data errors. To overcome these issues, the newest multiplex fiber uses retransmission. But again all of this is transparent to the end user. Sometimes packets get so completely garbled the receiving end has NO clue where it came from. These are proprietary solutions though at the hardware level. So the hardware at each node has to conform to that standard. That's why these solutions appear mostly at tier 1 providers as they control more end to end of the backbone.

Docsis does have data recovery like Party. But it also has retransmit request (or so I thought...here I might be wrong.) But like I said, I get a couple dozen unrecoverable data errors per day on my modem. So I would be getting a lot more program crashes with my WebAPI calls if there wasn't some redundancy wired in.

Found it: Forward Error Correction for DOCSIS. I will admit I may be interpreting this wrong.

Forward Error Correction (FEC) FEC enables the receiver to detect and fix errors to packets without the need for the transmitter to retransmit packets.
http://www.cable-europe.eu/wp-content/uploads/bsk-pdf-manager/3_CM-SP-PHYV3.0-I09-101008.PDF
 
Last edited:
It does on a peer to peer basis. Multiplexed fiber layers different wavelengths on top of one another to increase the bitdepth (and therefore bandwidth). Various issues can cause frequency shifts in the light/lambda attenuation/timing issues which leads to data errors. To overcome these issues, the newest multiplex fiber uses retransmission. But again all of this is transparent to the end user. Sometimes packets get so completely garbled the receiving end has NO clue where it came from. These are proprietary solutions though at the hardware level. So the hardware at each node has to conform to that standard. That's why these solutions appear mostly at tier 1 providers as they control more end to end of the backbone.

Docsis does have data recovery like Party. But it also has retransmit request (or so I thought...here I might be wrong.) But like I said, I get a couple dozen unrecoverable data errors per day on my modem. So I would be getting a lot more program crashes with my WebAPI calls if there wasn't some redundancy wired in.

Found it: Page 11 of 61: Forward Error Correction for DOCSIS. I will admit I may be interpreting this wrong.



http://www.cable-europe.eu/wp-content/uploads/bsk-pdf-manager/3_CM-SP-PHYV3.0-I09-101008.PDF
Error correction is not retranmission it just sends extra redundant bits along with the main transmission. The does reduce the total bandwidth some but it does not increase the delay/ping time. It just used the "spare" bits to get the correct data. This is extremely common in many of the fiber encoding methods. The extra data is always transmitted it would not cause random delays even if there was any delay.

Almost all data transmission methods leave data retransmission to the application. In almost all cases network problems are data loss not delays because the network equipment wants to put the burden on the end stations for retransmitting data.

We are really going nowhere with this. Even if there was something the ISP must admit it. It actually is much easier if you see packet loss. The ISP seem to be able to fix that since it is easy to see where the loss is. Delays are almost always some "router" type device buffering the data because some connection is full or it has some other issue like CPU load slowing its ability. The first level tech guys tend to not have access to any of this equipment. It would be nice if his problem was he was over using his connection and we could tell him to use the bufferbloat QoS options but in this case the delays appear to be outside his direct control.


........I will add this here because it might have been lost. This type of issue is exactly what the intel puma modem bug looked like. I think he said it happened on mulitple modems one of which does not use intel but in case I am confusing threads I will repost it here.
 
Last edited:

digitalgriffin

Distinguished
Jan 29, 2008
356
42
18,820
2
Error correction is not retranmission it just sends extra redundant bits along with the main transmission. The does reduce the total bandwidth some but it does not increase the delay/ping time. It just used the "spare" bits to get the correct data. This is extremely common in many of the fiber encoding methods. The extra data is always transmitted it would not cause random delays even if there was any delay.

Almost all data transmission methods leave data retransmission to the application. In almost all cases network problems are data loss not delays because the network equipment wants to put the burden on the end stations for retransmitting data.

We are really going nowhere with this. Even if there was something the ISP must admit it. It actually is much easier if you see packet loss. The ISP seem to be able to fix that since it is easy to see where the loss is. Delays are almost always some "router" type device buffering the data because some connection is full or it has some other issue like CPU load slowing its ability. The first level tech guys tend to not have access to any of this equipment. It would be nice if his problem was he was over using his connection and we could tell him to use the bufferbloat QoS options but in this case the delays appear to be outside his direct control.
I realize error correction is not re-transmission. It was this that leads me to believe there is some facility there for correction:
without the need for the transmitter to retransmit packets.
Like I said I may be interpreting it wrong.

It is in the best interest of ISPs and backbone providers to retransmit when they can on a peer to peer basis for several reasons. Retransmit over one peer to peer is cheaper to manage/handle than a client doing error correction over the whole path. It also increases reliability on bleeding edge tech.

I'll agree with you though that this is mostly academic at this point and drifting into the weeds. I could be wrong, but it's not relevant to the posters questions. So I'll stop here and admit I may be wrong. I'm just reading white papers on the latest tech. So my interpretation of them might be wrong.
 
Apr 15, 2019
16
0
10
0
Hey so sorry I was pretty busy until today so wasn't able to respond but I have a slight update on the situation. So I mentioned in my last post about having the fan blowing on the modem, which I have continued to do so, and my internet seems to be doing consistently better. I will still occasionally have some spikes (today I had a few minutes in a row but after a reset it was better) but over all they seem to be less often and less severe. The only exception was on the Xbox playing some COD with my brother so idk. Now after testing this I have a few thoughts on this:

1. I had replaced my modem and the issue persisted so I'm wondering why cooling the modem seems to fix things. I considered the fact that the modem is in a slightly enclosed area (about 2 ft space above and 3 feet under an overhang before the overhang ends and opens into our living room) so maybe the new modem was over heating, but that doesn't seem likely to me as this modem has been fine up there for like 2 years.

2. I'm not sure but was wondering if this could have something to do with the upstream power lvls being low?

3. Also the nature of the spikes is different. Instead of spiking continuously for an extended period of time, causing increased latency, I have been experiencing small blips where my game will freeze momentarily before catching back up(again not my computer as I was checking my task manager for any excessing CPU or memory hogs I occasionally get)

I'm not sure how this changes things or if it really is helping even if it seems to be just wanted to see if this changes any of your guys thoughts.
 
I think you are still pretty much proving that the ISP has some issue since you replaced the modem again.

You need to be very certain that the game freezes you see are due to higher ping times and not packet loss. Packet loss could be caused by the levels on your modem but I don't think the low upstream levels area problem. Packet delays are caused more by router in the ISP network. A modem sends the data and the data either gets to the other side at some fixed amount of time. The data is either good or it is discarded.

For packets to be delayed some device must hold the data in a buffer. A router will do this because the output connection is overloaded. In the past when memory was expensive routers help only a very small amount of data so you got packet loss from a connection overload.

Packet loss is generally due to a some damage to the data in the path or a extremely overloaded link that exceeds the amount of data that can be buffered.

Packet loss due to network problems the ISP will fix. Delays due to overloading the ISP has intentionally done that in many cases. Buffering the data causing delays actually helps the performance of almost every application other than online games so the ISP does not really want to "fix" that if they can not eliminate the source of the delay.

I really doubt there is anything on your side causing this. You can repeat the tests but you pretty much have proved you have no ping spikes between your machine and your router and it does the same when you directly connect to the modem. You have replaced the modem. This pretty much eliminates anything you have control over.
 
Apr 22, 2019
4
0
10
0
Have you tried changing your connection channel on your router/modem?
Cable or fibre op? Shared connection or independent?(ftth/fttn)
 
Apr 15, 2019
16
0
10
0
I think you are still pretty much proving that the ISP has some issue since you replaced the modem again.

You need to be very certain that the game freezes you see are due to higher ping times and not packet loss. Packet loss could be caused by the levels on your modem but I don't think the low upstream levels area problem. Packet delays are caused more by router in the ISP network. A modem sends the data and the data either gets to the other side at some fixed amount of time. The data is either good or it is discarded.

For packets to be delayed some device must hold the data in a buffer. A router will do this because the output connection is overloaded. In the past when memory was expensive routers help only a very small amount of data so you got packet loss from a connection overload.

Packet loss is generally due to a some damage to the data in the path or a extremely overloaded link that exceeds the amount of data that can be buffered.

Packet loss due to network problems the ISP will fix. Delays due to overloading the ISP has intentionally done that in many cases. Buffering the data causing delays actually helps the performance of almost every application other than online games so the ISP does not really want to "fix" that if they can not eliminate the source of the delay.

I really doubt there is anything on your side causing this. You can repeat the tests but you pretty much have proved you have no ping spikes between your machine and your router and it does the same when you directly connect to the modem. You have replaced the modem. This pretty much eliminates anything you have control over.
I guess I didn't make it very clear on what I meant which is my fault but I didn't replace the modem again I was just saying back when I did replace it, it didn't make a difference. Anyways, looks like the issue is most likely out of my control... I appreciate all of your guys help with the matter. I have inadvertently become quite knowledgeable in networks and how everything works haha. Well see if the tech has a revelation this Friday when he comes.
 
Apr 15, 2019
16
0
10
0
Have you tried changing your connection channel on your router/modem?
Cable or fibre op? Shared connection or independent?(ftth/fttn)
I don't think you can just switch between cable and fiber. Pretty sure I don't have fiber to my house anyways. I also don't think I can switch channels on my modem since I have only limited access to its settings. And we've pretty much eliminated the router as the problem. And not sure about connection or how that would make a difference?
 

davesnothere

Commendable
Aug 6, 2016
39
2
1,565
6
If you are getting timeouts in routing its a networking issue inside cox. Especially if the packets are getting routed to an internal office network and out (it will look like addresses in the ip pool: 10.xxx.xxx.xxx). RF Media dhcp servers can do this behavior too if it assigns the wrong DNS server. But there is nothing on your side that can help you here, other than trying to find a better internet service provider. I have to leave mine because it got baught by Vast and when they combined thier network with this one, now on everyone's machine times out on the first hop out, servicing us 5-10 times slower, when the average ping on even the smallest package was 5ms. Now its 200ms. which I can get better speeds with a dsl service provider here.
 

ASK THE COMMUNITY

TRENDING THREADS