First of let me start by stating that the subject of the blogpost is purely to get more viewers… But there is some truth to it, over the last weeks there has been alot of people talking about RDP / ICA / PCOIP and that the protocol wars are over.
There are multiple articles on the subject, but this one started the idea –> http://www.brianmadden.com/blogs/guestbloggers/archive/2015/11/25/are-the-display-protocol-wars-finally-over.aspx
And here as well –> https://twitter.com/michelroth/status/670288837730541568
So I figured since me and a good friend of mine @Mikael_modin have done alot of testing on Framehawk vs ThinWire (and with RDP in the mix) https://msandbu.wordpress.com/2015/11/06/putting-thinwire-and-framehawk-to-the-test/
Where we did a test based upon different packet loss parameters and measured is using uberagent splunk and netbalancer to see how it performed. The test consists about 5 minutes for each test where we did 1 minute of idle workload, 1 minute of web browsing using Chrome on a newspaper, 1 minute of PDF browning and zooming, 1 minute of word typing, Avengers Youtube trailer. The test was to be contucted on the same virtual infrastructure with the same amount of resources available to the guest VM (Windows 10) and no other firewall releated issues, and with just one connection server with a VDI instance. So this is purely a test of resource usage and bandwidth and how it adapts to network changes. There are of course other factors which kick in terms of performance +/- and other things.
Another thing is that I am by means no expert of View, if someone disagreed with the data or if I have stated something wrong please inform me of it.
So therefore I figured it was about time to put PCoIP to the test as well. Now I know that PCoIP has different protocol usage (HTML5/Blast and its own for GPU) but I am testing the native PCoIP Protocol) and no change besides the default setup.
For those unknowning, PCoIP uses TCP & UDP port 4172, where TCP is used for session handshake and UDP is used as the transport of session data. Now the issue with UDP is that its hard to control the traffic flow. PCoIP is a “quite” chatty protocol
which means that a better experience (if the line can handle it) so it will be interesting to see how it handles congestion)
So from the initial test (with no limits what so ever)
It consumed about 168 MBs of banwidth, with a max amount of 933KB/s which was mostly during the Youtube showing of Chrome.
The View agent only used about 7% average CPU during the test.
The max amount of CPU at one point was about 23% which was during the youtube testing
Not such a heavy user of RAM as well
During our test using Framehawk and ThinWire on the same test we could see that Framehawk for instance used about 224 MB/s of bandwidth with a max of 1,2 MBps and oddly enough this was during the PDF scrolling and zooming which generated the most bandwidth.
On a side note, framehawk delivered the best experience when it came to the PDF part, it was lightning fast! Thinwire on the other hand used only 47 MBs of bandwidth, most bandwidth was during the Youtube part. Thinwire used the same amount of CPU usage.
Now as part of the same test we also turned up the packet loss to a degree that it would be able to reflect upon a real-life scenario. So at 5% packet loss I saw alot of changes
Now PCoIP only used about 38 MBs of banwidth, looking kinda similar to thinmwire usage… But this was quite noticeable from an end user perspective. Not quite sure if there is a built-in mechanism to handle QoS under packet loss.
Now when we did this with ThinWire and Framehawk during the same test we got the following results (11 MBs bandwidth)
Framehawk (used about to 300 MBs bandwidth) I’m guessing that it got in ass in gear when it noticed packet loss and therefore tried to compentanse by trying to max my banwidth available.
So in terms of packet loss, Framehawk handles it alot better then PCoIP, and ICA which uses TCP still manages to give a decent user experience but because of the TCP rules and congestion algoritms it not really as useable. Now since there was packet loss and hence less banwidth to transmit, the CPU had less to do.
With 10% Packet loss, we could also see a good decrease in bandwidth usage. Which means that it had a hard time keeping up with want I wanted to do, now it was down to 27MB of bandwidth usage, and struggled during the PDF and browsing wasn’t really good.
So as a first quick summarization,
- the View agent is “lighter” meaning that is uses less CPU and memory on each host.
- Its a chatty protocol, which I’m guessing that it work well in a highly congested network, ICA is also chatty but since it uses TCP it can adapt to the congestion
- The plus side to it that since there is a steady flow of packets it delivers a good user experience.
- It cannot handle packet loss as well as Framehawk, it was better then Thinwire on packet loss, but Thinware was never aimed for lossy networks.
Conclusion: Well I’m not gonna post any conclusions related to this post, since in some social media circles.. 
Well let’s just say that you can draw your own conclusion from this blogpost and ill just end the post with the picture of these two cars and you can point out which is which
