Archive for the ‘Myth Buster’ Category

MYTH: The PCoIP protocol requires 10x the bandwidth of Citrix HDX

Saturday, November 21st, 2009

REALITY: The PCoIP protocol optimizes the user experience to the available bandwidth

The PCoIP encoding algorithms attempt to deliver a perfect, high-frame rate display experience whenever possible. Think of this like a high-performance sports car that will easily exceed 200kph on the open Autobahn, but slows down when driving on local roads or in congested traffic. Because the PCoIP algorithms can deliver a superior experience to Citrix ICA/HDX, when using them both in a single session on a 1Gbs network, the PCoIP session will deliver a superior image quality and frame rate, but will also use more bandwidth much like the high-performance sports car will go faster on the Autobahn than the average family car. In fact, in Citrix’s own bandwidth sizing presentations, they state, “Single session bandwidth testing is invalid”. We agree with this statement and suggest that Citrix follow their own guidelines.

The more relevant way to benchmark the two protocols is compare the user experience delivered when the network is constrained to say 5Mbs or 1Mbs or 200Kbs. In these constrained networks, the PCoIP user experience is equal to or better than that delivered by ICA/HDX under the same network constraints. This means that no matter the network conditions, the PCoIP protocol will optimize the user experience to the available bandwidth. Many customers are successfully deploying PCoIP solutions across WANs with high latency and limited bandwidth and are very satisfied with their experience.

For some additional clarification, the 10x bandwidth numbers that Citrix cites in their literature is based on comparing HDX-3D at it lowest quality and frame rate to a PCoIP session operating at a perception-free experience. This is because the two protocols have completely different philosophies on quality settings. For HDX-3D, the image quality settings are used to limit the maximum bandwidth by explicitly limiting the maximum quality and frame rate that the user can experience. This is like forcing a car to drive at 20kph no matter what the current road conditions are. In contrast, the PCoIP image quality settings represent the minimum image quality that the user will experience. If more bandwidth is available, the encoder is allowed to use more bandwidth to deliver a better experience. Thus, even on the lowest quality setting, a PCoIP session on an unconstrained 1Gbs network will still operate at the maximum frame rate and image quality it can deliver. In this case, the PCoIP sports car is driving over 200kph on the Autobahn while the HDX-3D sedan is only going 20kph even though the road is completely clear. Obviously, user experience must be factored into any benchmarks comparing virtual desktop protocols.

MYTH: The PCoIP protocol relies primarily on the server to do all the heavy lifting

Saturday, November 21st, 2009

REALITY: The PCoIP protocol is a comprehensive solution with options for stateless hardware zero clients

While some workload may result in the PCoIP protocol using more CPU than other protocols, the VMware office productivity interactive workload benchmark shows that the PCoIP protocol uses less CPU resources than XenDesktop 4 or RDP7.  Thus, the scalability of a VDI deployment using the PCoIP protocol should be equal to or higher than XenDesktop 4 or RDP7 (however, the PCoIP user experience will be better).  Furthermore the PCoIP software encoder requires less memory on the server than XenDesktop 4 or RDP7, which further helps scalability,
 
One very important advantage of host-rendering or server-side processing is the enablement of highly capable, zero-clients on the receiving end.  A completely stateless, hardware zero-client requires no operating system patches or anti-virus software. They can be very low-power devices while still delivering the highest possible user experience. This is just not possible with a client-rendered device. A PCoIP zero-client can further improve the opex savings associated with moving to a VDI deployment by reducing power consumption, eliminating management overhead, and providing a longer product life cycle.

In many ways, PCoIP technology is the only complete protocol. The graphics independence of the protocol means that all applications today and tomorrow will “just work” and not have to wait for an update to the protocol. Furthermore, no other protocol provides a true, zero-client to compete with the PCoIP Portals and integrated monitors from a wide variety of leading OEMs.

MYTH: The PCoIP protocol claims bitmap remoting is the best way to deliver graphics

Saturday, November 21st, 2009

REALITY: Teradici claims host rendering with intelligent display decomposition and compression is the best way to deliver desktops

Bitmap remoting is NOT the best way to deliver graphics.  This is why the PCoIP protocol does NOT do bitmap remoting.  Instead, the PCoIP protocol uses host rendering to generate the entire display image at the server/workstation in the datacenter. A display decomposition layer then selects the proper CODEC for encoding each region of the screen. So, for example, a 400×300 rectangle with black borders and white background is not sent as a bitmap.  This is decomposed into a white background and a black border and compressed as a two-color object that is just as efficient as a RECT command with coordinates.  As another example, in most cases, a text-based web page encoded using the PCoIP protocol compresses into the same amount of data or less than sending the HTML for that given web-page.  PCoIP algorithms include intelligent rendering functions wrapped into its encoding scheme. 

For client rendering protocols like RDP and ICA/HDX, many years of fine-tuning are required to deal with all of the different graphic primitives of OpenGL, DirectX and whatever may come (e.g.. Web3D, HTML5, ON2 …).  However, by generating all of the pixels at the host and using intelligent decomposition, the PCoIP protocol is independent of all the different graphics APIs. This graphics independence has allowed Teradici to spend all if its time and effort on how to properly encode the data to provide the best user experience.  The PCoIP protocol has five+ years of fine-tuning already under its belt and will continue to improve in the future.

MYTH: The PCoIP protocol bets on UDP as the foundational transport for graphics

Saturday, November 21st, 2009

REALITY: TCP constrains Citrix ICA and Microsoft RDP

TCP is a great transport for data traffic that requires reliable packet delivery and is not sensitive to interactive latency.  Some examples are: file transfers, HTTP web pages, or streaming data that is uni-directional (i.e. media streaming with large buffers). However, TCP is not the optimal transport layer for data traffic that is sensitive to interactive latency and does not require reliable packet delivery like Voice-over-IP (VoIP), Video Conferencing, or a remote desktop experience which requires instantaneous interaction and constant content updates.  This is why VoIP and Video Conferencing use UDP and why the PCoIP protocol is optimized for UDP.

For data traffic like this, TCP is a limitation, not an advantage since it requires reliable packet delivery even when it is unnecessary.  For example, if you have 3 screen changes A, B, and C; throwing B out is perfectly fine as long as the C screen change replaces what was done in B. However, TCP will continue to retransmit B until it all arrives reliably even if C has already reached the destination.  So, in the presence of packet loss, TCP will introduce unnecessary latency and retransmission.

For client-rendered protocols, like RDP and ICA/HDX, reliable packet deliver is almost always required because graphics primitives are being sent, not screen pixels. As a display screen is being rendered at the client, many of the graphics primitives are dependent on previous primitives. Thus, they all need to arrive reliably and in order.

These client-rendered protocols do employ sophisticated techniques like “tossing” to throw away graphics primitives that will be overwritten by subsequent primitives. However, these techniques do not work for primitives that have already been sent onto the network. Once a primitive has been sent using a TCP packet, it will be retransmitted until it has been delivered to the receiver adding latency for something that could have been thrown away. Packet loss generally only occurs in WAN environments which also have the highest latency. Thus, WAN connections benefit the most from the ability to discard overwritten packets since they will have the most packets “in flight” due to network latency and are most likely to lose packets. This is why WAN connections benefit the most from the use of UDP by the PCoIP protocol.