Hello, I have contacted tech support a few times and techs have come out to check my cables. The techs say that the signal strength is good and I do receive the advertised speeds 100/10, but I suffer packet loss. I also get dropped from Skype calls at the same times I am lagging on League.... I am not sure what the issue maybe, any advice?
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||BandWidth|
|1||23700000||ATDMA - 64QAM||40.250||7||6400000|
|2||30596000||ATDMA - 64QAM||40.250||6||6400000|
|3||38596000||ATDMA - 64QAM||40.250||5||3200000|
© 2015 Hitron Technologies Inc.. All rights reserved.
Solved! Solved! Go to Solution.
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.
I see. Is it normal for it to lock/unlock like that? Speed has never been a problem for me per se (it's not super consistent, but I wouldn't expect cable to be) -- but in terms of packetloss, could that be causing anything?
I'm not trying to obsess over minutiae, just trying to examine everything I see since everyone keeps saying things look fine, but something has to be wrong.
Well, Live Chat refused to send a tech out, but Facebook Chat was happy to. I'll buy a beer to the manager of the Facebook team if I meet them, as their reps seem to be empowered more both in how candidly they answer your questions as well as what they can schedule/request.
We'll see how visit #2 goes!
Still no resolution to packet loss. The "Open Issues for Investigation" thread mentions UDP packet loss, and does not post a resolution, but is also a bit dated. I'm at a loss (pun intended).
I've engaged the Office of the President, and had half a dozen visits from senior techs out. Each time they come out they replace some part (new modem, temp line, new connectors in box from temp line) and things look "good" as far as speed tests go, then a week later I will lose OFDM Downstream, suffer wildly varying download speeds (200-800 Mbps on Gigabit plan) and most importantly - have packet loss the whole time.
The interesting part is the narrative. Before visits: everything is fine in your neighborhood, looks good, looks fine. Then they replace something. Then they come back and show me how bad it was before - showed me a graph of how, while support was insisting my entire neighborhood was fine, that there was SO much noise and so many issues on the line the graphs are off the chart in to the red zone on their software. But now, it must be fixed, because look how much better your neighborhood is. It's impossible to know what to believe.
It's reaching the point where the techs are starting to say things like, you know, there's no real guarantee about service at this level - we don't guarantee any packets. I realize that for someone trying to do something silly like high-frequency trading, this is not something to rely on. But I have persistent, ongoing UDP (at least) packet loss that is bad enough that every 20-30 seconds, video games I am playing pop up warning icons (and if they have 'levels' of warning, it's the highest/worst possible level) that my connection has packet loss.
I have long since crossed the threshold where the sheer amount of time I have spent on this would have paid, at some reasonable hourly wage, for a second internet connection.
A friend who lives in the same city as me, but via TekSavvy, only a few kilometers away, connects to the exact same servers - with me! - and does not have any issues.
As a last resort, I think I could set up an iperf3 instance in a couple AWS regions and try to hit it from my house. The thing is, I don't know if anybody even cares. The tech himself has said, "we just load the Rogers speed test, and if it looks good, we're done."
@daveinsurgent I've given up as well. I am looking into other ISP's but the issue is that they use Rogers current cabling system so I'm unsure if I'll run into the same problems. I am also under contract for a few more months though, so that sucks. I really don't know what else to do, I have feeling it's the CMTS failing. Can't really think of another possibility since my cable TV works fine without issue so it's not the cabling gone bad. I just suffer from ping spikes/packet loss.
A solution I found to make it just slightly better was to lower the MTU in my router. It seemed to actually improve my connection just a little bit. I've been too invested in this problem with Rogers that I will just switch service and be done with it (hopefully).
Does anyone reading this happen to know of another ISP with their own CMTS or cabling?
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, 126.96.36.199 or 188.8.131.52 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, 184.108.40.206 or 220.127.116.11 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:
The command line to run Fping to the .204 DNS is:
fping 18.104.22.168 -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.