Client Performance Health Check - Diagnostics and troubleshooting guide

Rate this Article

September 28, 2021

Last modified: 11/15/2024, 7:09 am

Knowledge Base Article Diagnostics Performance HP Anyware

Summary

To receive a detailed client diagnostic report, create a client support/log file bundle and then submit this bundle to the PCoIP health check tool. Once the files are submitted, it will take 5-10 minutes to produce a detailed report. The report will be sent to your registered e-mail address.

Client health checks are available for Zero Clients, Windows/Mac and Linux software Clients.

Diagnostics

Phase

Diagnostic

Session

Packet Loss
Latency
Jitter
Buffer Overflow

Shows:

if the network is experiencing packet loss
if the network is experience latency (delay)
if the network is experience jitter (variability)
if the client is experience buffer overflow

Diagnostics Details

Packet Loss

Reports if packet loss was seen during a PCoIP session. The diagnostic returns:

Pass:	Packet loss never exceed 0.2% during the 60 second session
Warning:	Packet loss exceeded 0.2% during 60 second period

Data Collected:

Every 60 seconds, packet loss stats are reported by the agent.

No Traffic detected |
Traffic Healthy (Loss=0.00%/0.00%) |
Traffic Unhealthy (Loss= >0.2%/0.2%)

Corrective Actions (if diagnostic does not pass)

Root Cause

Remedy

Packet Loss can cause:

Black Screens
Display Artifacts
Poor Performance
Poor audio

Recommended next steps include:

Use PCoIP Session Statics Viewer tool to drill into the network and tx/rx performance during the session. This tool will provide graphs that give an accurate pictures of network usage during the time period.
Once the data, is obtained, the network issues should be addressed by following the guidance in these articles:
- Troubleshooting PCoIP packet loss on the LAN and WAN networks?
- Troubleshooting PCoIP Display Issues
- If GPU model have a dithering feature enabled, then make sure it is disabled to fix distorted image and higher frame utilization.

Implementation Details:

Category:

This diagnostic is checked every 60 seconds during an active session.

Implementation Steps:

Step 1: Find all Packet Loss Report associated with the session ID. See log pattern (a)
Step 2: In the notes area for each packet loss report, indicate if it is no traffic (0 transmitted packets), healthy (transmitted and loss rate below .02%) or unhealthy (transmitted and loss rate above .02%)
Timeout: Not Applicable.

Time Period:

The diagnostic starts time with the first Packet Loss Report associated with the session.
The diagnostic end time is the last Packet Loss Report associated with the session.

Example (a) Logs: Packet loss statistics

LVL:1 RC: 0 VGMAC :Stat frms: R=000000/000000/296923 T=022209/380982/107934 (A/I/O) Loss=0.00%/0.00% (R/T)

Latency

Reports the Latency seen during a PCoIP session. The diagnostic returns:

Pass:	Latency never exceed 100 ms during the indicated time period
Warning:	Latency exceeded 100 ms but is less than 250 ms for the indicated time period.
Fail:	Latency exceeded 250 ms for the indicated time period

Data Collected:

Every 60 seconds, Latency stats are reported by the agent.

Latency < 100ms (x ms) | Latency < 250 ms (x ms) | Latency > 250 ms (x ms)

Corrective Actions (if diagnostic does not pass)

Root Cause

Remedy

High latency can cause:

mouse/tablets sluggishness
audio pops and cracks

Recommended next steps include:

Use PCoIP Session Statics Viewer tool to drill into the network and tx/rx performance during the session. This tool will provide graphs that give an accurate pictures of network usage during the time period.
Once the data, is obtained, the network issues should be addressed by following the guidance in these articles:
- What are the latency requirements for PCoIP?
- How much latency does PCoIP technology add to the remote system?

Implementation Details:

Category:

This diagnostic is checked every 60 seconds during an active session..

Implementation Steps:

Step 1: Find all Latency reports associated with the session ID. See log pattern (a)
Step 2: Report X (# of Latency sessions > 100 ms)
Step 3: Report Y (# of Latency sessions > 250 ms).
Step 4: Report Z (# of Latency sessions found)
Timeout: Not Applicable.

Time Period:

The diagnostic starts time with the first Latency report associated with the session.
The diagnostic end time is the last Latency Report associated with the session.

Example (a): Latency information is published in the logs every 60 seconds and the statistics apply to the last 60 seconds.

LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 1, variance = 0, rto = 101, last = 2, max = 10

Jitter

Reports the Jitter seen during a PCoIP session. The diagnostic returns:

Pass:	Jitter never exceeded 30 ms for the time period
Warning:	Jitter exceeded 30 ms for at least one 60 second period during the session
Fail:	Jitter exceeded 100 ms for at least one 60 second period during the session

Data Collected:

Every 60 seconds, Jitter stats are reported by the agent.

X periods with Jitter > 30 ms. Y periods with Jitter > 100 ms. Z periods reported.

Corrective Actions (if diagnostic does not pass)

Root Cause

Remedy

High Jitter can cause:

Poor Performance
audio pops and cracks

Recommended next steps include:

Use PCoIP Session Statics Viewer tool to drill into the jitter seen during session. This tool will provide graphs that give an accurate pictures of network usage during the time period.
Once the data, is obtained, the network issues should be addressed by following the guidance in these articles:
- What are the latency/jitter requirements for PCoIP?
- How much latency/jitter does PCoIP technology add to the remote system?

Implementation Details:

Category:

This diagnostic is checked every 60 seconds during an active session.

Implementation Steps:

Step 1: Find all Jitter reports associated with the session. See log pattern (a)
Step 2: Report X (# of Jitter sessions > 30 ms)
Step 3: Report Y (# of Jitter sessions > 100 ms)
Step 3: Report Z (# of Jitter sessions found)
Timeout: Not Applicable.

Time Period:

The diagnostic starts time with the first Jitter report associated with the session.
The diagnostic end time is the last Jitter Report associated with the session.

Example (a): Jitter information is published in the logs every 60 seconds and the statistics apply to the last 60 seconds.

LVL:2 RC: 0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 1, variance = 0, rto = 101, last = 2, max = 10

Client Buffer Overflow

Reports if hosts buffers overflow events are seen during a session. This diagnostic is only reported if buffer overflow are seen and therefore if it is report, it is always reported as a fail.

Fail:

A buffer overflow event was reported on the host

Data Collected:

Z represents how many buffer overflow events were reported during the session.

Z buffer overflow events reported.

Corrective Actions (if diagnostic does not pass)

Root Cause

Remedy

Buffer Overflow cause:

Poor performance
distorted image quality,
black or tearing screens

If buffers are overflowing on the host, dithering may be the cause. Make sure the graphics cards on both the client and host have temporary dithering disabled. For additional guidance, refer to The impact of graphics card temporal dithering

Implementation Details:

Category:

This diagnostic during an active session

Implementation Steps:

Step 1: Find all Buffer Overflow events. See log pattern (a) or (b)
Step 2: Report Z (# of buffer overflow events found)
Timeout: Not Applicable.

Time Period:

The diagnostic starts time with the first buffer overflow event found associated with the session.
The diagnostic end time is the last buffer overflow event found associated with the session.

Example (a): Zero client logs showing overrun:

LVL:0   RC: -500 MGMT_IMG :(pkt_rx_resource_check): Insufficient imaging resources. Dropping imaging data

Example (b): Software client logs showing overrun:

LVL:2 RC:   0    IMAGE_UPDATE :cSW_CLIENT_IPC: Frame rate is 14.850992Hz
LVL:2 RC:   0        MGMT_IMG :loss: from seq_id 0x4a to 0x4f (5 slices)