I'm wondering how much control you folks give the CMTS for spectrum management as well as some "best practices." Do you define any frequency info on the port or only a spectrum group? Port only and not use spectrum groups? In the spectrum group do you define a single frequency (center frequency) or a band? Is the band a single channel width or more? Do you allow multiple channel widths? Modulation Profiles? Cards in question are MC5x20 and MC20x20.
Thanks!
The idea behind a spectrum group is to assign a range like 20 to 42MHz, and then tell every upstream to be a member of this group.
The CMTS will place the upstream somewhere within the spectrum group range. (It will take into account fixed or dynamic channel widths).
Thee CMTS is able to change the upstream frequency on demand in attempt to "hop" away from noise.
Sounds good in theory, however there are some practical downsides to this :
1) Dynamic frequencies will stuff up your reverse sweep channel plans
2) Typically the noise is worse the lower you go, so you are probably better off just to hardcode your frequencies starting from highest possible and work your way down.
With regards to multiple modulation profiles, I reckon this is a good idea. We set ours to 64QAM with fallback to 16QAM. We have graphing of the QAM setting and it is clear how it correctly flips to the lower QAM in the case of bad USSNR.
I agree that the idea of letting the cmts manage the channels sounds good but in the past I have been afraid to use it. I was worried that it was just something else to possibly go bonkers and cause headaches. I have been using the spectrum group feature to assign channels as it keeps that info in one place which is rather nice. The vxr code/hardware combo I have gives an error when assigning a frequency to the port itself and gives an error when assigning a center frequency in the spectrum group. Setting a band equal to channel width at the intended start and stop frequency works. I was just curious what the "recommended" method was with hardware that wasn't quite as ancient.
Graphing the mod profile switch is great. I'm really gonna have to work on my cacti setup with this change. I've seen quite a few nice graphing examples here that I need to get to work on.
I would also like to thank you for your help with my questions as well as all the examples/explanations you've posted here in the past (especially the MC20x20v) stuff. That has been a great help. The general implementation/configuration of the 20x20 is a pretty big change from what I'm familiar with and your posts have cleared up a lot of what is going on there. So... Thanks, a lot!
That is great that I have been able to help you. Nice to hear feedback like that :-)
I don't know why you are having problems hardcoding US freqs, this is a pretty basic function of the CMTS.
Can you post some sample config, and the error message you are receiving ?
---
Hardcoded way should just be like this :
interface cable 5/0/0
cable upstream 0 frequency 38700000
cable upstream 1 frequency 31200000
cable upstream 2 frequency 38700000
cable upstream 3 frequency 31200000
---
Or spectrum group way would be like this :
cable spectrum-group 1 band 20000000 42000000
interface cable 5/0/0
cable spectrum-group 1
---
You can mix the two, by going to any of the individual upstream interfaces and setting the frequency (even when the spectrum group config is also present). The hardcoded value will win, and the spectrum group will take the hardcoded channel into consideration for placing the dynamic frequency channels.
My memory wasn't quite accurate. It had been a while ago. The card takes a frequency just fine. If you define a set frequency in the spectrum group it doesn't like that.
For example:
cable spectrum-group 1 frequency 33000000
and then
int cable5/0/3
cable upstream 0 spectrum-group 1
you get
%Warning: spectrum group 6 with discrete frequency configuration is not fully supported on interface Cable5/0/3 U0
The card appears to take the config just fine and comes up, I just didn't like the stern warning! I realize this isn't the intention of the spectrum-group feature, I was just using it as a handy way to assign frequencies to the ports. On the vxr I just assigned a band equal to channel width instead of center frequency which works fine. No big deal, just a quirk I had encountered in the past and noticed it was still there.