You need to rule out problems one at a time:
- Troubleshooting your own equipment is on you but it sounds like you've done that.
- Next you need to determine if your physical connection is working properly. That involves signals and logs.
- Then, only if you have determined that the physical connection is working, you can explore the possibility of node saturation.
It sounds like your physical connection still has some issues. Noise and "hum" will cause problems. "Hum" is just a name for a certain type of noise. You will also hear names like "ingress" or "backfeed". These are different names for the same general problem. Understanding these words won't help you solve your problem. Knowing precisely which one it is won't help you solve your problem. There's no question you can ask about these words that will help you solve the problem.
If you have uncorrectables on your downstream signal screen, that's a sign of high frequency noise and/or ingress. You can't fix this and you can't ask any questions that will help you fix it. Only Cox can fix this. But you can show them the signal screen to help them know what frequencies to look for the noise on. For example, look at my signals:
Downstream Bonded Channels |
Channel ID |
Lock Status |
Modulation |
Frequency |
Power |
SNR/MER |
Corrected |
Uncorrectables |
13 |
Locked |
QAM256 |
855000000 Hz |
8.5 dBmV |
42.1 dB |
211 |
0 |
1 |
Locked |
QAM256 |
783000000 Hz |
10.1 dBmV |
43.2 dB |
41 |
0 |
2 |
Locked |
QAM256 |
789000000 Hz |
10.3 dBmV |
43.2 dB |
35 |
0 |
3 |
Locked |
QAM256 |
795000000 Hz |
9.7 dBmV |
42.9 dB |
70 |
0 |
4 |
Locked |
QAM256 |
801000000 Hz |
9.8 dBmV |
43.0 dB |
55 |
0 |
5 |
Locked |
QAM256 |
807000000 Hz |
9.5 dBmV |
42.6 dB |
79 |
0 |
6 |
Locked |
QAM256 |
813000000 Hz |
9.2 dBmV |
42.6 dB |
128 |
0 |
7 |
Locked |
QAM256 |
819000000 Hz |
9.3 dBmV |
42.5 dB |
93 |
0 |
8 |
Locked |
QAM256 |
825000000 Hz |
8.9 dBmV |
42.3 dB |
163 |
0 |
9 |
Locked |
QAM256 |
831000000 Hz |
9.0 dBmV |
42.2 dB |
142 |
0 |
10 |
Locked |
QAM256 |
837000000 Hz |
8.8 dBmV |
42.3 dB |
171 |
0 |
11 |
Locked |
QAM256 |
843000000 Hz |
8.7 dBmV |
42.1 dB |
138 |
0 |
12 |
Locked |
QAM256 |
849000000 Hz |
8.8 dBmV |
42.4 dB |
130 |
0 |
14 |
Locked |
QAM256 |
861000000 Hz |
8.4 dBmV |
41.4 dB |
175 |
0 |
15 |
Locked |
QAM256 |
867000000 Hz |
8.2 dBmV |
41.5 dB |
218 |
0 |
16 |
Locked |
QAM256 |
873000000 Hz |
8.0 dBmV |
41.9 dB |
279 |
0 |
33 |
Locked |
QAM256 |
357000000 Hz |
7.0 dBmV |
43.9 dB |
0 |
0 |
34 |
Locked |
QAM256 |
363000000 Hz |
7.1 dBmV |
44.2 dB |
0 |
0 |
35 |
Locked |
QAM256 |
369000000 Hz |
7.3 dBmV |
44.3 dB |
0 |
0 |
36 |
Locked |
QAM256 |
375000000 Hz |
7.3 dBmV |
44.2 dB |
33 |
0 |
37 |
Locked |
QAM256 |
381000000 Hz |
7.5 dBmV |
44.2 dB |
42 |
0 |
38 |
Locked |
QAM256 |
387000000 Hz |
7.5 dBmV |
44.1 dB |
30 |
0 |
39 |
Locked |
QAM256 |
393000000 Hz |
7.6 dBmV |
44.1 dB |
0 |
0 |
40 |
Locked |
QAM256 |
399000000 Hz |
7.6 dBmV |
44.1 dB |
0 |
0 |
41 |
Locked |
QAM256 |
405000000 Hz |
7.8 dBmV |
44.1 dB |
0 |
0 |
42 |
Locked |
QAM256 |
411000000 Hz |
7.9 dBmV |
44.0 dB |
0 |
0 |
43 |
Locked |
QAM256 |
417000000 Hz |
8.0 dBmV |
44.2 dB |
0 |
0 |
44 |
Locked |
QAM256 |
423000000 Hz |
8.1 dBmV |
44.1 dB |
0 |
0 |
45 |
Locked |
QAM256 |
429000000 Hz |
8.2 dBmV |
44.2 dB |
0 |
0 |
46 |
Locked |
QAM256 |
435000000 Hz |
8.3 dBmV |
44.2 dB |
0 |
0 |
47 |
Locked |
QAM256 |
441000000 Hz |
8.3 dBmV |
44.1 dB |
0 |
0 |
48 |
Locked |
QAM256 |
447000000 Hz |
8.3 dBmV |
44.0 dB |
0 |
0 |
159 |
Locked |
Other |
300000000 Hz |
6.5 dBmV |
42.2 dB |
1982721905 |
0 |
My connection works perfectly because I have no uncorrectables after over a week of uptime. IMHO, a continually increasing number of uncorrectables always indicates a major connection problem. Every now and then (less than twice a month) you might see a brief spike when something is disconnected for maintenance overnight. But if uncorrectables are growing and growing, your connection is no good. Cox probably considers a certain number of uncorrectables to be acceptable because no ISP can afford to keep all connections 100% perfect all the time. But to me, uncorrectables are never acceptable.
You can learn a bit about my connection from these signals. For example, you see some correctable errors on all of the mid-frequency (700-900 MHz) channels. That means that the connection isn't quite perfect in that band. Something is letting in a tiny bit of noise in that whole frequency band but it's not causing me any problems at all. However I will keep an eye on this because if those numbers start growing at a faster rate it means the connection is degrading and might go bad eventually.
On the lower-frequency channels, you see it's almost perfect with one exception. You can see that right around 381 MHz, there was an incident where a small amount of noise came in on that frequency range. It was definitely caused by something outside my home, but it didn't cause me any real problems. Like before, I can keep an eye on it to see if it starts getting worse or if it starts to cause uncorrectables.
You can analyze your downstream signals in the same way to determine if you're getting noise all across the band or if it's isolated to a small frequency band. Let your modem run for at least 3 days without resetting it so you can get a proper picture of the error rate. But learning this won't help you solve the problem. There's nothing you can do to solve the problem.
If you have Dynamic Range Window violations in your modem logs, it means you have some noise on the low-frequency upstream channels but it's mostly harmless.
If you have T3 timeouts in your modem logs, it means there is problematic noise on the low-frequency upstream channels and you will have packet loss. You can't get as much detail about this as you can on the downstream. All you can do is know that the noise is on the upstream. You can't fix this problem.
The possible causes of noise, ingress, and backfeed are too long to list. It could be any of hundreds of different things. No matter how many questions you ask, you won't be able to figure out what it is. Only Cox can figure it out. And it might be very hard for them to figure it out since it could be hundreds of different things.
Once you get your connection so that it has no uncorrectables and no T3 timeouts, only then should you use PingPlotter to isolate potential node congestion. But even if you determine that the problem is node congestion, there's nothing you can do to fix it. Only Cox can fix that.