HP dc73 HP Blade Workstation Solution Planning Guide - Page 24

5-1 Maximizing RGS interactivity RGS runs in a tightly coupled loop between the RGS Sender (on the blade workstation) and the RGS Receiver (on the client computer). Historically, each display update on the client computer required a roundtrip traversal of this loop-the full network path between the RGS Sender and Receiver was crossed twice, once in each direction, for every update (see Figure 5-2). Figure 5-2 Network traffic between the RGS Sender and Receiver Sender Receiver Capture Image Display Image Graphics Frame Buffer Compress/Encrypt Network Decrypt/Decompress Applications run on native graphics HW Decrypt Apply Keyboard & Mouse events Encrypt Capture Keyboard & Mouse events The RGS Receiver requested an update as soon as it finished processing the previous update. If the blade workstation RGS Sender determines that the image has changed, an update is sent. Beginning at RGS 5.1.3, HP implemented a user-settable feature that allows multiple image update requests to be outstanding at any given time. The Receiver property Rgreceiver.MaxImageUpdateRequests can be used to specify how many Receiver image update requests are outstanding. For example, if this property is set to 4, the Receiver can have up to 4 image update requests outstanding at any give time. The Rgreceiver.MaxImageUpdateRequests property enables performance optimization in high-latency network environments. For more information on this property, refer to Chapter 8, "RGS Properties", in the HP RGS User Guide. NOTE: The RGS Sender can be constrained to a maximum update frequency (see the HP RGS User Guide). This constraint usually results in less network traffic, but may cause unacceptable interactivity. It is very important that the bandwidth used by RGS for a particular monitor configuration and set of applications be characterized before full deployment. Except in certain cases (for example, high-resolution video, or complex 3D object manipulation), the time needed to capture, compress, and encrypt the blade desktop (by the RGS Sender), and the time needed to decrypt, decompress, and display the desktop (by the RGS Receiver) is small. The largest single contributor to RGS interactivity is the time needed to make a complete round trip across the network between the RGS Sender and Receiver. This time is closely approximated by the roundtrip (RT) latency for an IP packet as measured by the ping command (in a lightly loaded network) or the bing command (in a more heavily loaded network). Therefore, to maximize RGS interactivity, the goal should be to minimize the roundtrip network latency. Table 5-1 assumes that the RGS Sender and Receiver require zero time to operate. It is simply an inverse relationship between the best possible screen update frame rate and the network round-trip latency, and is based on the property Rgreceiver.MaxImageUpdateRequests=1. For higher values of this property, the frame rate may improve. Table 5-1 RGS frame rate for different network latencies when Rgreceiver.MaxImageUpdateRequests=1 Roundtrip Latency Best Possible Frame Rate (in frames per second) 1 ms 1000 5 ms 200 17 ms 20 ms 33 ms 67 ms 100 ms 60 50 30 15 10 Network Planning 24