I also have to disable all streams in Restream and then restart everything and all works fine. I usually can completely stop the stream (I can push stop on my atem mini pro). The cache seems to recover by the percentage but it continues to flash and never gets stable again. I then see the cache in my atem mini pro cache strat flashing and then at some point the stream to YouTube (and Facebook in our case) freezes up. I notice that the Restream monitor video skips a little. ![]() Some weeks our church service goes fine, but about half the time the everything seems to stop working at around 40-50 minutes into the service. We have created a support case with Citrix, and keep you informed.I think I may have the same or similar problemīoth Restream and my ISP don’t see any problems. So this will almost exclude the VDA software.īecause we had 3 versions on the VDISK we did a merge, then we see that the package loss is decreasing and the latency is not impacted. We also have the issue doing a RDP session to the VDA server. The golden image is setup with only server 2016 installed and the VDA, so there is no other software interfering and no optimization is done. We can simulate this just to start an Office application or doing some Internet browsing. This is for a user a complete system freeze for one or two seconds. When the user is working on the new image we see packet loss and extreme high latency to the VDA, also from VDA to PVS server. The old golden image is working with the same hardware / network and Citrix components, and is working well. We have also the same issue, currently we're building a new golden image with Server 2016. But not on VM's with another golding image, running on the exact same hosts, in the same AD OU and so on.Īny feedback, even "you're a moron if you haven't tried this:" - I'll take anything :) So, basicly - I get short screen freezing on my VDA, and actual packet loss when pinging the VM at the same time. This led us to try out a different Xentools version, but alas no change was seen. Looking at the Xenservers running the VM, the packet loss matched a high CPU load on one of the VM cores. If I don't put any user load on the new golden image, I can still see small "spikes" via Pingplotter with 50-100ms delay that aren't there, with a fully loaded server running the healthy image. ![]() This image has been thru a couple of versions over the last six months, and so its a bit difficult for me to replicate it 100% - although, I doubt that we are faced with a situation where only the magic combination of software works. Even a bone stock W2016 with the bare minimum of software needed: VDA, PVS - has the same issues.īut - the image that we currently have in production is working just peacy. ![]() Nothing definitive seems to make a difference. Windows 2016: Clean from ISO, and varying levels of cumulative updates.Ĭlient software has been tried also, Receiver 4.9, 4.11, 1808 - HDX 2.3, 2.6 - all same result. Xentools: Three different version spanning 7.1, 7.1CU and latest as of a few weeks ago I've tried more of less every thinkable combination of: The MDT process is locked down pretty well, so there really isn't any difference in how the master images are prepared. And it doesn't take much more than 2-3 users for this to be noticable. In this period the VDA doesn't even respond to ping - and users that are logged in also notice that the HDX realtime connector status displays "connected" when the screen freeze is done - kind of like the server looses all connection to the outside world.ĭepending on the amount of users, this can go from slightly annoying to absolutely unbearable. This is the same across several physical hosts. Short story long: whenever I try to create a new golden image using MDT, and implement this via our PVS, I end up with a VDA that - when "pushed" - experiences short hang/freeze moments, upto 1-2 seconds. Hope everyone is slowly gearing down for the holidays :)īut before doing so, I'm being taunted by our Xenapp environment at the moment, and could use the help of some fresh minds.
0 Comments
Leave a Reply. |