Jump to content


Photo

Framehawk Woes

Started by Patrick Sudderth , 16 July 2015 - 10:31 PM
9 replies to this topic

Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 16 July 2015 - 10:31 PM

We're having some Framehawk woes and I was wondering if anyone else ran into any of these issues.  

 

1)  Framehawk in Director does not show Framehawk as compatible with the VDA.  I've tried multiple VM's and reinstallation of the DDC components.

 

2) Wireshark shows UDP communication so it's actually working.  However, we experience two separate issues:

 

a) Connecting over 1gbps IPSEC: Quick movement, Windowing the session or resizing the session window causes the session to lock, forcing a disconnect/reconnect.

 

B) Connecting "internally" by connecting the Framehawk-enabled session from within my standard VDI session (or from RDP) does not lock in the same fashion but is beyond laggy... Considerably worse than H264, DCR and even the VMware console itself.  Unusable.



Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 16 July 2015 - 10:44 PM

VM Patches Installed:

Citrix HDX WMI Provider x64 2.2.1.0 GPMx240WX64002.msi

Citrix WMI Proxy Plugin 7.6.300.02 WMIProxy_x64.msi

MISA760WX64001.msi 

ICAWS760WX64011.msp

ICAWS760WX64014.msp

ICAWS760WX64024.msp

ICAWS760WX64026.msp

Citrix Virtual Delivery Agent 7.6 7.6.0.5026 (Original ISO Install)

 

 

DDC/Director Patches Installed:

Citrix Group Policy Management 2.4.2.0

Citrix WMI Proxy Plugin 7.6.300.02 WMIProxy_x64.msi GPMx240WX64002.msi

Citrix XenDesktop Powershell Module 7.6.2.5029 XDPoshModule760WX64002.msi

Citrix Director 7.6.300.2 DesktopDirector_x64.msi



Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 17 July 2015 - 01:55 PM

I managed to get FH showing in Win8... Doesnt seem to work at all in Win10 (neither Director, nor actual), however... Strange.

 

I also adjusted an MTU mismatch that was causing the issue over the VPN.  Now the symptoms are the same over the VPN and "Internal"... TCP performance is lightyears faster than UDP.  There has to be something odd causing this...



Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 17 July 2015 - 10:12 PM

FYI... I tested RDP over UDP and it's working fine... Not sure what would be impacting Framehawk UDP :(



Christoph Wegener Members

Christoph Wegener
  • 3,266 posts

Posted 18 July 2015 - 02:33 AM

http://discussions.citrix.com/topic/367200-framehawk-76-fp2-2008r2-vda/



Stephen Vilke Citrix Employees

Stephen Vilke
  • 10 posts

Posted 18 July 2015 - 07:26 PM

Hi Patrick,

 

I just caught a phrase in one of your posts - VPN....are you using site-to-site VPN or client-to-site VPN?  The latter oftentimes is an SSL based VPN which will convert everything to TCP - since TCP likes to do its own quality of service (retransmit lost things) and we do our own, on top of UDP (we don't retransmit anything that we can self-heal in a transition phase) we can fight with TCP....instead, these will go through the Netscaler when Netscaler support is added later.

 

Most Enterprise class site-to-site VPNs are GRE over IPSec - those should be fine...

 

Can you elaborate?  Thanks,

Stephen



Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 18 July 2015 - 09:10 PM

Stephen,

 

Thanks for your reply.  The VPN issue we were having seemed to be caused by an MTU mismatch... It doesn't lock up anymore but it is still extremely slow whereas RDP UDP and ICA TCP are extremely responsive.  

 

The VPN is AES128 IPSEC Site to Site.  However, the lack of responsiveness persists even "internal" when running a Framehawk session from within my standard VDI or RDP session.  I just don't get it :(

 

-Patrick



Stephen Vilke Citrix Employees

Stephen Vilke
  • 10 posts

Posted 18 July 2015 - 10:32 PM

Hi Patrick,

 

Hmmm.  I am forming a few thoughts.  I'll find you on Monday and perhaps we can chat realtime.  Love to help you get this running...

 

Thanks,

Stephen


Helpful Answer

Patrick Sudderth Members

Patrick Sudderth
  • 57 posts

Posted 25 July 2015 - 02:33 PM

After thorough testing, it appears as if the lockups were due to running > 1080p resolution on my 21:9 monitor at the office.  After testing @ 1080p or less, Framehawk does not lock and functions as expected... Likely a framebuffer limitation that will be solved with a patch.  Now... onto the good stuff... Framehawk is the real deal!

 

Observations:

 

  • Running 200+ms latency with 5-30% packet loss and having a functioning VDI workstation is a surreal experience.  Thinwire was completely crippled but Framehawk ran like a champ.  That being said, running in those environments for long periods of time is likely not real-world (unless you're on an airplane) and I'd say Framehawk is better than the local PC experience in those scenarios since webpages barely loaded on the local.  If users are willing to work offline in those situations (like they are used to) then offline may be better.  That being said, I could type and load webpages and even watch fullmotion video without any real issues... Unbelievably cool and amazing... I felt like I was living in the future!  When users realize that they may actually be able to get work done on a plane, they will likely be willing to work through any minor side effects that they may experience in these extreme scenarios.
  • The more likely real-world situation is bursty, intermittent periods of packet loss due to oversaturated/shoddy cellular/wifi signal and I have no doubt Framehawk is going to eliminate all of those concerns for WAN users... Bring on the Netscaler support!!
  • When testing on a WAN Emulator, make sure to disconnect/reconnect when making big latency swings so that Framehawk can recalibrate... i.e. multi-hundred ms latency.  Quick changes to latency don't seem to impact performance much but changing from 1ms and then sticking to 300ms is likely not something that would happen outside of testing so that's just a tip to anyone who might be testing the protocol in their environments...
  • LAN performance is snappy and good... The release notes/blogs on this first release state this is targeted at Enterprise WiFi users and it succeeds.  Over time, I can see this supplanting thinwire in all scenarios... It may need to be tuned a bit more for low-latency, low-loss scenarios where users may expect a near local-like quality/performance but, it's darn near perfect as it stands today!
  • Did I mention, bring on the Netscaler support?  The suspense is killing me!


Stephen Vilke Citrix Employees
  • #10

Stephen Vilke
  • 10 posts

Posted 25 July 2015 - 06:15 PM

Hey Patrick,

 

Just wanted to say I really appreciated your working with me as we sorted it out.  You are certainly a great Citrix supporter and if everyone in the community is as enthusiastic as you, I am looking forward to people using the product!  A couple take aways for me, with some overlap:

 

- i will verify there is a bug opened on the artifacts that were created above 2048x2048

- i will inject notes into the documentation for testing:  any change in ms or bandwidth requires a disconnect/reconnect to enable a calibration

- i put on the future feature list a request for dynamic re-calibration for latency and bandwidth (used to have it years ago, will put it back in)

- for this community, i will continue to note how people "test" to simulate workloads.  The way I used to do it pre-FH (and we noticed you did it) was to grab a window and drag it all over tarnation.  Since Framehawk looks at visual cues and thinwire has access to object layer (some versions like snowball), that test actually will not give easy-to-compare results at a protocol level.  I like alt-tab tests, random animation video and infinite random scrolling to pressure the protocols and to simulate human behaviours.  I offer this back to the community to experiment with:  http://medialab.tiddlyspot.com/

 

Patrick, again, thanks for being the crazy first one out of the gate and helping me recalibrate to a new user's expectations.  Lot of fun and I look forward to the next time...

 

Thanks,

Stephen