JDS Uniphase SmartClass User Manual page 172

Chapter 18 Maintenance and Troubleshooting
Resolving problems
Resolution
Packet loss (continuity error) problems are typically seen on all channels/programs coming to the
premise because they are not source or content related. If packet loss is present, analysis of the
physical layer at the xDSL interface or Ethernet interface will aid in sectionalization. If no physical
layer errors are present, then packet loss is most likely being caused by the distribution network not
from the access network. Congestion is most likely at issue.
Looking further into the temporal component can help pinpoint the issue. The answers to the
following questions can help find the problem area(s). Are packets being lost during known peak
traffic times during the day? Are they coming in bursts with intervals with no loss? Are they random
single or small packet loss events?
Bursts of loss might be more symptomatic of buffer overflows related to heavy traffic. Random
single or small events might be more related to noise hits on the access network impacting packet
flows. DSL loop performance in the access network may be pushing the bandwidth limits when
signal to noise margins are low and the addition of a second or third channel flow reaches 100%
capacity of the loop. The copper may be poorly balanced allowing high impulse noise to impact the
data flows. In-home wiring may be introducing noise which also can damage data flows.
Issue
I have a PCR jitter result that is higher than expected.
Resolution
PCR jitter problems may be due to content quality problems as outlined previously or overall
network packet jitter. By evaluating more than one channel/program at a time, this can be deter-
mined. If excessive PCR jitter is present at more than one channel, network jitter is most likely at
fault. If excessive PCR jitter is present on only one channel, then a source problem as described
above is normally the cause.
Issue
I am receiving error indicators.
Resolution
Error Indicator counts indicate content problems, since the indicator can only be set by the encoder.
Typically this would affect only one program or channel. However, if a multiple program feed in the
head end is experiencing problems, more than one program/channel could be affected. Analyzing
a channel from another source, or different feed would be instructive. The video may show poor
quality with only the Error Indicator count showing a problem. Any count is bad.
Issue
I have significantly more IGMP latency on one channel than the others.
Resolution
IGMP latency measures the network's performance. Typically, IGMP latency would be similar for
multiple channels. However, if network topology and management place access to certain program
material farther back in the network, then differences could be experienced. If such a hierarchical
approach is used, then differences might be detected based upon which programs are accessible
deeper in the network. Testing multiple channels/programs to exercise this network design would
be useful.
154
SmartClass TPS User's Guide
22035456, Rev 001 June 2014