Specifications

Chapter 4 Diagnostics and Troubleshooting IPmux-11 Installation and Operation Manual
4-14 Performance Monitoring Statistics
Table 4-4. Bundle Connection Parameters (Cont.)
Parameter Description
Jitter Buffer
Underflows
(cont.)
An underflow situation can be a cause of:
• Buffer starvation: Packets delay variation causes the buffer to empty out gradually until it is
underflowed.
• Continuous Sequence Errors. The sequence error means a halt in the valid stream of packet arrival
into the jitter buffer.
• Packets are being stopped/lost/dropped.
• Too small jitter buffer configuration that can’t compensate for the network delay variation.
• When all system elements are not locked on the same master clock, it will lead to a situation in
which data is clocked out of the jitter buffer at a rate different from the one it is clocked into. This
will gradually result in either an overflow or underflow event, depending on which rate is higher.
The event will repeat itself periodically as long as the system clock is not locked.
• When an overflow (see below) situation occurs, IPmux-11 instantly flashes the jitter buffer, causing a
forced underflow. So when you need to calculate the real underflow events and not the self-initiated
ones, subtract the number of overflows from the total number of underflows counted by the device.
Recommendations:
• Try increasing the jitter buffer size.
• Check reasons for sequence errors or lost/dropped packets (if present), system clocking
configuration, Ethernet environment (full duplex) and connection, packets drop/loss/ignore by
routers/switches or non-uniform packets output by routers/switches due to queuing mechanisms.
• Make sure the same amount of TS for bundle is configured on each side of the IPmux-11
application, and that the “TDM bytes in frame” parameter is identical in both IPmux-11 units.
• Make sure Ethernet/IP network provides priority (Quality Of Service) to the IPmux-11 traffic. Priority
may be achieved by three means: VLAN tagging, IP TOS marking or by using the constant 2142
decimal value at each IPmux “UDP destination Port” field.
Jitter Buffer
Overflows
The number of times an overflow situation took place.
Explanation:
In steady state, the jitter buffer is filled up to its middle point, which means it has the space to hold an
additional similar quantity of packets. Overflow is opposite phenomenon of the Underflow, i.e., when
a big burst of packets reaches the IPmux (a burst with more packets than the Jitter Buffer can store), the
buffer will be filled up to its top. In this case, an unknown number of excessive packets are dropped
and hence IPmux initiates a forced underflow by flashing (emptying) the buffer in order to start fresh
from the beginning. An overflow situation always results in an immediate Underflow, forced by the
IPmux. After the buffer is flashed, the process of filling up the buffer is started again, as explained above
(“Underflow” section).
An overflow situation can be a cause of:
• A big burst of packets, filling up the buffer completely. The burst itself can often be a cause of some
element along the IP network queuing the packets and then transmitting them all at once.
• Too small jitter buffer configuration.
• When system isn’t locked on the same clock, it will lead to a situation in which data is clocked out
of the jitter buffer at a rate different from the one it is clocked into. This will gradually result in either
an overflow or underflow event, depending on which rate is higher. The event will repeat itself
periodically as long as the system clock is not locked.