To gain optimal network performance for Sun Ray 3 Series Clients, enable link-level flow control (IEEE 802.3 link pause) on the network switches to which the clients are connected.
If the Sun Ray server does not have enough virtual memory available, the X Window server instance does not start and the user experiences a slow response. When virtual memory is insufficient, the Sun Ray server performs excessive disk swapping.
To determine whether the Sun Ray server is swapping to disk excessively, use the vmstat command:
# vmstat 5
If excessive swapping is occurring, the system might be undersized or overutilized.
The solution is to add more memory or increase the size of the swap partition.
Many graphics-intensive screensaver programs consume large amounts of CPU, memory, and network bandwidth. To avoid excessive resource consumption on the Sun Ray servers, disable them.
Some network switches do not work well with Sun Ray Clients when the server-side connection is configured to run at 1 Gbps. Because the Sun Ray Clients run at 100 Mbps and the data is sent from the X Windows server in periodic bursts, these switches are required to buffer a certain amount of data. This situation can happen even when the average data rate from the X server is well under 100 Mbps.
The X server is programmed in such a way that a certain allowed amount of data is sent at tick intervals. The original implementation had 50 ticks per second. The X server is allowed to send at a certain specific rate granted by the Sun Ray Client.
For example, if the Sun Ray Client's grant is 40 Mbps, it can send 5 MB per second in bursts that are sent every 1/50th of a second. This means that at each tick, the server can send 100 KB of data at a rate of 1 Gbps. This rate would cause a queue buildup in the switch of close to 100 KB, which would then drain out at 100 Mbps over the next 1/50th of a second.
The first action to mitigate this type of issue is to increase the number of ticks per second to 100 per second from 50. Thus, in the example above, the X server would send 50 KB every 10 ms rather than 100 KB every 20 ms. This setting would improve the situation considerably, but the problem would still remain. The 100 ticks per second rate was chosen because it corresponded to the normal resolution of the timer in the Solaris and Linux software.
To increase the number of ticks per second beyond 100, the operating system's timer must also be increased. On the Solaris platform, use the following procedure.
Open the /etc/system file.
Add the following command:
set hires_tick=1
Save and close the file.
Reboot the system.
The hires_tick=1 setting increases the
system timer resolution to 1000 ticks per second.
Because the X server code uses the system setting, the X server's bursts of data now use the same value, 1000 ticks = 1 second, that is, 1 tick = 1 ms. In the example, using the new tick duration results in the X server sending 5 KB of data every 1 ms.
Because the change to the tick duration decreases the amount of buffering required on the network switch, the performance of the Sun Ray Clients improve.
The Sun Ray Clients are designed to power on and be fully operational in a very short time--typically less than 10 seconds.
Some network switches have initial configurations that can cause this start-up time to be considerably longer, often taking 30 seconds or longer to achieve a fully working state. Longer start-on times typically are due to the configuration of the Ethernet switch that implements capabilities not needed in the Sun Ray environment. The most common of these capabilities is enabling the spanning tree protocol, which is designed to detect and compensate for loops in the network.
In the Sun Ray environment, the spanning tree protocol should be disabled or deferred for ports connected directly to the Sun Ray Clients. Some manufacturers support a feature that immediately puts a port into the spanning tree forwarding mode. This feature is an acceptable alternative to disabling the spanning tree protocol on the port.
If the spanning tree protocol is disabled and the start-up time is still excessive, contact the switch manufacturer to determine if there are other features or proprietary protocols that might be interfering with the Sun Ray Client. Some switches might have features designed into the switch that cannot be changed; if this is the case, then it may not be possible to reduce the start-up time.
In situations where network load or packet loss is too high, network cables or switch equipment might be defective in very rare cases.
Verify that network connections are 100F.
Use utcapture to assess network latency and packet loss.
As latency and packet loss increase, performance suffers.
Some applications, such as intensive 3-D visual simulations, might run very slowly on a Sun Ray client.
Applications that use double-buffering such as pseudo-stereo viewers and applications that use high-frequency dynamic color table flips on 8-bit visual displays might not show the proper result. Turn off antialiasing to save screen resources.
Install interactive applications such as web browsers and StarOffice(TM) and PC interoperability tools such as Citrix and Sun Secure Global Desktop (SGD) software on the Sun Ray server. The applications benefit from faster transport of commands to the Sun Rays X server and network traffic is reduced.
If an application can be configured to use shared memory instead of DGA or OpenGL(R), using shared memory results in improved performance.