still high pings an slow speeds..
Ping statistics for 99.240.xxx.x
Packets: Sent = 200, Received = 198, Lost = 2 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 427ms, Avera
@lethalsniper can you log into your modem and navigate to the BASIC .... GATEWAY SETTINGS. Is the Router Mode configured for IPV4 or Dual? If it's set for Dual, that means that the modem and connected devices are using both IPV4 and IPV6 with IPV6 being the default address mode. If the modem is set to run Dual Router Mode, then the XBox will be using IPV6 addressing instead of IPV4. That brings about the possibility of IPV6 issues at the CMTS or upstream.
Fwiw, you should not be seeing regular spikes or averages up to 500 ms when you ping the CMTS. Your ping tests only show IPV4 addresses, but, I'm wondering at this point what the current Router mode happens to be.
@lethalsniper real solution, don't use Pingplotter:
1. Pingplotter generates a lot of traffic;
2. Over long time periods, the displayed data is averaged instead of showing the maximum and minimum times on the plot. So, when you run a test for 24, 48, 72 hours, etc, it will look like a flat line although you can have extremely high latency spikes occurring within that plot. It boils down to the number of horizontal pixels versus the amount of data per pixel that should be displayed. At low time periods on the plot, 60 seconds, 1, 5 and 10(?) minute plots, you're essentially looking at on data point per horizontal pixel, so you will see the higher latency spikes. As you scale up in plot time, 30 minutes or higher, you can run into situations where you have more than one data point per horizontal pixel, so, Pingplotter averages the data without telling you. If you hover your mouse over a point on the plot, it will show the point data, either as a single data point, or it will show the number of data points in that horizontal pixel. Thats the only way to know if the plot has switched over to averaging the data points.
The upper text area will show the max and minimum times, etc within the plotted time and is not affected by the plot averaging scheme.
Right click on the column titles to bring up the title menu selection. Select MAX to display the maximum time column and drag that to the right to sit beside the MIN time column. Don't know why Pingplotter doesn't set that as a default configuration, unless they've changed that recently.
Ok, so, with the data selection on AUTO, so that the text data time period matches the plot time period, the text data will show the MIN and MAX time, etc, for the plot time period. If you've scaled up in time, in a long test, now you have a problem, in that the plot will essentially be a flat line but the text data will or could show a high latency time. So, where is the high time spike? Now you have to scale down to something like 30 minutes or less, more likely 5 minutes or less and scroll thru the chart, section by section looking for the high time latency spikes. In a nutshell, if you have problems with high time latency spkes, Pingplotter fails to do the job that you're asking of it. Yup, you can determine where those high time spikes are, but, it can be a laborious task, and you can't see the overall picture of what the latency issue looks like.
You can also drive Pingplotter to flatten the plot by dropping the time interval down. The default time interval is 2.5 seconds. In theory, depending on your monitor size, that should allow pingplotter to run for 24 hours and display the plotted data without any averaging. That time interval can be adjusted manually by selecting 1 second or 0.5 seconds. You can also enter your own time, such as 0.1 for 100 Milli-second intervals, 0.020 for 20 ms intervals, 0.005 for 5 ms intervals, etc, etc. Now, as you drop the interval time between pings, that results in more data per horizontal pixel, driving Pingplotter towards averaging the data. You have to experiment with a time period you would like to display, I'd suggest starting with a 5 min plot or below, and trying different time periods to see where Pingplotter starts to average the data, as seen by a given horizontal pixel displaying more than one data point. When you drop the time period far below 1 second you can end up with plot averaging at a 60 second plot.
Fwiw, if you're testing latency from the CMTS, you need to be running a 20 ms ping interval with the CODA-4582. With version 18.104.22.168, you will see latency spikes up to 80 ms. I didn't check version 33 but finally in version 35 those high latency spikes are gone. So, depending on what firmware version you have, you may or may not be able to use the CMTS as a ping target, looking for latency. If version .33 shows regular high latency spikes with 0.02 entered as a time interval, then the next choice is to use the DNS addresses: 22.214.171.124 primary and 126.96.36.199 secondary.
For the purposes of using the CMTS as a ping target, you need to know if you have .33 or .35 loaded. With .33 loaded, run a test with 0.02 second intervals. That will only take a few seconds to see the latency spikes, if they're still present in .33. If you have 188.8.131.52 loaded, then you can use the CMTS as a ping target at any time interval, although practically speaking, 0.015 seconds is about as low as you want to go for short test periods. The typical average is around 8 to 12 milli-seconds, so, trying to use an interval at or below the normal average will result in lost packets
Ok, so, back to the original question, Select the Focus on Auto, and for any longer term testing, as in hours long test periods, I'd suggest 1 second intervals. The lower the interval, the more spikes you will get, which of course won't necessarily show up on the plot depending on what time interval the plot is set for, but, when you scale down in time periods, you will have more data to examine with 1 seconds intervals.
The one item that Pingplotter does well is to test for packet loss from the modem, or the CMTS. Thats about it. Packet loss shows up very well on the plot, you can't miss it.
One last item on Pingplotter, you can and will end up with false packet loss indications from the modem and CMTS due to a timing issue up to and including modem firmware version 184.108.40.206. 220.127.116.11 I'm not sure of, and can't test it anymore, and now with 18.104.22.168 loaded, I haven't tested for that just yet.
If you're interested in using Wireshark, to plot latency testing you would need to download the following:
1. Wireshark from: https://www.wireshark.org/
2. Notepad++ to look at the text data files: https://notepad-plus-plus.org/downloads/
3. HrPing for IPV4 ICMP ping testing: https://www.cfos.de/en/ping/ping.htm
4. TcPing64 for TCP/IP testing from: https://download.elifulkerson.com/files/tcping/current/x64/
5: Microsoft PsPing from Microsoft Sysinternals: https://docs.microsoft.com/en-us/sysinternals/downloads/psping
6. DnsMonitor for UDP testing from Tallsoft.com: http://www.tallsoft.com/
I would have to write up a few instructions on what applications to use and how to use them. Wireshark, Notepad++ and DnsMonitor are all standard windows applications. HrPing, TcPing64 and PsPing are command line applications.
I'd also have to write up instructions for Wireshark display filtering. Or, it looks like I might be able to send the display filter setting thru a DSLReports message. Don't know if I trust the forum software enough to think that the filtering file would arrive unscathed at your end.
Let me know if you're interested in trying Wireshark. Here's a couple of examples from a CMTS IPV4 ICMP ping test last Friday 22 Jan 2021. This was run at 15 ms intervals (0.015 seconds), plotted at 100 ms intervals. I would expect a test using your CMTS to result in a similar result, although, I'm really interested in seeing how it turns out given the numbers that you have reported so far. This is a short test, typically I'd run a slower test for 24 hours looking for changes in latency over the course of a whole day.
Note that you can change the plot times for the plotted data as in plot the data for 100 ms, 1 second, 10 second, 1 min, etc time spans, but, the higher and lower response times are still displayed on the plot, unlike Pingplotter which averages the data instead of displaying the MIN and MAX data points. Wireshark doesn't have a great selection of time spans available to plot the data, so sometime you have to work around this by running tests at lower ping intervals. I'd like to see Wireshark increase the number of available time spans for plotting the data.
The two plots are the same, with the bottom plot being a close in view. The bulk of the returns run from about 8 ms to 16 ms with the average showing around 10 ms. That's a typical DOCSIS return. These plots are generated with a CODA-4582U 2A running in Bridge mode with an Asus RT-AC86U behind it. It shouldn't matter if the modem is in Bridge mode or Gateway mode. I haven't checked Gateway mode but I don't expect to see any differences. The modem is running DOCSIS 3.1 down, DOCSIS 3.0 up. Contrast that with the plots for Bell's VDSL service as shown throughout the following thread:
It will be interesting to see the plots when DOCSIS 3.1upstream (OFDM) is enabled at my CMTS.
Ok, I'll have to write up some instructions on loading the various applications and how to use them. I also need to rearrange the Wireshark Display Filter file and send that to you
For Wireshark scroll down to the bottom of the Wireshark.org page. You will see various download files. Select Wireshark Installer (64 bit). That will load Wireshark and NpCap which is used for data capture from the pc interfaces. NpCap can be loaded using the default values that it shows. Uncheck the setting to load NpCap for Administrative use only. Don't remember the exact wording but that's close. With the setting uncheck, NpCap will run for all pc users who are using Wireshark, so, assuming that you use a User Account on a daily basis, you shouldn't have any problems running Wireshark when you select it to start.