Hi,
kind of silly questions, but I want to understand what is being used around your plants:
1) What is the parameter you use to consider a service group (downstream or upstream) saturated?
2) Do you measure it by peaks or average?
3) Are your node splits related to this metric?
If you answer to question 3 is "yes", how long it takes from the moment the trigger is fired to the actual physical node split?
Just sharing ours, we trigger a node split every time a service group reaches 6 peaks of 80% (for downstream or upstream) in a mont ( of course we use all possible downstream and upstream channels on our service groups). Here it takes around 6 months between the trigger is fired to the split of the node.
Thanks in advance for your thoughts.
regars,
MS
Here's how we do it :
---
Graph every US channel in MRTG
Each day, scroll through the daily (5min interval) graphs.
Beware when you see 5min interval spikes hitting 100%, even if only for a short period.
(On the same page we are also graphing stuff like SNR, FEC, width, QAM, so you can review all this stuff in one place just by quickly scrolling)
If concerned about any particular channels, have a look at the yearly graphs.
If blue (average) line going above 50%, it means upgrade is needed.
In this case the pink (peak) line will generally be showing a flattening at 100%.
You do not want the utilisation to hit 100, because queues will start to form inside the modems, and latency for all modems in that node will blow out.
People surfing the net may not notice, but interactive apps like gaming / citrix / RDP will see the problem straight away.
On the US channels, the CMTS allocates timeslots to the various modems with aim of fairly granting bandwidth.
However the CMTS isn't in complete control here, the modems are responsible for some aspects.
For example the queuing happens inside the modems, and the CMTS doesn't have much control over the queue depth.
This can sometimes result in latency jumping very high eg 500ms+.
If there is heavy congestion you can run low on contention intervals meaning bandwidth request collisions etc.
The scheduler will lose control. QoS wont work. Things go downhill very rapidly.
When US utilisation is high, it will also affect DS performance.
TCP ACK packets gets delayed or lost.
So really need to keep a close eye on it, otherwise you will end up with some very unhappy customers.
---
Graph every DS channel in MRTG
We graph the per-channel MPEG counters from (Cisco) CMTS, as this gives you the channel view.
(Rather than the narrowband / wideband etc counters which (with DOCSIS 3.0) aren't showing you the per-channel utilisation)
Review the daily graphs periodically (we dont bother doing it every day).
If seeing spikes to 100%, flip over to the yearly view to see the longer term trend.
If blue (average) line is going above 50, time to upgrade.
Pink (peak) line will also be flattening at 100%.
Congestion in the DS isn't as "bad news" as congestion in the US.
For the DS, the CMTS is in complete control of all the traffic.
CMTS handles all the timeslots, so can fairly distribute the bandwidth to the users.
DOCSIS priority 0-7 will work well, with the different priorities getting their appropriate share of traffic.
So business customers (eg prio2) can win over residential customers (eg prio1) etc.
CMTS handles all the queuing, it will tail drop traffic that has exceeded the target max queue depth, eg 40ms
So latency will not blow out, instead excessive dataflows will backoff / slow down.
---
We use Cisco Subscriber Traffic Management to control users who are doing excessive data transfer
Typically we will demote the QoS (to prio0) for heavy DS traffic
And we will impose a stricter max-rate for heavy US traffic
---
Note:
If you have a lot of CMTS or channels, dont use MRTG. The overhead is high because every png is recreated every 5 mins.
Better off to use cacti instead, where PNG is created at time of viewing.
We use observium, it's basically mrtg but it is easier to audit an entire cmts and will automatically graph all interfaces. I use cacti for SNR reporting and modem stats, and homegrown php/snmp for individual modems and modem usage. With a cgi script to parse cmts service flows.