Topic Last Modified: 2011-04-12
The Service Performance Report lists the servers that have experienced the most problems, based on measurements of such key quality metrics as degradation, packet loss, and jitter.
Filters
Filters provide a way for you to return a more finely-targeted set of data or to view the returned data in different ways. For example, the Server Performance Report enables you to do such things as filter the returned data by server type or by network type (that is, wired or wireless). You can also choose how data should be grouped. In this case, data is grouped by hour, day, week, or month.
The following table lists the filters that you can use with the Server Performance Report.
Server Performance Report Filters
| Name | Description |
|---|---|
|
From |
Start date/time for the time range. To view data by hours, enter both the start date and time as follows: 1/1/2011 1:00 PM If you do not enter a start time, the report automatically begins at 12:00 AM on the specified day. To view data by day, enter just the date: 1/1/2011 To view by week or by month, enter a date that falls anywhere within the week or month that you want to view (you do not have to enter the first day of the week or month): 1/3/2011 Weeks always run from Sunday through Saturday. |
|
To |
End date/time for the time range. To view data by hours, enter both the end date and time as follows: 1/1/2011 1:00 PM If you do not enter an end time, the report automatically ends at 12:00 AM on the specified day. To view data by day, enter just the date: 1/1/2011 To view by week or by month, enter a date that falls anywhere within the week or month that you want to view (you do not have to enter the first day of the week or month): 1/3/2011 Weeks always run from Sunday through Saturday. |
|
Server type |
Indicates the type of server whose performance should be reported. Select one of the following:
|
|
Top N |
Indicates the number of servers (based on their poor call percentage) to be displayed in each category. For example, if you select 5 then the five poorest-performing servers are displayed. Select one of the following:
|
|
Activity type |
Indicates whether the client was logged on to the internal network or the external network when the call was placed. Select one of the following:
|
|
Network type |
Indicates the type of network the client was connected to when the call was placed. Select one of the following:
|
|
VPN |
Indicates whether an external client was using a virtual private network (VPN) connection when the call was placed. Select one of the following:
|
Metrics
The following table lists the information provided in the Server Performance Report.
Server Performance Report Metrics
| Name | Can Sort On | Description |
|---|---|---|
|
Server |
No |
Name/IP address of the server. |
|
Call volume |
No |
Total number of calls made. |
|
Poor call percentage |
No |
Total number of calls classified as poor. A poor call is any call which at least one of the measured metrics exceeded the allowed value (for example, a call that experienced excessive jitter). |
|
Round trip (MS) |
Yes |
Average amount of (in milliseconds) required for a real-time transport protocol (RTP) packet to travel to another endpoint and then back. Round-trip times of 100 milliseconds or less are considered of acceptable quality. High round-trip values can be caused by international call routing; a routing misconfiguration; or an overloaded media server. High round-trip times result in difficulties with two-way, real-time audio conversations. |
|
Degradation (MOS) |
Yes |
Average amount of mean opinion score (MOS) degradation experienced during a call. Degradation values can range from a low of 0.0 to a high of 5.0. A value of 0.5 or less represents acceptable degradation. Historically, mean options scores were calculated by having users rate the quality of a call on a scale of 1-to-5. In Microsoft Lync Server 2010, the Monitoring Server uses a set of algorithms to predict how users would have rated a call. High degradation values can be caused by congestion, lack of bandwidth, wireless congestion or interference, or an overloaded media server or endpoint. High degradation results in distorted or lost audio. |
|
Packet loss |
Yes |
Average rate of real-time transport protocol (RTP) packet loss. (Packet loss occurs when RTP packets, a protocol used for transmitting audio and video across the Internet, failed to reach their destination.) High loss rates are generally caused by congestion, lack of bandwidth, wireless congestion or interference, or an overloaded media server. Packet loss typically results in distorted or lost audio. |
|
Jitter |
Yes |
Average jitter detected between RTP packet arrivals. (Jitter is a measure of the "shakiness" of a call.) High jitter values are typically caused by congestion or an overloaded media server, and result in distorted or lost audio. |
|
Healer concealed ratio |
Yes |
Average ratio of concealed audio samples to the total to the total number of samples. (A concealed audio sample is a technique used to smooth out the abrupt transition that would usually be caused by dropped network packets.) High values indicate significant levels of loss concealment applied caused by packet loss or jitter, and results in distorted or lost audio. |
|
Healer stretched ratio |
Yes |
Average ratio of stretched audio samples to the total to the total number of samples. (Stretched audio is audio that has been expanded to help maintain call quality when a dropped network packet has been detected.) High values indicate significant levels of sample stretching caused by jitter, and result in audio sounding robotic or distorted. |
|
Healer compressed ratio |
Yes |
Average ratio of compressed audio samples to the total number of samples. (Compressed audio is audio that has been compressed to help maintain call quality when a dropped network packet has been detected.) High values indicate significant levels of sample compression caused by jitter, and result in audio sounding accelerated or distorted. |
|
Trend |
No |
Graphs server performance over time. |