Hi all,
I wanted to chime in here too with some feedback, I for one am very happy with my results, last night I got updated to 2.0.10.36T5 overnight seamlessly. Today when I woke up, both myself and my wife typically work from home and we noticed a huge improvement in our speeds and even the wifi range. Not only that, the speeds are where they should be both on wifi and ethernet using only the rogers modem itself. This is the result consistent for my connection after the update to 36T5. 
Before this, it was closer to 500ish with around 15-17 ping, upload about the same. Slightly higher on Ethernet, but not even close to this speed!
I have yet to test if bridge mode works now and has been fixed on my side, as it wasn't working before, but to be honest, if this is the speeds and consistency I will continue to have, then I will not even bridge my modem as this is optimal! I know that not everyone may have the same results and I do agree we have been dealing with a lot of frustrations and ups and downs for some time, but this to me is a HUGE improvement and makes me feel that the money I am spending for service is worth it and justified. This is my opinion only and I truly wanted to say thank you for making a change to Rogers, thank you to the Devs and Engineers that worked on this. I will keep you all posted on my results after a couple of days and let's hope this sticks!!
Edit: It might help to mention that I have 3 mobile phones on wifi, 3 computers on ethernet, PS4 on wifi, an IPAD on wifi, an IPTV Android Box on wifi, my Sony smart TV on wifi. Obviously not everything is used at the same time but with the test results, the TV was on, 3 cell phones are on (2 personal, 1 work constantly being used) IPTV Android Box was on, 2 laptops where on and I think my niece was using the IPAD at the same time too.
Good for me as well but I always have good speeds but this time my Upload is better as most of the time it's below 30Mbps.
@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.
- last edited on by
RogersAli
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. 2.0.10.36T4 - 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 2.0.10.36T4
Ok, an interesting plot to say the least the first plot that is.
- First point, this is only a 10 min run with numerous packet loss and latency instances. The red denotes packet loss.
- Hop #2, the Cable Modem Termination System. The response time is crazy and not reliable due to the modem processing timing. The packet loss indications for Hop #2 are correct however, and in this case there is only one instance for this hop.
- Hop #6 and #7. If this data is accurate, the latency and packet loss to these two servers will cause problems. Hop #7 is shown on the plot. This is the DNS that your network is probably using unless you have entered different DNS addresses such as Google or OpenDNS into the modem. If this is accurate, your DNS lookups for IP address will suffer, so your web pages will load slower due to the latency to the DNS and due to the lost data that the packet loss will impose. This would cause neverending problems for all applications.
So, there are a couple of things to do.
- Test Hop #2 to see if there are any packet loss issues between the modem and the CMTS.
- Test Hop #7 using a command ping to confirm the Pingplotter results. Not that I don’t trust Pingplotter, I trust a command ping more…..
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 174.117.144.1 –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 64.71.255.204 –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:
- Packet loss and latency from the modem to the CMTS and back again; and/or
- Packet loss and latency to and from the DNS.
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 64.71.255.204 (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?
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 64.71.255.204.
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.
Edit:
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.
-
974090 views
-
669 Likes
-
-
