That 4k indication would mean that the modem is using OFDM 4096 sub-carriers for downstream data. If that section indicates N/A, NO, I would presume that means that the OFDM channel data or data lock has been lost and the modem has reverted to DOCSIS 3.0 mode. So, you go from using 4096 sub-carriers to 32 channels. In either case, the modem should be capable of running 900+ Mb/s on the downstream side.
Yeah, that will be the issues.
If its something like the CMTS, or any of the local nodes before it gets back to where its switching to the TPIA, you could run into similar issues.
Rogers pretty much own all the cabling networks. (other than a some areas with shaw, etc). But none of the small ISPs have their own.. they all rent off the bigger guy. And the CMTS is run by them.
If its just a routing issue, etc.. (bad node inside that providers network or path that its taking), going to a TPIA would be fine.
Depending on where you are.. switching may not be an option either 😞
EG: Myself, I can can get up to 250mbps service through rogers/TPIA, but bell (or any TPIA on bells lines), i max out at 15mbps, as bell's network has not been upgraded where I am.
@lethalsniper yes, there is an issue there, specifically with the return from the CMTS. Those high ping spikes from the CMTS started in version .27, and they've carried thru in every version since. The other issue is packet loss indications from the CMTS when in fact there is no packet loss. The problem is the internal modem processing. This was fixed in the CGN3ACSMR a long time ago. I don't know if it still is fixed, or if its become a problem once again. If you drop the ping interval time down to 0.010 seconds by manually entering that figure, you would see that the ping spikes run in groups. So, you'll see a normal return for a period of time, followed by a high time return for a period of time, back to a normal section return, and on and on. You will probably see packet loss indications as well which are false indications. If you were to run a command line ping with the same interval, you would see the same normal time, high time, normal time, etc, etc. The only time where you would see packet loss indications is in fact if that timeout actually occurred due to packet loss, or due to the return being delayed that the ping application times it out. Back and forth to the CMTS, that shouldn't happen unless there actually was a problem in the modem to CMTS path.
The upshot at the present time is that you can't use the CMTS as a target to gauge upstream congestion at the CMTS. You have to use the DNS instead, even though I'm not in favor of doing that. You also can't use Pingplotter with the 4582 for the purpose of determining packet loss, you have to use a command line application to determine the loss over a period of time. The two of these combined really makes troubleshooting at the local level a problem which needs addressing, personal opinion.
When you go beyond the CMTS, you won't see the high time ping spikes, so, although the return from the CMTS is a problem, it doesn't appear to impact anything that goes beyond the CMTS. I've run both simultaneously and haven't observed an identifiable correspondence between the high time CMTS return, and the simultaneous return from the DNS or any other ping target.
If you were looking to check IVP4 ICMP return times, ping the DNS, 64.71.255.204 or 64.71.255.198 using an interval of 0.5 seconds or perhaps 1 second if you want to run that for the entire day. From Ottawa, the .204 server is the faster of the two. That might be different given your location and distance from both servers.
Just as a reminder, Pingplotter averages the data on the plot. At an interval of 2.5 seconds you can display 24 hours of data without any data averaging on the plot. When you step down in ping intervals, Pingplotter starts to average the data. That data averaging will depend on the number of sample points that are included in a given plot area. At low plot times, ie: 60 seconds and perhaps 5 minutes, you probably won't see any data averaging. As you go up in timeframe, working up to 24 hours and beyond, Pingplotter averages the data points in the plot. Essentially it comes down to having x many data points that need to be represented in a given horizontal display pixel. Pingplotter has chosen to average the data instead of preserving the high and low ping times, so, any high time returns are lost as you go up in plot timeframe. The plot looks better and better as you go up in timeframe. Thats very unfortunate as it forces the users to review the data at low plot times, which if you're looking at 24 hours or more of data, is a complete pain, having to scroll across 24 hours or more of data, looking for high time events.
Fwiw, I'm working on posting a set of instructions to do this with Wireshark, which doesn't average the plot data. Just have to get around to doing it.....
Hope this helps.
For the CODA-4582 modem:
In the case of detecting packet loss from the CMTS, yes, Pingplotter is useless as it presents false packet loss indications. You need to use a command line ping application to accurately determine if there is a packet loss problem.
As for the response time from the CMTS, that's a modem issue that requires fixing. So, you can't ping the CMTS looking for possible congestion at the CMTS.
If you're attempting to use Pingplotter to determine congestion issues, then you have to ping the DNS. Same for Wireshark. That keeps the total path to a minimum and keeps the target within the ISPs network, in this case, within the Rogers network.
Instead of pinging the CMTS, ping the DNS, 64.71.255.204 or 64.71.255.198 using an interval of 0.5 seconds or perhaps 1 second. Let that run for an entire day. If you want to run the plot without data averaging, use Pingplotter's default interval time of 2.5 seconds. If there is a large difference between the very early morning hours when there is almost no traffic, to the later evening hours where there are high traffic times, you should see that on the plot. Just a matter of using the DNS address as the target instead of the CMTS. Use the DNS IP address plot (default plot) to make the comparison. Its not an ideal situation.
Edit: One thing you could also try is to use the next IP address beyond the CMTS and see how that turns out. Try a test run with the ping interval set to 0.010 seconds, looking for the high time pings. If they show up, go to the next address on the trace. At some point, the return times should settle out. Wherever the return times settle out, use that as the target for an extended ping test. This is now on my list of things to do.
I don't believe the packet loss at this point. Time for a command application. Download Fping from:
http://www.softpedia.com/get/Network-Tools/IP-Tools/Fping.shtml
The command line to run Fping to the .204 DNS is:
fping 64.71.255.204 -t 10 -c -D -T -L c:\temp\fping13mar.txt
-t 500 That runs a ping at 500 ms intervals. For test purposes, drop this to 10 for a fast run.
-c Runs continuously until stopped with a Control C
-D Stamps the result with a Datestamp
-T Stamps the result with a Timestamp
-L Writes the results to a text file, in this case located in the C:\temp folder.
Change the folder location if you prefer, or delete this altogether if you don't want
a text record
If you change the address to the CMTS address and run it at 10 ms intervals, you can asses very quickly if there is a packet loss issue to the CMTS. Run that for a minute or two at 10 ms intervals and then stop the run. You can then check the results, looking for packet loss. To run that for a longer period, I would set the time for 500 ms, -t 500 You can also specify the number of pings to run using something like -n 1000 instead of -c. After 1000 pings the application will stop. So, you can set this for a low interval run, and set the number of pings to run.
A simpler version of this is to run the normal ping command, using the CMTS as the target. Let that run for however long you want to run it, and then check the packet loss numbers when you stop the run. That will run the ping with a 1 second interval.
1. Run a trace to anywhere: tracert www.google.com
2. Look at the trace address. The first is the router or modem, the second will be the CMTS.
3. Use that CMTS IP address as the ping target: ping 99.xxx.xxx.xxx for example. That will run until you bail out of it.
That uses the normal ping command that is available thru the command prompt. It will run one ping per second.
-
11955 views
-
17 Likes
-
-
