Cablemodem Readings


  • Mon 12 November 2018
  • misc

A couple of months ago my friend Bryan sent me a screen shot of the status page on his cablemodem (often available at http://192.168.100.1 depending on the manufacturer and model of your cablemodem) and asked for my thoughts.

Bryans Cablemodem

Here's what I wrote him in reply:

This looks reasonably good. Salient points:

256QAM needs a CNR (which is technically what they're showing you there, not SNR) of 34 dB (or thereabouts) or better. 64QAM only needs 28. Rule of thumb is each bit that you add to your QAM constellation requires 3 dB more. that's true for both j.83 video and cablemodem data - they're exactly the same thing except that the cablemodem channels tend to run a shallower reed-solomon convoluter (because latency) and docsis has a PID of 0x1ffe.

I see your received power levels are around +1 dBmv. 0 dBmv is theoretically ideal. a cablemodem or stb in a clean plant should be good with +10 to -10 dBmv inclusive. in my FiOS here, launch out of the ONT is around +10 to +11 dBmv. I feed that through a combiner (for my locally inserted channels) with 3 dB insertion loss and an 8 way splitter which has about 10.5 dB of loss. Typically (varies by channel) I see rx levels of around -2 dBmv.

The launch levels on your upstream are at the low end of what you want. 38 to 48 dBmv is where you want to be. The CMTS will tell your cablemodem to adjust its power until it is receiving (at the CMTS) at 0 dBmv. That adjustment is made for all cablemodems so when received they're all the same loudness. What varies is the cable plant and amplifier count between the cablemodem and the CMTS in the upstream path. You're probably thinking that +40 is fairly hot, and it is... You want it to be, since you want to be loud compared to any potential ingress in the cable plant (local ham radio operators, etc). But you don't want to be driving more than 51 or 52 dBmv since you'll in all probability be overdriving the first amplifier you run into on the upstream.

You're seeing about 0.03% loss attributable to stuff FEC can't handle, but not 1518 byte ethernet frame loss, it's codeword loss. Modulation profile dependent, but maybe 230 bytes long. Because of the bursty nature of noise, you're likely to have substantially less ethernet packet loss than you have codeword loss since a burst of noise may take out 2-3 codewords in squence that are all part of the same IP packet. More at https://volpefirm.com/docsis-reed-solomon-codewords/