TigerVNC performance with AIR application

[Richard Mixon]

We have an AIR application (uses the Harman AIR SDK) that is struggling under Tiger VNC.

When we run the application locally (i.e. output just to an HDMI display) we see 12.0 frames per second.

When we run through TigerVNC server and noVNC we are seeing between 6.5 and 8.8 frames per second.

When we run through TigerVNC server and the TigerVNC client we are seeing between 6.4 and 8.2 frames per second (we did this test to make sure noVNC was not the performance culprit).

Any ideas on how to improve the performance over TigerVNC server? We''ve looked at things via top and using "perf stats" but don't see any glaring issues other than the extra memory usage we'd expect to see with TigerVNC server running.

Thank you much - Richard

[Andrew C Aitchison]

On Mon, 22 Apr 2024, Richard Mixon wrote:

> We have an AIR application (uses the Harman AIR SDK) that is struggling
> under Tiger VNC.
>
> When we run the application locally (i.e. output just to an HDMI display)
> we see 12.0 frames per second.
>
> When we run through TigerVNC server and noVNC we are seeing between 6.5 and
> 8.8 frames per second.
>
> When we run through TigerVNC server and the TigerVNC client we are seeing
> between 6.4 and 8.2 frames per second (we did this test to make sure noVNC
> was not the performance culprit).

What sort of network connects the client and server ?
Even if they are on the same machine you have added a TCP/IP stack.

Is the network connection "full"; are any of the CPUs running near 100% ?

Does the AIR SDK make significant use of the GPU -
I am not sure that TigerVNC is able to offload much to the GPU ?

> Any ideas on how to improve the performance over TigerVNC server? We''ve
> looked at things via top and using "perf stats" but don't see any glaring
> issues other than the extra memory usage we'd expect to see with TigerVNC
> server running.
>
> Thank you much - Richard

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

[DRC]

What CPUs are on the client and server? Assuming you are using the default (“Tight”) encoding, the performance of TigerVNC is heavily dependent on libjpeg-turbo, which I maintain, and the performance of libjpeg-turbo is heavily dependent on the type of CPU and the SIMD instructions that it supports. You should be good with any modern x86 or Arm CPU.

TigerVNC does not offload anything to the GPU. It uses CPU-based compression.

If the application uses OpenGL, then that could explain the performance disparity, as OpenGL is not GPU-accelerated in TigerVNC by default. You would need to use VirtualGL (which I also maintain) to get GPU acceleration for OpenGL.

> On Apr 22, 2024, at 2:42 PM, Andrew C Aitchison <and...@aitchison.me.uk> wrote:

> --
> You received this message because you are subscribed to the Google Groups "TigerVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/2df9a1c2-7e1e-e92b-99a7-624c40ac9bcb%40aitchison.me.uk.

[Richard Mixon]

My bad for not including more information.

"Server" computer:

• Atom E3945 (4 cores);
• 2GB RAM
• 8GB SSD
• OSL Ubuntu 22.04
• AIR app built with latest Harman AIR SDK (50.2.5)
• When running on a remote display/browser:
• tigervnc-standalone-server and dependencies (runs as service tigervncserver@:1.service) version 1.12.0
• noVNC version 1.4.0

"Client" computer:

• When noVNC is used, then the web browser used to connect/display is a Windows workstation with 6 core i7-6850K
  In the field this would be an embedded web browser on a "smart display".
• When noVNC was not used (just for comparison purposes) the Tiger VNC Client was run on a VM with 2 vcpus running Ubuntu 22.04 as a Hyper-V VM on the above workstation.

I don't find any mention of "tight" encoding (or even encoding) in /etc/tigervnc/vncserver-config-defaults. I also could not find references on the system to VirtualGL or libjpeg-turbo,

Curiously, on the previous stack for this application/server, the same hardware ran "fine" - i.e. frame rate was about 12 always. It has the following different characteristics:

• OS: Ubuntu 12.04 (yes, a 2012 OS)
  
• Adobe AIR runtime
• When running on a remote display/browser:
  
• tigervncserver running as an /etc/init.d service, version 1.7.0
• noVNC version 0.6.1

On the surface it seems the key difference is either the more recent version of tiger vnc or the updated OS ... since taking noVNC out of the picture does not change the results.

Any ideas/help are much appreciated

Thank you - Richard

--

Richard Mixon

2209 E. Constance Way

Phoenix, AZ 85042

mobile: 480-577-6834

[Richard Mixon]

On Mon, Apr 22, 2024 at 3:48 PM DRC <d...@virtualgl.org> wrote:

What CPUs are on the client and server? Assuming you are using the default (“Tight”) encoding, the performance of TigerVNC is heavily dependent on libjpeg-turbo, which I maintain, and the performance of libjpeg-turbo is heavily dependent on the type of CPU and the SIMD instructions that it supports. You should be good with any modern x86 or Arm CPU.

TigerVNC does not offload anything to the GPU. It uses CPU-based compression.

If the application uses OpenGL, then that could explain the performance disparity, as OpenGL is not GPU-accelerated in TigerVNC by default. You would need to use VirtualGL (which I also maintain) to get GPU acceleration for OpenGL.

OK, I figured out how to install libjpeg-turbo. It did not seem to make any difference in our frame rate. 

I also installed the latest virtualGL - again, it did not seem to make a difference.

n2kowner@host:~$ sudo egrep -e "libjpeg|virtualgl" /var/log/apt/history.log ..... Commandline: apt install libjpeg-turbo-official
Install: libjpeg-turbo-official:amd64 (3.0.2-20240124)
Commandline: apt install virtualgl
Install: virtualgl:amd64 (3.1.1-20240228)
n2kowner@host:~$

Are there settings in /etc/tigervnc/vncserver-config-defaults that are needed to enable either of these libraries?

[DRC]

libjpeg-turbo is already used by TigerVNC. You don’t have to install it separately. As far as VirtualGL, simply installing it won’t do anything. You need to read the VirtualGL User’s Guide regarding how to activate and use it.

On Apr 23, 2024, at 1:21 PM, Richard Mixon <rnm...@gmail.com> wrote:



[Richard Mixon]

First, on the VirtualGL option ...

Going through the VirtualGL requirements it mentions needing an AMD or nVidia GPU on the "server".

https://rawcdn.githack.com/VirtualGL/virtualgl/main/doc/index.html#hd004001

Our hardware does not have an AMD or nVidia GPU - it is an Intel SOC system (Atom E3845) with builtin Intel HD graphics:

https://ark.intel.com/content/www/us/en/ark/products/78475/intel-atom-processor-e3845-2m-cache-1-91-ghz.html

Is VirtualGL likely to work in this situation?

Second, noVNC has settings to influence how the underlying VNC software handles quality and compression. I have tried changing these in /noVNC-1.4.0/app/ui.js but do not see any difference in performance. Am I missing something or not setting these in the correct place? Here are the default settings, I've tried increasing and decreasing each.

UI.initSetting('quality', 6);
UI.initSetting('compression', 2);

Thank you much - Richard

[DRC]

AMD and nVidia are recommended, and those are the only GPU types that VirtualGL officially supports. However, VGL should work with Intel GPUs as well.

Changing the compression level and quality might affect the frame rate if the frame rate were limited by the network, but the fact that you can only get 12 fps locally tells me that the frame rate is application-limited. You never mentioned the frame size, but TigerVNC should be capable of streaming 50-100 Megapixels/sec on a LAN when using the TigerVNC Viewer. The performance will be less than that when using noVNC, but I still suspect that the reduced performance is due to something other than the RFB transport layer or the network. Try to get it working with VGL, and we can go from there.

On Apr 24, 2024, at 2:18 PM, Richard Mixon <rnm...@gmail.com> wrote:



[Richard Mixon]

OK, I've got the latest virtualgl installed. After reading through the background section on VirtualGL I'm guessing that we are more interested in the GLX option rather than EGL - but that's just a guess. I tried configuring both option 1 ("GLX + EGL back ends") and option 3 ("EGL back end only"), , but I'm not seeing much difference either way.

The only confirmation I received from Harman on the use of OpenGL in the new Linux AIR runtime was:

... We do use OpenGL for macOS and Linux runtimes, certainly if you’re using “direct” or “gpu” render modes. ...

Any pointers on how to proceed are welcome.

Thank you - Richard

[DRC]

Did you run the application using vglrun?

On Apr 25, 2024, at 4:08 PM, Richard Mixon <rnm...@gmail.com> wrote:



[Richard Mixon]

No I did not. The instructions do not mention vglrun until towards the bottom in this sections "6.4 Using VirtualGL with Multiple GPUs".

So I tried it using vglrun  in a command line like this:

/usr/bin/vglrun '/opt/<application>'

I am seeing a noticeable improvement - from 8 to 10 frames per second. Are there any particular options/parameters I might try using to coax a bit more performance?

FWI, as I understand it the application limits itself to 12 frames per second. If it's running faster it adds time/sleeps so as to not go faster than 12 frames per second.

Thank you much for your help - Richard

[DRC]

Chapter 6 is still a configuration chapter. Chapter 9 is the relevant usage chapter for a VNC server, and it does mention the need to use vglrun.

You might try passing -sp to vglrun to disable frame spoiling. It may not help the frame rate, but disabling frame spoiling is theoretically the right thing to do with any application that measures its own rendering performance or with any non-interactive application.

On Apr 25, 2024, at 10:10 PM, Richard Mixon <rnm...@gmail.com> wrote:



[Richard Mixon]

Thank you for pointing me to Chapter 9, that makes more sense now.

I did add the -sp option and it seems to have given us another  10% increase in frame rate - e.g. 8.1 fps versus 8 fps.

Our system only has 2GB of RAM, but we have a bit more to spare - can that be marshalled to help somehow?

Thank you again - Richard

[DRC]

No, VirtualGL doesn’t need any more memory than is necessary to hold 2-3 rendered frames, which is on the order of megabytes. Why is the application artificially limiting itself to 12 fps? Is it interactive or non-interactive? It seems silly to bend over backwards to try to make TigerVNC+VirtualGL match the artificial limit of 12 fps when you could undoubtedly achieve a much higher frame rate if that artificial limit wasn’t there.

On Apr 26, 2024, at 12:49 AM, Richard Mixon <rnm...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "TigerVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/CACXoXCFbu3AspPVQA6BvtiVgSzVD3W%3Dg8%2BB3Ri%3DMQyJ%3DYvLUtw%40mail.gmail.com.

[Richard Mixon]

My understanding is the application limits itself to 12 frames per second to avoid suciking up resources from other critical processes. The application is a monitoring and alerts application receiving status and alert signals over a dedicated industrial bus.

Question:. Is it feasible to run the older TigerVNC 1.7 on Ubuntu 22.04.  That version did not have the frames-per-second issue, however we were running on a much older version of Ubuntu which we must upgrade for other reasons.

Thank you - Richard

[Richard Mixon]

Just to add a bit more info about how the app processes. The AIR application is single threaded, it runs in a loop. Each loop iteration does the following:

1. Performs calculations and UI widget/graphics updates;
2. Displays the frame
3. If less than 83.3 ms (time for one frame at 12 fps) has passed since beginning of loop iteration, a sleep is invoked for the number of ms needed to bring it to 83.3 ms.

Thank you - Richard