Wyse Xenith 3 (3020) poor graphic performance

There is no way to tune that in any kind.
The devices are simply too old.

CG

I am going to add to this, as I have noticed similar “disappointing” performance with Virtual Apps 1912 LTSR with Wyse 3020 (Xenith Pro 3) units recently.

But first, I need to take you back 5.5 years 🙂 ….

I deployed a XenApp 7.6 desktop on Windows Server 2012 R2 for a customer, and they used Xenith Pro 3 (T00D) units (now called “Wyse 3020 zero client for Citrix”, in the Great Rename). At the time, they were deployed with firmware 2.1_027, and things like YouTube could play full screen on a 1920×1080 display with no issues. It was very satisfying to see this operate over WAN links, and everyone was impressed (“hoorah!”).

Jump forward in time a bit, and the Citrix XenApp was upgraded to 7.15 LTSR, and still there were no complaints.

Jump to this year, and a new Citrix Virtual Apps environment on Windows Server 2019 was deployed, and due to COVID, etc. thin clients were not wanted to be replaced, so the firmware was updated to the latest/last release of 2.6_412 as part of the migration to ensure compatibility with the latest StoreFront and VDAs, etc.

Now, the clients worked fine with the Citrix VA 1912 LTSR environment (no issues with StoreFront, etc.) … except in things like YouTube. Even if the website is left at “normal” sizes, so the video is less than half the screen, it is choppy and terrible. Looking at the local performance monitor on the 3020, you can see that one single CPU core is maxing out. If the video size is scaled down (to less than 1/8th screen size, or more), then the single CPU core stops maxing out and the video plays well.

Connecting back to the old XA 7.15 LTSR environment causes the same issues though.

Which kind of points the finger at some change between 2.1_027 and 2.6_412 that is causing the high CPU usage, almost as if something that was previously hardware-accelerated is now forced in to software-only mode.

I know that all the new Citrix BCR stuff is not supported in this now-obsolete models, but previously I believe that some kind of codec “pass-through” was in effect, whereby the server didn’t decode the video stream but passed it to the client to decode, thereby saving a lot of decode/encode/decode overhead. I think I remember moving the YouTube page around the screen rapidly, and seeing the telltale signs of a blank video section in the background with the Wyse client not quite keeping up with its video stream overlay.

Now I know a lot of this is “I remember this” and “I think that”, and I am not asking for definitive answers and/or fixes. But is there any known reason why this would be happening? The cynical amongst us would cry enforced technical obsolescence by artificially removing a feature that used to work, although there may well be a technically valid reason for this.

Unfortunately, I didn’t have time to try downgrading back to 2.1_027 (if even possible?) and testing it. We have just accepted that this is what it is, unless a “magic switch” is found.

On a side note, a 3040 running ThinOS 8.6_606 also suffers a similar fate, except as it has a more powerful CPU it can just about maintain the standard YouTube video in a browser page at 1920×1080, but fails if you go larger or fullscreen. The local CPU doesn’t quite show the same “single CPU core maxed out” (it has 4 cores), but it does show elevated/spikey CPU activity.