Lantronix Spider KVM Over IP Switch Spider App. Note - Page 7

Transmission Encoding

Page 7 highlights

The Spider Network: A Guide to Maximizing Distributed KVM Installations become large enough to cause mouse and cursor tracking problems or, when using the PS/2 mouse connection option, asynchronous data transfer. According to the simulation, network bandwidth averages 650 kbps per session when there is a vigorous amount of user activity. This means that clients using DSL or cable modem connections should not experience compression issues. However, Spiders that connect to DSL or a cable modem will be limited in the number of possible external connections. The upstream rate needs to be considered along with the faster downstream connection rate advertised for the DSL or cable modem service. This could be a particular disadvantage if multiple Spiders, accessed by multiple users, are connected to DSL or a cable modem. While the bandwidth dictates the cost of service for most Wide Area Network (WAN) connections, the availability of upstream bandwidth can alleviate simultaneous session constraints. If the target screen is changing rapidly enough to saturate the upstream connection, cursor lag at the client may result. Wireless network users are particularly susceptible to multiple TCP retries due to congestion downstream from the Spider. Cellular data networks, including UMTS (Universal Mobile Telecommunications Systems) and EVDO (Evolution-Data Optimized), can also have significant latency issues. If your Spider is configured similar to the simulation, the network may experience degraded performance. Hence, if smooth cursor feedback is required, the above sessions may benefit from high-compression settings. To change those default settings in firmware v2.1, navigate to Interfaces  KVM Console Settings  Transmission Encoding You can also make changes to the compression settings during a session by navigating to Options  Encoding  Compression. More compression means less data is sent over the network. Static Images In many instances, a client initiates a Spider session to run scripts or copy files, which results in minimal screen updates or a static image. A Spider with a static image should take up zero or very little network bandwidth; therefore a large number of sessions are possible. For example, a blinking cursor with no other activity should use no more than several hundred bytes per second. If the lower right corner of the remote console window indicates significant data coming from the Spider, then click the "Auto-Adjust" button once or twice to eliminate it. If the activity levels do not subside, you can navigate the menu (firmware v2.1) to Interfaces  Video  Noise Filter, and select "Large". Display Settings It is possible to change the display settings in order to reduce the amount of data sent in each update, but it is not necessarily obvious which settings will affect the desired change. For example, changing the encoded color depth of the client's display or scaling the remote console window, will not affect the amount of data sent from the Spider and will degrade the image on the client. A client workstation that has six Spiders logged-in, each RC window scaled to 25% is the same as six individual users logged into six Spiders with full-size RC windows. However, in the former scenario the user will only be capable of interacting with and therefore receiving screen updates from one Spider at a time. The easiest way to reduce the bandwidth requirements is to minimize the target server's screen resolution. While this simulation used a resolution of 1280x1024 pixels to show The Spider-Based Network: A Guide to Maximizing Distributed KVM Installations 7 The information contained in this document is protected by copyright. Information is subject to change without notice. Lantronix, Inc. makes no claim regarding the accuracy of this competitive information and specifically disclaims any and all liability for loss or damages of any kind resulting from decisions made or actions taken by any party based on this information.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

The Spider Network: A Guide to Maximizing Distributed KVM Installations
The Spider-Based Network: A Guide to Maximizing Distributed KVM Installations
7
The information contained in this document is protected by copyright. Information is subject to change without notice.
Lantronix, Inc. makes no claim regarding the accuracy of this competitive information and specifically disclaims any and all
liability for loss or damages of any kind resulting from decisions made or actions taken by any party based on this
information.
become large enough to cause mouse and cursor tracking problems or, when using the
PS/2 mouse connection option, asynchronous data transfer.
According to the simulation, network bandwidth averages 650 kbps per session when
there is a vigorous amount of user activity. This means that clients using DSL or cable
modem connections should not experience compression issues. However, Spiders that
connect to DSL or a cable modem will be limited in the number of possible external
connections. The upstream rate needs to be considered along with the faster downstream
connection rate advertised for the DSL or cable modem service. This could be a
particular disadvantage if multiple Spiders, accessed by multiple users, are connected to
DSL or a cable modem. While the bandwidth dictates the cost of service for most Wide
Area Network (WAN) connections, the availability of upstream bandwidth can alleviate
simultaneous session constraints.
If the target screen is changing rapidly enough to saturate the upstream connection, cursor
lag at the client may result. Wireless network users are particularly susceptible to
multiple TCP retries due to congestion downstream from
the Spider. Cellular data
networks, including UMTS (Universal Mobile Telecommunications Systems) and EV-
DO (Evolution-Data Optimized), can also have significant latency issues.
If your Spider is configured similar to the simulation, the network may experience
degraded performance. Hence, if smooth cursor feedback is required, the above sessions
may benefit from high-compression settings.
To change those default settings in firmware v2.1, navigate to Interfaces
KVM
Console Settings
Transmission Encoding
You can also make changes to the compression settings during a session by
navigating to Options
Encoding
Compression.
More compression means less
data is sent over the network.
Static Images
In many instances, a client initiates a Spider session to run scripts or copy files, which
results in minimal screen updates or a static image. A Spider with a static image should
take up zero or very little network bandwidth; therefore a large number of sessions are
possible. For example, a blinking cursor with no other activity should use no more than
several hundred bytes per second. If the lower right corner of the remote console window
indicates significant data coming from the Spider, then click the
Auto-Adjust
button
once or twice to eliminate it.
If the activity levels do not subside, you can navigate the
menu (firmware v2.1) to Interfaces
Video
Noise Filter, and select “Large”.
Display Settings
It is possible to change the display settings in order to reduce the amount of data sent in
each update, but it is not necessarily obvious which settings will affect the desired
change. For example, changing the encoded color depth of th
e client’s display
or scaling
the remote console window, will not affect the amount of data sent from the Spider and
will degrade the image on the client. A client workstation that has six Spiders logged-in,
each RC window scaled to 25% is the same as six individual users logged into six Spiders
with full-size RC windows.
However, in the former scenario the user will only be
capable of interacting with and therefore receiving screen updates from one Spider at a
time.
The easiest way to reduce the bandwidth requirements is to minimize the targ
et server’s
screen resolution. While this simulation used a resolution of 1280x1024 pixels to show