Quote:
Originally Posted by daveybm
…..
PS I've also noticed I'm now on a different US channel number (was 58 is now 59)
Dave
|
The channel ID number could vary (by area and/or CMTS) depending on frequency/channel plan and ID convention used across linecards so in user context it's perhaps less ambiguous to also include actual frequency. Level2 having access to what node/cable segment your Hub is attached to will invariably use a different naming convention related to how the stats are reported.
For example on my CMTS I may be attached to linecard 1 and the channel ID numbering may start sequentially at 1 thru the whole chassis.
I may be connected to any 1(or 2 combinations as my connection has upstream bundling enabled) of 3 discrete channels available on my node such that:
Channel ID 1 = 45.8MHz and US0 (Level2 reference)
Channel ID 2 = 38.5MHz and US1
Channel ID 3 = 27.4MHz and US2
Just to muddy the waters further US0/1/2 can obviously alter against displayed headers(US-1,US-2 etc) in webpage of upstream tab in SHub stats as well!
Hence you probably want to take a screen shot of upstream to avoid any ambiguity caused by terminology and subsequent confusion and post that with results of TBB graph.
In your scenario Ch59 is 27.4MHz so previous Ch58 was probably 35.8MHz?
However what we're now interested in seeing is if there's any change in packet loss relevant to upstream channel that is actually locked.
The upstream channel may (but not always) change when rebooting the SHub as CMTS static load balancing attempts to evenly spread CM/SH's that are registering across the available upstreams (that may occur due to utilisation load or noise). Upstream channel can also change due to dynamic load balancing as well.