Tcping64.exe

[Egisto Chancellor]

IntermittentlyI get between 120-500ms latency spikes that last a few seconds in online PC games, especially Overwatch and Apex Legends. These happen every few minutes and don't last long. They're enough to make the game unplayable at moments. I average between 50-100ms normally.

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.

Yes, I have my modem in bridge mode to an external router. I have done isolation testing all on ethernet. The results I am seeing are that in the evenings there is packet loss at the CMTS hop. During the day time with less neighborhood load I am not seeing the same level of packet loss spikes.

@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.

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.

@Datalink this was helpful insight into the data as I had a technician look at my power levels and resolved it through replacing the 20 year old coaxial line to the Rogers demac housing on the side of my house.

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.

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 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.

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.

-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.

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.

-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.

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?

3a8082e126