continuing on my slow tesla testing journey and I’ve been playing around a little bit with Win10 - I’m having some pretty serious issues with the performance of video within Web browsers.
Everything works fine in Windowed mode - but as soon as I go fullscreen then the issues start:
-IE is extremely choppy and is just horrible in general (I’ve checked it’s not using CPU for rendering)
-Chrome is smooth for around 5 seconds then the screen just freezes (audio still going) until I switch back to Windowed mode where the video catches up to the audio
On the exact same hardware my Windows 7 stuff works without any issues with either browser when NVENC doesn’t crash during login…
Running the MG0-1q profile across the board. The screen doesn’t freeze in chrome on a 2GB profile - IE is still rubbish though
Anyone else seen/heard about this type of issue?
I’ve just tried this with an M60-1Q profile on W10 and I do not have these issues. I’m in the UK, but to connect to my platform I have to go via Amsterdam then back into the UK (don’t ask), I’m currently connected via WiFi and then over the internet so a less than controlled connection with plenty of areas for issue, although I do run through a Netscaler to help optimize things. Both IE and Chrome are perfect when playing this video at 1080p, I’ve also tried Firefox which was also perfect. I’ve listed the video so we can test the same thing:
Either windowed within the browser (standard playback) or full screen, neither give me any issues. Audio is great with no sync issues, there’s no frame drops and picture quality is very good with no image crush.
Using MS Sysinternals I can see the GPU is running at between 12-18% when full screen.
A few questions for you:
What’s the spec of your VM? (CPU (Cores & Speed), RAM)
What screen resolution are you using?
Single or multiple monitors?
Which Citrix policies do you have applied?
Which version of XD are you currently running?
Which version of Receiver are you running?
Is your local client “hardware decode” capable, and if so have you enabled it?
What is your local / client Operating System?
Remember that due to the generation differences, Windows 7 and Windows 10 handle graphics in different ways. Windows 7 uses legacy Citrix policy settings, whereas Windows 10 uses the current settings and legacy settings do not apply to it.
Thanks for the response, using gpu-z I see around 25-28% utilisation, fullscreen and windowed shows minimal difference.
-The VM I’ve tried is 2/4 cpu 4GB RAM - the host cpu is E5-2640 v4 @ 2.4ghz
-Screen res is 1900x1200, although I get the same perf on my laptop at a much lower res, both dual or single screen doesn’t appear to matter either.
-I have only got a couple of specific policies applied to the windows machine (like nvenc etc) - I think I’ll circle back and build a full policy specifically for the test machine so I can know for sure what’s been applied.
-VDA is 7.11 and the backend is 7.11 - although I previously tried on a 7.6 backend (with 7.11 VDA) and the results were the same.
-Endpoints I’ve tested with can decode, I haven’t explicitly enabled anything - would’ve have thought I would need to?
-Local endpoints are Win7
Perf/issues persist over both LAN and Wireless.
I’ll setup a dedicated policy and see how I go… I really want this to work!
No worries with the VM spec or resolution, that all looks fine for what you’re doing.
For simplicity, can you try removing every Citrix policy that is applied to your W10 VM and run the same test with the video and compare the results (you shouldn’t have many applied so should be pretty quick and easy). This will use CPU encode, and not NVenc so it will be a good benchmark to see the difference. It’s not uncommon to have way too many Citrix policies applied and they actually degrade the experience rather than improve it.
The 7.6 backend won’t have the NVenc policies / feature to enable, they were only released with 7.11.
As for the end points, yes, if they are hardware decode capable, then you should absolutely be using it. To double check if you haven’t already done so as to whether your endpoints have this ability, you need to run a tool called a DXVA checker. You can get that from here: http://bluesky23.yukishigure.com/en/DXVAChecker.html
When you run it, you’re looking for the entry I’ve highlighted in the attached .jpg
If you need the settings to enable it, let me know as I have these in a .reg key that you simply merge with the local OS. If you now monitor the endpoint GPU, the H.264 decode process takes up approximately 10%. This is important as the decode process when run on a CPU is single threaded, whereas on a GPU it’s multi threaded, so it can decode quicker. This is important because of the way that Citrix as a system works … ;-)
Let me know how you get on
My DXVA shows the same as your screenshot minus D3D11 - my endpoint CPU is an Intel HD530 - not sure if that is relevant but I suspect not.
Interestingly if I RDP to the machine the performance is pretty good - I can see decoding being used via nvidia-smi and I don’t suffer the issues above in either browser.
When I use HDX is when the issues start - nvenc on sees encoding being used on nvidia-smi, nvenc off sees overall video performance pretty poor (I can’t watch 1080p fulscreen withou major choppiness) - however there is no decoding going on like RDP? I’m not sure if this is expected behaviour?
I’ll remove all the policies now and see how that goes
Equally weird… if I fullscreen but have something else with focus (say task manager always on top) the video never pauses in chrome - it just works - as soon as I return focus to the video it then freezes after after a few seconds until I switch back to windowed mode…
this is very frustrating!!!
“HD 530” is the graphics series on your endpoints CPU, just out of interest, what’s the CPU model?
Did you enable hardware decode on the endpoint? Any difference?
For this test, apart from some "Session Limit" and "Security" Policies, the only settings I have applied to my W10 VM are as follows:
Target Frame Rate - 60 FPS
Use Hardware Encoding For Video Codec - Enabled
Use Video Codec For Compression - Use When Preferred
Is your Policy the same or do you have a different configuration?
I haven’t enabled anything extra on the endpoint, CPU is an i5-6500. Are you able to send the regkeys?
I logged in to the desktop from my personal PC at which is a Win10 machine with a i5-4660k and a GTX970 on a 100MB FTTH connection and I had the exact same issues so it doesn’t seem to be endpoint related, it’s either something wrong with my SOE or HDX…
My VM is running on ESXi so not sure if that helps… I even disabled the VMWare VGA. The window focus thing is the weirdest - it shows it CAN work and run well but just won’t for some reason…
I am using those above policy settings at the moment, they were my original settings I tested with before posting.
That’s a decent CPU on the endpoint, shouldn’t have any issues decoding the H.264. However, it’s still a single threaded process and is best off being handled by the GPU when possible. It’s just more efficient.
I’ve attached a .txt file. Download it, change the extension to a .reg and just Merge it on your endpoint. This will enable hardware decode.
We use vSphere and Xen on our platforms. When using vSphere, I don’t install the SVGA drivers when installing VMTools. Did you remove any Ghost adapters from device manager before running it through MCS / PVS?
HW Decode.txt (143 Bytes)
I’ve been looking into your issue with Chrome locking up when running in full screen in my XenSever lab and I can replicate and stop it from happening, but I wouldn’t call it resolved. The problem I have, is that I cannot replicate it on my VMware platform, so I’m not entirely sure what’s causing it.
To resolve the freezing, in Chrome go to: Settings > Show Advanced Settings > System and un-check "Use Hardware Acceleration When Available".
This is obviously counter intuitive and yes, ideally you want to use the GPU for this, however this will resolve the freezing issue but you’re no longer using the GPU.
I can confirm that switching off hardware acceleration also work for me. Very interesting! I also forced hwdecoding for receiver and I can see that usage you mentioned earlier