HP dc73 HP Blade Workstation Solution Planning Guide - Page 34

Characterizing RGS bandwidth consumption, Application, Bandwidth consumption

Page 34 highlights

5-5-2 Characterizing RGS bandwidth consumption To help ensure interactive performance, RGS is designed to react quickly to events. The client RGS Receiver requests an update as soon as it finishes processing the previous request. If the blade workstation RGS Sender determines that the image has changed, an update is sent. This results in an interactive session that can use a significant amount of bandwidth. The RGS Sender can be constrained at the blade to a maximum update frequency (see the HP Remote Graphics Software User Guide). This constraint usually results in less network traffic but may cause unacceptable display performance. It is imperative that the bandwidth used by RGS for a particular monitor configuration and set of applications be characterized before full deployment. There are several ways to measure RGS bandwidth consumption. Bandwidth consumed is most accurately measured at the RGS Receiver using Ethereal to capture packets or by using the Performance Logs and Alerts snap-in for the Microsoft Windows Management Console to monitor the total number of bytes moving through the receiver NIC. Figure 5-10 shows a screen shot of the Performance snap-in. Figure 5-10 Performance monitoring To start the performance snap-in, select Start>Run, and enter perfmon in the text box. The typical bandwidth consumption for RGS running various applications is shown in Table 5-3. Table 5-3 Typical bandwidth consumption for a 100 Mb/s network Application Microsoft Office applications Financial Trader-Four screens Streaming Video-800x600 24fps full color Bandwidth consumption 1-1.5 Mb/s 2-3 Mb/s 9 Mb/s Average bandwidth consumption data is not sufficient to determine the overall bandwidth requirements for a scaled-out implementation. Peak bandwidth is also important. However, sizing for peak bandwidth utilization on all systems would be inefficient. Sizing for average utilization plus two standard deviations should be adequate. Network Planning 34

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35

Network Planning 34
5-5-2 Characterizing RGS bandwidth consumption
To help ensure interactive performance, RGS is designed to react quickly to events. The client RGS Receiver
requests an update as soon as it finishes processing the previous request. If the blade workstation RGS Sender
determines that the image has changed, an update is sent. This results in an interactive session that can use a
significant amount of bandwidth. The RGS Sender can be constrained at the blade to a maximum update
frequency (see the
HP Remote Graphics Software User Guide
). This constraint usually results in less network traffic
but may cause unacceptable display performance. It is imperative that the bandwidth used by RGS for a
particular monitor configuration and set of applications be characterized before full deployment.
There are several ways to measure RGS bandwidth consumption. Bandwidth consumed is most accurately
measured at the RGS Receiver using Ethereal to capture packets or by using the Performance Logs and Alerts
snap-in for the Microsoft Windows Management Console to monitor the total number of bytes moving through the
receiver NIC. Figure 5-10 shows a screen shot of the Performance snap-in.
Figure 5-10
Performance monitoring
To start the performance snap-in, select
Start>Run
, and enter
perfmon
in the text box. The typical bandwidth
consumption for RGS running various applications is shown in Table 5-3.
Table 5-3
Typical bandwidth consumption for a 100 Mb/s network
Application
Bandwidth consumption
Microsoft Office applications
1–1.5 Mb/s
Financial Trader—Four screens
2–3 Mb/s
Streaming Video—800x600 24fps full color
9 Mb/s
Average bandwidth consumption data is not sufficient to determine the overall bandwidth requirements for a
scaled-out implementation. Peak bandwidth is also important. However, sizing for peak bandwidth utilization on
all systems would be inefficient. Sizing for average utilization plus two standard deviations should be adequate.