Performance guide

How to enable the UDP based QUIC transport protocol in DCV

NICE DCV uses the WebSocket protocol, which is based on TCP, by default. As alternative you can run NICE DCV under QUIC protocol, which is based in UDP (WebSocket/TCP will still be used for authentication, to avoid security issues). If your network experiences high latency and packet loss, using QUIC might improve performance

Linux

On Linux QUIC can be enabled in dcv.conf in the connectivity section:

[connectivity]
enable-quic-frontend=true

After starting the DCV client (beginning with version 2020.2, the web browser client does not support UDP) you click on “Connection Settings” and in the “Advanced” tab you can choose QUIC transport:

Please note to enable the UDP traffic (UDP 8443 and TCP 8443 by default) to pass through the firewall or cloud security group in case.

To verify QUIC is used you can navigate in the DCV client to Settings (upper left) -> Streaming Mode and the popup should show (DCV 2020.1):

To test the difference of the DCV streaming modes you can switch easily between the TCP and QUIC/UDP mode in the settings of the client before connecting to the DCV session.

This NI SP demo video shows the difference in remote experience using TCP versus QUIC/UDP for higher latencies of ca. 100 msec: https://youtu.be/FDQumi0lPvA?t=282. Above ca. 50 – 70 msec latency we suggest to test how QUIC/UDP works for your use case.

For more background on QUIC from the NICE dev team head over to our news article How NICE DCV achieves 4K 60 fps high-quality interactive streaming with two videos from the DCV development team.

In case you want to enable QUIC Streams instead of the default QUIC Datagrams (more info: Background on QUIC Streams and QUIC Datagrams) you can use the following approach:

Starting with DCV 2023.1 you can add the following configuration in the [connectivity] section of your DCV configuration file for Linux DCV Servers. Please restart dcvserver after the change has been made.

[connectivity]
enable-datagrams-display = always-off

You can also configure QUIC Streams instead of QUIC Datagrams by starting the DCV client with the following option (Linux or MacOS):
./dcvviewer --dqt-alpn-versions="Dcv20Basic"

Windows

To enable the high-FPS QUIC/UDP protocol offering by default 60 FPS e.g. on Windows DCV servers (starting with DCV version 2020.2) you can enable QUIC in the registry.

On the DCV server side you can use the Registry Editor to configure the key HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/connectivity/enable-quic-frontend as 32-bit DWORD with the value 1:

Or using PowerShell:

New-ItemProperty -Path “Microsoft.PowerShell.Core\Registry::\HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\connectivity” -Name enable-quic-frontend -PropertyType DWORD -Value 1 -Force

After starting the DCV client (beginning with version 2020.2, the web browser client does not support UDP) you click on “Connection Settings” and in the “Advanced” tab you can choose QUIC transport:

Please note to enable the UDP traffic (UDP 8443 and TCP 8443 by default) to pass through the firewall or cloud security group in case.

To verify QUIC is used you can navigate in the DCV client to Settings (upper left) -> Streaming Mode and the popup should show (DCV 2020.1):

To test the difference of the DCV streaming modes you can switch easily between the TCP and QUIC/UDP mode in the settings of the client before connecting to the DCV session.

This NI SP demo video shows the difference in remote experience using TCP versus QUIC/UDP for higher latencies of ca. 100 msec: https://youtu.be/FDQumi0lPvA?t=282. Above ca. 50 – 70 msec latency we suggest to test how QUIC/UDP works for your use case.

For more background on QUIC from the NICE dev team head over to our news article How NICE DCV achieves 4K 60 fps high-quality interactive streaming with two videos from the DCV development team.

In case you want to enable QUIC Streams instead of the default QUIC Datagrams (more info: Background on QUIC Streams and QUIC Datagrams) you can use the following approach:

Starting with DCV 2023.1 you can add the following configuration in the [connectivity] section of your DCV configuration file for Linux DCV Servers. Please restart dcvserver after the change has been made.

An in case of Windows DCV Servers the PowerShell setting:

New-ItemProperty -Path "Microsoft.PowerShell.Core\Registry::\HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\connectivity" -Name enable-datagrams-display -PropertyType STRING -Value "always-off" -Force

New-ItemProperty -Path "Microsoft.PowerShell.Core\Registry::\HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\connectivity" -Name enable-datagrams-display -Value always-off -force

You can also configure QUIC Streams instead of QUIC Datagrams by starting the DCV client with the following option:

On Windows:
dcvviewer.exe --enabled-quic-alpn-versions="Dcv20Basic"

Analyze GPU consumption with nVidia SMI and Process Explorer

Windows

You can find out how much GPU memory your applications are using with the nVidia tool nvidia-smi (/usr/bin/nvidia-smi) on Linux or C:\'Program Files'\'NVIDIA Corporation'\NVSMI\nvidia-smi.exe on Windows. With the option -a nvidia-smi will show full GPU details.

nvidia-smi on Linux with 10 Mio nodes LS-Dyna model loaded in LS-PrePost

Monitoring the GPU status with nvidia-smi is available with the dmon option, e.g.
nvidia-smi dmon -s puctm , which will allow to log values with respective options including utilization and PCIe bus throughput:

  • p – Power Usage and Temperature
  • u – Utilization
  • c – Proc and Mem Clocks
  • v – Power and Thermal Violations
  • m – FB and Bar1 Memory
  • e – ECC Errors and PCIe Replay errors
  • t – PCIe Rx and Tx Throughput

and produce output similar to this which can be logged into a file as well:

Another very helpful tool to understand GPU usage on Windows is Process Explorer (Microsoft Process Explorer). Here a sample output with GPU consumption by Blender:

Optimize nVidia GPU performance

Linux

For optimal performance of nVidia GPUs the clock settings are important. You can set specific clock rates depending on the application or configure Auto Boost to adapt the clock rates to the best values depending on application needs and the thermal situation.

You can query the present clock settings with nvidia-smi -q -i 0 -d CLOCK which will produce an output similar to this:

> nvidia-smi -q -i 0 -d CLOCK
==============NVSMI LOG==============
 
Driver Version                            : 450.89
CUDA Version                              : 11.0
Attached GPUs                             : 1
GPU 00000000:00:1E.0
    Clocks
        Graphics                          : 405 MHz
        SM                                : 405 MHz
        Memory                            : 324 MHz
        Video                             : 405 MHz
    Applications Clocks
        Graphics                          : 1177 MHz
        Memory                            : 2505 MHz
    Default Applications Clocks
        Graphics                          : 557 MHz
        Memory                            : 2505 MHz
    Max Clocks
        Graphics                          : 1177 MHz
        SM                                : 1177 MHz
        Memory                            : 2505 MHz
        Video                             : 1083 MHz
    Max Customer Boost Clocks
        Graphics                          : N/A
    SM Clock Samples
        Duration                          : 386.49 sec
        Number of Samples                 : 29
        Max                               : 1177 MHz
        Min                               : 405 MHz
        Avg                               : 548 MHz
    Memory Clock Samples
        Duration                          : 386.49 sec
        Number of Samples                 : 29
        Max                               : 2505 MHz
        Min                               : 324 MHz
        Avg                               : 2157 MHz
    Clock Policy
        Auto Boost                        : Off
        Auto Boost Default                : Off

At the end of the output we can see that Auto Boost is set to “off” or “N/A” depending on the GPU. We can change this to “on” with the following command: sudo nvidia-smi --auto-boost-default=ENABLED -i 0. In case we want to set clocks to specific values we can do this with the following commands – first we make sure persistence mode is enabled and then we set Auto Boost or memory and SM clocks:

> sudo nvidia-smi -pm ENABLED -i 0
Enabled persistence mode for GPU 00000000:00:1E.0.
> # sudo nvidia-persistenced   # alternatively 
> sudo nvidia-smi --auto-boost-default=ENABLED -i 0
All done.
# alternatively check for available clocks and set respectively
> nvidia-smi  -q -i 0 -d SUPPORTED_CLOCKS
........ Output ...... 
> sudo nvidia-smi --applications-clocks=2505,1177   # M60, depending on available clocks
Applications clocks set to "(MEM 2505, SM 1177)" for GPU 00000000:00:1E.0
> sudo nvidia-smi -ac 5001,1590                     # T4 
Applications clocks set to "(MEM 5001, SM 1590)" for GPU 00000000:00:1E.0

Adapt the DCV image quality for best user experience

Background

Please note: most of the settings below apply to DCV TCP based connections. DCV QUIC/UDP offers great interactivity so please consider trying QUIC/UDP for your use cases as well: Configuration of QUIC/UDP for DCV Remote Desktops.

The format is (minimum_quality,maximum_quality).  So in this case it would lower the maximum H264 quality from it’s default value of 80 to 70. You can also raise the lower boundary from 30 to a higher value which will result in a higher bandwidth consumption while providing better image quality in the H264 stream. This setting and the ones highlighted below typically work on TCP based connections.

Further optimization in case you are working in a high bandwidth environment and want to increase image quality testing effects in the following order on the DCV server (you need to reconnect to the session or restart the DCV server to pick up the settings):

  • display/quality
    Increase the H264 stream quality by setting display/quality to e.g. (60, 80) or (80, 90). This will lead to an increase in bandwidth consumption so you can try (90,95) as well which will result in the highest quality and bandwidth consumption. Setting 100 will enforce lossless and significantly higher bandwidth. Or you can lower the quality boundaries in a low bandwidth environment. In the case of QUIC/UDP the protocol uses the available bandwidth and sets bitrate to quality fitting related to bandwidth. The TCP protocol estimates quality then sets the bandwidth (opposite of QUIC)
    Windows: New-ItemProperty -Path "Microsoft.PowerShell.Core\Registry::\HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\display" -Name quality -PropertyType STRING -Value "(80,90)" -Force
  • display/enable-qu (enable quality update)
    Enabled by default (true). Quality updates to be send after the screen becomes steady. Sends pixel-perfect copy of the remote screen. Disabling can be useful for certain workloads in case lossless is not needed. An example of when useful is e.g. remote gaming (screen is refreshing too fast for lossless to happen anyway).
    Windows: New-ItemProperty -Path "Microsoft.PowerShell.Core\Registry::\HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\display" -Name enable-qu -PropertyType DWORD -Value 0 -Force
  • display/qu-bandwidth (quality update bandwidth)
    Configure to use more bandwidth for the quality update by setting display/qu-bandwidth to 10 (or 20). This will allow lossless to happen faster, the default being 2. Only active when quality updates are enabled
  • display/frame-queue-weights
    Tweak queue weights for low latency and high bandwidth by setting display/frame-queue-weights to (8,5,1) (default: (5,3,1)). This is related to increase the number of active frames (DCV will send more frames before waiting for an ACK from the client). This applies to the TCP protocol. Related to this is
  • display/frames-in-transit
    Control the min-max frames in transit, default is (2, 4). E.g. set display/frames-in-transit to (2, 8). This applies to the TCP protocol
  • display/target-fps
    Adapt the frame limiter by setting display/target-fps to 60 or even disable it by setting it to 0
  • display/use-grabber-dirty-region
    Set display/use-grabber-dirty-region to false (Specifies whether to use dirty screen regions. If enabled, the grabber tries to compute new frames out of the changed regions from the screen which is helpful in case of some desktop manager like XFCE)

More settings related to the DCV display configuration and other paramters can be found here: https://docs.aws.amazon.com/dcv/latest/adminguide/config-param-ref.html#display

Please note the Reload context column in each table indicates when the parameter is reloaded. Possible contexts include:

  • server – The parameter is loaded once when the server is started. If the parameter value is updated, the new value is loaded when the server is restarted.
  • session – The parameter is loaded when the session is created. If the parameter value is updated, the new value is loaded for subsequent sessions.
  • connection – The parameter is loaded when a new client connection is established. If the parameter value is updated, the new value is used for subsequent client connections.
  • custom – The conditions under which the parameter loads is unique to this parameter. See the parameter description for more information.

Linux

For fine-grained control, you can tune the 0-100 quality setting on the server side by modifying the /etc/dcv/dcv.conf file and adding a line to the display section:

[display]
quality=(70,90)

The format is (minimum_quality,maximum_quality).  So in this case it would lower the maximum H264 quality from it’s default value of 80 to 70. You can also raise the lower boundary from 30 to a higher value which will result in a higher bandwidth consumption while providing better image quality in the H264 stream. This setting and the ones highlighted below typically work on TCP based connections.

Windows

On Windows it would be the respective parameter in HKEY_USERS​\​S-1-5-18​\​Software​\​GSettings​\​com​\​nicesoftware​\​dcv​\display\quality were we can create a string entry with “(60,90)” in case we want to always have a higher quality in the H264 stream with a higher bandwidth consumption.

When a larger portion of the screen content changes DCV will use a H264 stream to display the changing content. When the image is steady a pixel-perfect quality update will be send with the exact copy of the server side image on the GPU. To disable the quality update we can set HKEY_USERS​\​S-1-5-18​\​Software​\​GSettings​\​com​\​nicesoftware​\​dcv​\display\enable-qu to 0 on Windows (false on Linux).

Limiting the bandwidth usage

Linux

  1. Edit the file
    /etc/dcv/dcv.conf
  2. Look for the [connectivity] section
  3. Set, or add if is not there, the value needed. In this example 20000 means 20mbps.
    max-target-bitrate=20000

Windows

  1. Open the registry key
    HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/connectivity/
  2. Create a new QWORD: max-target-bitrate
  3. Set 20000 if you want 20mbps max bandwidth usage, for example

Slow devices with QUIC / UDP transport protocol

If you have some device being slow, this can help you. Some Wacom Tablet devices can have problems with QUIC / UDP transport protocol.

The parameter that we will show below will instruct the server to use QUIC streams instead of QUIC datagram, which can help connections with high data packet loss problems.

You can also limit the max bandwidth usage, which can also help improve the user experience.

Linux DCV client

Try to open the client with this parameter:

./dcvviewer --dqt-alpn-versions="Dcv20Basic"

Linux DCV server

Edit the /etc/dcv/dcv.conf file and set:

[display]
quality=(90,95)
​# here you can try 100 as well but this will be lossless so more bandwidth 
# to tune quic in the connectivity section: 
[connectivity]
enable-datagrams-display = always-off
# set the quic target bitrate to 20Mbit/sec 
max-target-bitrate=20000

You can also try to use specific display encorders under [display] section.

Please test the first option before try the second option. Use the one that actually improve your user experience.

Option 1:

display-encoders=['turbojpeg', 'lz4']

Option 2:

display-encoders=['lz4']

Windows DCV client

Try to open the client with this parameter:

dcvviewer.exe  --enabled-quic-alpn-versions="Dcv20Basic"

Large resolutions: 5120×1440, 2x 2560×1600 or 2x 3840×2160

Here are some parameters where you can use to start tweak the values to improve the user experience:

[session-management]
enable-gl-in-virtual-sessions = "default-off"

[display]
max-head-resolution = "(7680, 2160)"
qu-bandwidth=20
quality=(20,90)
frame-queue-weights=(8,5,1)
frames-in-transit=(2,8)

[connectivity]
web-port=8443
enable-quic-frontend=true
quic-port=8443
idle-timeout=0

[input]
enable-autorepeat=false
mouse-wheel-sensitivity=0