Hello, @AaronMT.
Thank you for your post; latency spikes can surely hinder the gaming experience.
Let’s work on isolating the issue; we need a tad bit more info:
- Is your modem in bridge mode?
- The first hop seems to be your modem itself. Have you checked the Ethernet cable condition between your router and the modem?
Please bypass your router, unbridge the modem if necessary and run the ping and traceroute tests on a wired computer to your gaming server. You can follow the steps listed in our knowledge base article.
We look forward to the results.
Cheers,
RogersMoin
@AaronMT I had a quick look at the data you had posted previously, prior to its disappearance. Your ping time to the CMTS was above 40 milli-seconds. It should be down around 13 ms or possibly slightly lower.
Your power levels in the posted signal levels show that the downstream levels are all slightly low, but, that shouldn't be a problem. All of your upstream levels are too high. Rogers used to use 52 dBmV as a cut off point before they will do anything. I believe that they've moved that to a higher level, but, don't quote me on that one. The DOCSIS spec indicates 51 dBmV as a max power output level for three or four upstream channels.
In any event, your upstream levels are too high although I suspect that Rogers won't do anything about it. With levels that high, it would only take a momentary move upwards, in terms of power levels before the modem starts to shut down upstream channels one by one, in order to maximize the output power on the remaining upstream channels. If that happens, you would notice a drop in the data rates, both downstream and upstream.
So, the question is, why are those power levels so high. That will take a field tech to determine the cause.
If you looked at the entry point, where the incoming cable enters your home, do you happen to have a powered amplifier in operation, or perhaps a splitter installed. Either one of those should have been removed when your modem was installed.
Edit: The normal signal range for QAM channels is 0 dBmV on the downstream side and 36 to 40 dBmV on the upstream side. My personal opinion is that you have a cable signal problem that requires further investigation. It doesn't matter what mode the modem is operating in, Gateway or Bridge, you will still have the same signal problem and same results that you're experiencing.
Hi @AaronMT,
Your upstream power levels are looking better, not all the way down to the typical 36 to 40 dBmV range, but, their better. I'd bet that your external cable also needs replacing if if hasn't been replaced/installed within that last 20 years. If you've managed to get 20 years out of that cable, consider yourself lucky. Most of the time they don't last anywhere near that long. So, if you suspect that you're still seeing issues, that would be one item to consider. If the cable is underground, the techs can use run a time domain reflectometry test, (TDR) for short.
https://en.wikipedia.org/wiki/Time-domain_reflectometer
Unplug both ends of the cable, connect the test equipment to one end, run the test and then run the same test from the other end. The TDR essentially pings the cable, looking for a reflected signal from the other end. In theory, a serviceable cable will show the same ping response time (length) from tests conducted at both ends. If there's a difference in the cable lengths between the two ends, then the cable has a fault, most likely water ingress, and requires replacement. An overhead cable could use the same test, but, I believe the only qualified utility pole techs are actual Rogers techs, not the usual contractor techs. Just looking at an overhead cable would probably be enough to determine if it requires replacement, especially if its been in use for a very long time.
For the CMTS, what you want to do is run a long ping test. I run these for 24 hours, typically testing for response times after a firmware update. Run a minimum of one hour, maximum of 24 hours, but, you can go longer. Fwiw, each day will show similar, but not identical results. I'd recommend downloading hrPing from https://www.cfos.de/en/ping/ping.htm. That will allow you to run ping tests using adjustable ping times and write the results to a file that you can look back on.
hrPing is a command line utility, so, I'd recommend parking it in a folder that you can easily access using a command line.
When you have hrPing start a command prompt which has administrative privilege's. From what I remember, you will need to acknowledge the copywrite statements when you start hrPing for the very first time. When that is out of the way, you can use a user command prompt to run the program. You might get a statement indicating that you attempted to access a socket in a way forbidden by its access permissions. So, this is due to using a user command prompt instead of an administrator command prompt. You can if you prefer, run hrPing using an administrative command prompt.
To see all of the options for hrPing, type hrPing at a command prompt when you've navigated to the folder containing hrPing and hit enter.
For the task at hand, to ping the CMTS.
Run an IPV4 trace to anywhere, google for example. At a command prompt, run:
tracert -4 www.google.com
The first IP address in the trace will be the router if the modem is in Bridge mode. The second IP address will be the Cable Modem Termination System (CMTS). Ping the CMTS.
Run the following: hrping -t -T -s 500 -F pingtest.txt xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the IPV4 CMTS IP address. Note: hrPing is IPV4 only.
That will run a ping test to the CMTS which will keep running (-t), until you stop it by using Ctrl c.
The -T will print a time stamp at the beginning of each record.
-s is the ping interval in milli-seconds. The default is 500 ms, so, you can adjust that up or down as required. For ping tests to the CMTS, if I wanted to print a higher resolution, I would probably drop that down no lower than 400 ms. I usually record the results with Wireshark and plot the results. In order to plot down to 1 second resolution, Wireshark requires two or more pings per second, hence the 400 ms ping intervals. For your current purposes, consider using 1000 ms as a ping interval (1 sec).
-F pingtest.txt will generate and populate the test record in the folder where hrPing is located. You can use any file name that you want as long as you stick a .txt at the end of the name. The file can be written anywhere, such as -F c:\temp\pingtest1Jul.txt, or any other folder location. If you're going to be running tests like these, consider setting up a test data folder somewhere and use sub-folders to separate the data by date. That way, you can look back on the test results according to the test date.
If you wanted to run a 24 hour test for example at 1 second intervals, the command would be:
hrping -n 86400 -T -s 1000 -F pingtest.txt
After the last ping, the test will terminate automatically.
So, this is one method. You can also possibly do the same using TCping. That will run a TCP/IP ping test to the CMTS port 53. There is no guarantee that it will work as it depends on whether or not the CMTS is configured to answer a TCP/IP ping. Some are, some aren't. You can try it, but as I indicated, it may or may not work.
TCPing can be downloaded from: http://www.elifulkerson.com/projects/tcping.php Drill down to the x64 folder to download tcping64.exe
To see the various options, once again, use a command prompt in the folder where you've parked the tcping64.exe file.
To run a ping test, once again, you're going to use the CMTS address from the trace. The command for a TCP/IP ping test, as an example, is as follows:
tcping64 -t -d -i 0.25 -4 --tee tcping1Jul2020.txt 8.8.8.8 53
That will ping google's DNS server with the following:
-t continues the ping test until stopped by using Ctrl c
-n 100 for example runs a 100 ping test and terminates after 100 pings. Delete the -t and use -n 100
-d includes a date and time stamp for every record
-i 0.25 runs ping intervals of 0.25 seconds (250) milli-seconds. I don't recommend this unless you're running a test for your router or modem. I wouldn't run anything under 400 milliseconds against the CMTS or the Rogers DNS. Anything lower when testing against the Rogers DNS will likely get you banned from the DNS server for 24 to 48 hours. I don't remember off of the top of my head if your modem allows you to select a particular DNS or if its permanently set for the Rogers DNS. If its permanenely set for the Rogers DNS, getting yourself banned for a period of time might be a problem.
-4 runs the test using IPV4. TCPing 64 can run IPV6 tests as well
--tee tcping1Jul 2020.txt writes the results to a file that it will generate in the folder where the tcping64.exe file is located. If you use the same name for consecutive tests, the last test will overwrite the previous test results.
8.8.8.8 53 in this case runs a test to the google DNS at 8.8.8.8 using port 53 as the target port. Use port 53 for testing the CMTS IP address and DNS servers.
The output of the TCPing test is much cleaner and easier to read thru.
If you manage to run a TCP/IP ping test, you will see that the response time is much lower. It will show around 1.5 ms. The ICMP test will result in a typical result of ~13 ms.
There is also a way to run these tests using Windows Powershell. I have that stored somewhere, so don't have it handy at the moment. Powershell allows you to run the Windows ping test and write the results to a file from what I remember. That should also allow one to use Microsoft Sysinternals to run ping tests as well and write the results to a file.
Fwiw, what you're attempting to do is actually very difficult. It was much easier just a few short years ago when you might have been able to run these tests with very little load on the modem itself. Now, with people working from home, running Comcasts IPTV (Rogers Ignite), other streaming videos on other systems, and gaming, there is a larger constant load on the modems with higher transmit/receive priorities for other data. That can cause unpredictable spikes in the test results. So the question arises, is it something locally generated that is causing the spike, or an issue at the CMTS. You have to be aware of other users in the home and what they might be running. When you get down into the weeds, with much smaller ping time intervals, something like a application on a pc/laptop/tablet calling home can cause an unexpected ping spike. That includes everything from social media or work apps to pc/laptop/tablet system applications looking for updates. That's where Wireshark comes into play, so that if you see a large spike in the result, you can go hunting for a possible explanation. That's easy if you're the only user on the system with a single pc, but, if there are other devices running on your network, this becomes very difficult. Ideally you would be able to disconnect everyone else from your local network, but, that's probably not going to win any favours from family members. You might be able to get away with that for short periods of time 🙂 With no other traffic thru the modem, and just the test running to the CMTS, the results should speak for themselves, good or bad.
In order to really see the change throughout the day you need to run a test for 24 hours. That way, you capture data from the very quiet periods in the morning from about 3 to 6 am and the ramp up in the 8 to 9:30 am and 7 to 10 pm time periods. Having that data available will show what the response times are with little load on the CMTS in the very early morning hours, and what they are when the CMTS is possible heavily loaded later in the day. The question is, what's the typical response time under heavy loads, and is it acceptable for what you might be running?
Just to note, you can run these tests against your router or modem for practice and experimental purposes, dropping the ping intervals down to a minimum. With a ping interval of 5 ms or lower for example, you should see response times under 1 ms for both router and modem. That time really shouldn't change if you run 1 second intervals instead, but, if you wanted to see the results for very short ping intervals, don't be afraid to give that a go, as its an internal test, not one that runs across the internet.
If you post the bottom results of the test to the CMTS for example, change the last three digits of the IPV4 address to xxx, just to keep the CMTS address secure.
Food for thought, if you could run an IPV6 test to the CMTS, you would probably see different results from the IPV4 test. In theory, IPV6 should be faster, but, I wouldn't guarantee that. If you used the Windows command prompt, you should be able to run an IPV6 test to the CMTS. Same process applies here, run an IPV6 trace to google for example:
tracert -6 www.google.com
In this case, the first IP address should be the IPV6 address of the modem (don't post this). The second IP address will be the CMTS. As before, this time with the Windows ping command, ping the CMTS. If you run the test long enough, it will force the initial results out of the command windows buffer, so you wouldn't be able to scroll thru the whole log from beginning to end. There is a limit that I don't remember off of the top of my head.
Last but not least, there is Pingplotter which is built for testing like this. Only problem with Pingplotter is that it averages the plot data when you scale up in plot display from 5 min, 10 min etc, all the way up to 72 hours for the pro version. What you're basically doing is cramming more data into a fixed horizontal display area. So for displays of 5 or 10 minutes it will show one data point per pixel. At high time displays of hours or days, you end up with more than one data point per horizontal display pixel, where Pingplotter averages the data instead of showing user selectable max or minimum times. That's very unfortunate as the end result, when you go to display several hours or days of data, is that the response line flattens right out, as the data has been averaged for every display pixel. You could have a number of high time spikes within the data, but you won't see them when you're looking at data for a number of hours or days. You have to scale down in time frame and scroll thru the data in an attempt to find the high time data points. Too bad, other wise Pingplotter would be a very useful application, suitable for what you're trying to do at the present time 😞
Ok, that should do it for now. Give this a go and let me know if you have any problems running the tests.
@AaronMT one key point that I didn't mention in my post is that the ping testing needs to run via ethernet from a connected pc/laptop. That will rule out any wifi issues.
Just to clarify the CMTS IP address:
1. If you have the modem in Bridge mode with a router behind it, the router IP will be the first IP address in the trace assuming that you're running a direct connection to the router. The CMTS will be the second IP address in the trace;
2. If you have the modem in Gateway mode, with a direct connection to the modem, the modem IP address will be the first IP address in the trace, the CMTS will be the second IP address in the trace;
3. If for some reason you have the modem in Gateway mode with a router behind it in full router mode, and you're running a direct connection to the router, then the first IP address in the trace will be the router, the second IP address will be the modem and the third IP address will be the CMTS.
When you replaced the cable that runs to the demarc, did you use RG-6 cable?
Is the rest of the cabling in the house RG-6 or RG-59?
Consider replacing the F-81 connector in the wallplate that connects to the modem with a higher frequency connector such as the following:
https://www.homedepot.ca/product/ideal-3ghz-f-splice-adapter-10-pack-/1000751479
That shows up as a ten pack but you only need two of these, one for the interconnect between the demarc cable and the internal cable running to the modem, and one for the wallplate that connects to the modem.
-
4717 views
-
0 Likes
-
-
