Win10/Blast VDI on 5010s

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #53961
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    We recently completed a migration to Windows 10 1809 in our Horizon VDI environment, that coincided with going to WTOS 8.6_206 and utilizing Blast (latest Horizon 5.1 client). Since this has happened, we’ve received pretty consistent reports of VDI performance from our client base.

    The problem we’re having is isolating if it’s poor performance in our main application, Epic Hyperspace, or within the VDI desktop itself. That’s still being looked at. One thing we have noted, is all of the complaints seem to be coming from our base that uses 5010s, where as the base that uses 5070s, we haven’t heard from. Same OS level, same Horizon level, both have mix of wired/wireless but use the exact same WMS config. It could very well be happening in both user bases, and maybe the 5070 base is just more forgiving, we’re not sure.

    In a nutshell: is there any concern with using the 5010 as a hardware platform for Horizon 7 VDI utilizing Windows 10 via Blast? We are NOT doing anything graphically intensive, nor are we doing any GPO/DEM tasks for Blast optimization/throttling.

    Thanks.

    #53967
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    Spoke to Dell, as well as another user from this forum. Theory is that since the 5010s don’t support Blast H.264, that may be our root cause. Dell suggested possibly going back to PCoIP on our 5010s, but, that’s really not an option. We’re going to discuss some options tomorrow, like possibly doing some Blast tweaking. Unfortunately that this is needed, but, if it works it works.

    When connecting with a 5010 we ran the Horizon Perf Tracker, and saw the encoder being used was “adaptive”. The encoder on a 5070, same exact pool, the encoder was using H.264.

    #53976
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    Turns out that probably isn’t the route after all. After some discussion, the policies modying/conditioning Blast really don’t seem like a fit for us, nor a fix for what we’re seeing. I’m still convinced it’s the actual installed app IN THE IMAGE that is an issue, not the Blast/thin client config.

    Search continues.

    #55355
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    Updating this some, hopefully it goes somewhere and we can provide a solution.

    Environment reminder: we are Windows 10 1809, 3vCPU/6GB of memory instant clones on a Horizon 7.8 infrastructure. All terminals are standardized on 8.6_206, 5010/5070.  vSan ready nodes all flash. Horizon client is 5.1.19059218. The horizon.pkg is the only package we deploy to terminals via WMS. Some terminals in the environment also seem to have the RTME.386.pkg but, my assumption is they simply came out of the box with that. We don’t push it.

    We’re a bit at a loss now. Over the past month the issue with “performance” in our VDI environment has expanded. No longer is it really focused on just 5010s, it seems 5070s are feeling it as well if users are to be believed. This kind of rules out the idea that the 5010s not being able to do h.264 was an issue, which I thought was a reach anyway.

    The description of the issue remains vague. The experience feels “sluggish”, and the users claim a logoff/new session resolves the issue, but that eventually they return to that state. No one can really give us an estimate of how long, it’s a wide range. Most of the reports are coming from wired terminal vs. wireless, but, this also could be a result of us just having more wired units. It does not seem focused to any geographic location/building either.

    One bothersome thing is, as a test, we reverted a problem area back to PCoIP. Since that change, the users claim the experience is night and day better. They say they haven’t needed to reboot at all. We’ve checked with our network guys, and there was never any kind of QoS preference for PCoIP traffic ever done, so, it’s not like that’s a step we missed when going to Blast. As I stated previously in the thread, we really didn’t do anything specific when it came to our flip to blast: no GPOs, no smart policies from VMware DEM, etc.

    The switch back to PCoIP obviously can’t be permanent. As I said though, we’re kind of stumped.

    We’re deploying, as a test, 8.6_606 to an area to see what kind of testing we get. I read through the release notes of all versions between 206 and 606, and some Blast things did catch my eye:

    In 8.6_206 (our version), THINOS-771 is listed in the resolved issues: “Resolved Blast performance issue on Wyse 5070 Thin Clients”. Sounds perfect, but, iffy.

    In 8.6_303, THINOS-2299 is listed in the resolved issues: “Resolved the issue where BLAST performance reduces on the Wyse 3040 and Wyse 5070 thin clients running ThinOS 8.6_206”. This is the one we’re banking on in the move to .606. It does state just 5070, but, would be nice if it ripples into our 5010s as well.

    8.6_412 = no mention of Blast/5010/5070 fixes

    8.6_511 = no 5010/5070 specifics, Blast specific but no really for us: THINOS-2505 Fixed the issue where the Blast main screen application switches display after reconnection.

    8.6_606 (latest) = no 5010/5070 specifics, Blast specific possibly related to us (although not heard about): THINOS-2494 Fixed the issue where during the VMware blast session, scrolling functionality of the mouse was triggered when the forward and backward web navigation side mouse buttons were clicked.

    I have spoken about this issue with a fellow member of these forums, and one policy he mentioned to look into, is this one below from WMS. He was saying perhaps change the network condition to typical. It’s been set to Excellent from the get go, but, we’re ready to try anything.

    Apologies for the super long post. Trying to figure this out has been a bit of a pain. We’ve opened tickets with Dell and VMware, but, they really haven’t gone anywhere. VMware’s review of our agent logs on a test VM were literally “yeah we don’t see how this could look better”, but we’re getting hammered out in the wild.

     

    #58380
    ConfGen
    Keymaster
    • Total Post: 10696
    • Jedi Master
    • ★★★★★★★

    I would even go with “Poor” as this switches from TCP to UDP.
    Worth a try.

    CG

    #58414
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    Doesn’t seem like it works on the 5.1 client on a 5010 at 8.6_206. I changed the condition to poor, tried going to a pool, after a few seconds the terminal rebooted (almost like it connected and disconnected rapidly). Trying on 8.6_606 yielded the same result.

    Can 5010s via Blast not do UDP? Guess I’m mixing up my testing, I thought they could.

    #58418
    ConfGen
    Keymaster
    • Total Post: 10696
    • Jedi Master
    • ★★★★★★★

    Yes, they should be able. This was a standard 8.x feature

    CG

    #58444
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    I tested on a 5010 and 5070. Both in the same WMS policy, both on 8.6_206, both using Horizon client 5.1.19052918. 5010 connected with TCP when on Excellent or Typical condition. On Poor, it could not connect at all. The 5070 connected with TCP on Excellent and Typical, connected with UDP on poor.

    I’m guessing a limitation of the 5010s. Unless there’s something else I’m missing.

    #105358
    epa80
    Participant
    • Total Post: 208
    • Jacked into The Matrix
    • ★★★★★★

    Updating this some. We’ve been sticking with Excellent the whole time while we’ve been troubleshooting other possible culprits, but, at Dell’s request, we’re switching to Typical across the board. Our SE stated this is the standard across most/all of his large clients. Switching to poor on the 5010s isn’t an option. Even on 8.6_606 with the latest Horizon client, they can’t do UDP. If you switch them to poor, as soon as they authenticate to Horizon and start to launch a VM, they disconnect.

    We’ll be pushing it out enterprise wide (10,000+ terminals) in a week or so and I’ll update the thread some more.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.