@CChilderhose are you running a VPN of any type? I'm running my modem in Bridge mode with an Asus RT-AC86U behind it and I've never seen any issues with that combination. The only time that I reboot the modem is for firmware updates or more often, experimental purposes, which is deliberate instead of necessary.
On going internet issues
had 2 tech come over and still getting spikes while gaming or streaming videos. they checked everything and said not much they could do all signals look good. I am wondering if its my modem trial update since I am on the gaming one. 188.8.131.52T4 - 2A
Speeds seem the same as previous firmware i'm getting higher than 950 mbps on downstream but its probably just a bug on the site.
Also on the previous firmware i had an up time of over 30 days no reboots so my experience has been quite stable ever since 184.108.40.206T4
Ok, an interesting plot to say the least the first plot that is.
So, there are a couple of things to do.
To test Hop #2 you can do this three ways. Using that plot, click or double click on any of the individual hops to bring up the plot for that hop. You could actually select all of them if you wanted to. The plots will stack up vertically in order. To close any of the plots right click on the plot and select “close”. The real question at this point is whether or not any packet loss at Hop #2 relates to Hop #7, the target DNS address. Looking at both plots, one on top of the other will allow you to do that. If you look at the text data, there is only one error, or one packet loss instance for Hop #2, the CMTS, and 36 loss instances for Hop #7, the DNS. So, you may or may not be able to see if the one packet loss aligns with the DNS packet loss.
The other way to do this is to right click on Hop #2 and copy the IP address. Pause Pingplotter, paste that address into the address bar and let Pingplotter run. That my preference as Pingplotter causes a good deal of extra traffic that I would rather not see while a test of this type is running. You will see regular latency spikes from the CMTS. That’s a false indication due to the modem processing. Disregard the ping spikes. We’re looking for packet loss to and from the CMTS.
Lastly, you can do this via command prompt. Bring up a command prompt and ping the CMTS:
Ping 220.127.116.11 –t
That runs a continuous ping at 1 second intervals. Again, you will see high return times. Disregard those times as that’s a modem processing issue. When you want to stop the test, use Control^C. What we’re trying to confirm in this case is whether or not there is any packet loss. To post the bottom results, right click on the command box title bar. Select EDIT …. SELECT ALL. Right click again and select EDIT …. COPY. Paste that into notepad so that you can copy the bottom results section, or paste that into a post and delete the data above the bottom results. The question is, whats the packet loss to the CMTS? I usually run this for 24 hours, but, in your case keep an eye on the ping returns for a few short minutes to see if there are signs of packet loss. If not, just let it run for at least an hour or more. If yes, ok, stop the test and paste the results. From the Pingplotter results, you shouldn’t see much packet loss in this test.
Last test is for Hop #7, the DNS. I’d like to confirm the results that Pingplotter is indicating. In this case run a command ping to the DNS:
Ping 18.104.22.168 –t
Let that run for a few minutes and if you see continuous instances of no response, ok, that confirms the issue.
So, at this point there are two potential issues:
Tech support can help with the packet loss to and from the CMTS. That’s what the field techs would resolve, but, looking at the Pingplotter results, that appears to be a minimal problem. I’d have to see a much longer run to come to a real conclusion.
The packet loss and high latency to and from the DNS is a network issue. Those problems shouldn’t exist. For the specific cases of Hop # 6 and #7 (DNS) you need to talk to Level II tech support. Failing that, @CommunityHelps would need to become involved to get the network engineering staff involved. This is a rather important point as the path thru Hop #6 enroute to the DNS would be a common router for a number of customers. If you’re having problems with it, then so are a lot of other customers. It would be in Rogers best interest if a staff member somewhere pays attention to that server to determine what the problem is.
Just for comparison’s sake, here’s the result of an HrPing 10,000 ping run to the DNS, at 50 milli-second intervals:
Packets: sent=10000, rcvd=10000, error=0, lost=0 (0.0% loss) in 499.974018 sec
RTTs in ms: min/avg/max/dev: 5.332 / 10.788 / 38.816 / 1.923
Bandwidth in kbytes/sec: sent=1.200, rcvd=1.200
So, no packet loss and an average time of 10.8 seconds, which isn’t too bad. Top time is 38.8 seconds. That’s the high time in the run, with the remainder at or below 25 seconds. That’s a far cry from your max time of 523 seconds.
Here’s a Pingplotter run for comparison’s sake, with the ping interval set to 1 second. No packet losses or high latency except for the high ping time for Hop #2, the CMTS. Again thats a modem processing issue for the return from the CMTS, with no effect to targets after the CMTS. This plot shows an average of 10.8 seconds which agrees with the longer run using HrPing. This plot should be what your plot looks like, low normal latency with no packet loss throughout the path to and from the DNS.
Ok so, first task is to confirm that you don’t have any packet loss to Hop #2 using a command line ping.
Second task is to confirm that you have high latency and packet loss to 22.214.171.124 (the DNS), using a command line ping.
If and when you confirm that there is high latency and packet loss to the DNS, then its time to chat with Tech Support Level II or, get @CommunityHelps to send a request to the network staff to look at the server at Hop #6 and the impact on the DNS when the DNS is accessed thru the server at Hop #6.
Hope this helps. My apologies for taking a while to get this done ....
Ok, your second pingplotter image is a little ugly to say the least. I see you've found the show plot commands to show more than one plot. The combination is rather interesting.
In the above post, I've included instructions to confirm the packet loss using a command ping. When you have confirmed the packet loss, or not, we'll go from there.
Can you confirm for me that this is done via ethernet connected pc?
Are you using a power bar of any type to power your computer equipment?
Ran a quick test for you and already time outs. using CMD
Ping statistics for 126.96.36.199:
Packets: Sent = 17, Received = 13, Lost = 4 (23% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 50ms, Average = 23ms
Ping statistics for 188.8.131.52:
Packets: Sent = 129, Received = 129, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 410ms, Average = 27ms
yes it is done via Ethernet CODA right to PC connected
wall plug with 2 spots, one spot is my modem CODA plugged into the wall directly and the 2nd spot is my power bar directly into wall above modem plug. modem is not plugged into power bar tho. they are both (modem and power bar) plugged into same wall plug tho.
Ok, no packet loss from the CMTS, which is good, but, this is a very short run. You have a very high level of packet loss from the DNS, most likely due to the server at Hop #6. So, at this point you can try to chat with Level II tech support, or ask @CommunityHelps to get involved to resolve the issue at Hop #6 10.202.47.204 and its impact on the DNS 184.108.40.206.
Before you do that, and just to be absolutely sure, can you completely disconnect the power bar from the wall socket and the connected equipment and rerun the command ping. Run the equipment using extension cords just for temporary test purposes. Power bars can contain metal oxide varistors to prevent over-voltage damage to connected equipment. That will run for several years without any issues, but, if and when that varistor starts to fail, it can generate RF interference that is conducted along power, RG-6 or ethernet cables from the source to any connected equipment. There is also a possible radiated component from the power bar and from the power cabling. The common connection point in your case would be the wall socket. Tech support will ask customers to disconnect power bars and this is the actual reason, to eliminate any possible RF interference issues.
Can you have a look at the following as well by logging into your modem:
1. Check the STATUS page that is displayed when you log into the modem. On the upper left is the WAN IP address which might show two IP addresses if your modem is running in Dual Stack mode (IPV4 & IPV6). The IPV6 address is a much longer address.
2. Navigate to the BASIC .... DNS. Is the DNS Obtain set for Auto or Manual. If its set to Manual, what are you using for DNS addresses, Rogers, Google, OpenDNS, other?
3. Do you happen to have hard set DNS addresses in your pc and other devices? If so, what are they set to, Rogers, Google, OpenDNS, other?
If your using the Rogers DNS address, its easy to avoid the IPV4 DNS packet loss that your seeing with Pingplotter and with the command line ping. Thats simply a matter of using one of the other DNS providers such as Google, OpenDNS, Quad 9, or others. The only question that relates to this is the IPV6 status of the modem, ie: enabled or disabled. That can be seen on the BASIC .... GATEWAY FUNCTION tab. With Dual Stack running and the pc and other equipment using IPV6, you then have to provide both IPV4 and IPV6 DNS addresses for the entry windows in the BASIC .... DNS .... DNS Obtain .... Manual settings.
When I know what mode the modem is running in, IPV4 or Dual Stack, I might ask you to run a test to the IPV6 DNS address.