Transcript The interactive performance of SLIM: a stateless thin

The interactive performance of SLIM:
a stateless thin-client architecture
Brian K. Schmidt and Monica S. Lam
Stanford University
J. Duane Northcutt
Sun Microsystems Laboratories
Introduction
Computing environment timeline
1970’s: time-sharing on mainframes
 1980’s: networks of workstations
=> return to time-sharing (total cost improve)

Thin-client computing


(modern version of the old time-sharing)
Plan 9 project ( plan9.bell-labs.com )
X terminals, Win Terms, Java Station, other
 Display protocol ( X, ICA, RDP)
 High-level, API-specific protocols

Thinnest possible clients are dumb terminals
 MaxStation (MaxSpeed Corporation, 1024x768 8bit 64Mbps)
 VNC viewer
Introduction
(con’t)
SLIM:
a stateless thin-client architecture
SLIM:
a stateless thin-client architecture (con’t)
SLIM : Stateless, Low-level Interface Machine
Statelessness
Low-level interface
A fixed-function appliance
Contains no software
The SLIM architecture and implementation
The SLIM protocol

Simple pixel encodings for display
SET
Set literal pixel values
BITMAP 1’ s = foreground color, 0’s = background color
FILL
Fill with solid color
COPY
Copy region on screen
CSCS
Color Space Convert from YUV to RGB and Scale



Keyboard and mouse state messages
Simple error recovery
Implemented on top of UDP/IP
The SLIM architecture and implementation(con’t)
Console is stateless, dumb frame buffer



100MHz microSPARC IIep and 2MB
24-bit 1280x1024 graphics controller
10/100Mbps ethernet interface
Interconnection Fabric (IF)

Switched, full-duplex 100Mbps Ethernet
Server software


Daemons for authentication, remote peripheral
management, I/O re-direction
Device driver and library interfaces to protocol
Evaluation methodology
Basic performance of each component
Characterization of GUI applications
Analysis of sharing’s impact on performance
Explore limit of capabilities using multimedia applications
Image Processing Adobe Pthotoshop 3.0
Web Brousing
Netscape Communicator 4.02
Word Processing
Adobe Frame Maker 5.5
PIM
Personal Information Management tools
Streaming Video
MPEG-II decoder and live video player
3-D Cames
Quake from id Software
Performance of SLIM components
Benchmark
Result
Respnse time over a 100Mbps switched IF
550us
x11perf/Xmark93
3.834
x11perf/Xmark93 – no display data sent on IF
7.505
Protocol Command
SET
Startup Cost
Cost per Pixel
5000ns
270ns
11080ns
22ns
FILL
5000ns
2ns
COPY
5000ns
10ns
CSCS(16bits/pixel)
24000ms
205ns
CSCS(12bits/pixel)
24000ms
193ns
CSCS(8bits/pixel)
24000ms
178ns
CSCS(5bits/pixel)
24000ms
150ns
BITMAP
Characterization of interactive applicaiotns
Benchmarks are commonly used GUI apps
Analyze characteristics of human interface
Real-life data
Include analysis of network component
User studies characterize interactive performance

50 people performed normal work with app’s

Logged protocol commands, resource usage
Human Interaction Rates
Input Events per Second
1000
100
Photoshop
Netscape
Frame Maker
PIM Applications
10
1
0.1
Human input rates <<
monitor refresh rates
0.01
0.001
0
10
20
30
40
50
60
70
80
Cumulative Frequency (%)
90 100
Sizes of Pixel Updates
Pixels Changed per Input Event
10000000
1000000
Photoshop
Netscape
Frame Maker
PIM Applications
100000
10000
1000
Updates affect small
fraction of display
100
10
1
0
10 20 30 40 50 60 70 80 90 100
Cumulative Frequency (%)
SLIM Protocol Efficiency
80
COPY
BITMAP
FILL
SET
60
40
20
Photoshop Netscape
Frame
Maker
SLIM
Raw
SLIM
Raw
SLIM
Raw
SLIM
0
Raw
Bytes Transmitted (%)
100
PIM
Applications
Display Update Transmission Sizes
Bytes Transmitted per i
Input Event
1000000
Photoshop
Netscape
Frame Maker
PIM Applications
100000
10000
1000
100
10
Compressed display updates are small
100Mbps transmission takes a few ms
1
0
10
20 30
40 50 60
70 80
90 100
Cumulative Frequency (%)
Console Protocol Processing Cost
10000
Response time is below
perception threshold
Service Time per i
Input Event (ms)
1000
Photoshop
Netscape
Frame Maker
PIM Applications
100
10
1
0.1
0
10
20
30
40
50
60
70
80
90 100
Cumulative Frequency (%)
Display Bandwidth Requirements
Average Bandwidth (Mbps)
10
Raw Pixels
SLIM
X
1
0.1
BW is very low
SLIM & X are competitive
0.01
Photoshop Netscape
Frame
Maker
PIM
Applications
Effects of Bandwidth Constraints
Added Packet Delay
Relative to 100Mbps (ms) i
1000
56Kbps
64Kbps
128Kbps
1Mbps
1.5Mbps
2Mbps
10Mbps
100
10
1
0.1
0.01
0
10
20
30
40
50
60
70
80
Cumulative Frequency (%)
90
100
Interactive Performance Analysis Summary
Requirements for transmitting display updates with
SLIM proto are modest

Updates are typically < 10Hz and < 10KB
Remote display is indistinguishable from console
local to server


Transmission delay & console service time < 50ms
Human tolerance limit: 150ms
Bandwidth requirements are modest



Very low average BW: < 1 Mbps
Competitive with high-level X protocol
Can easily use over DSL to the home
Multi-User Interactive Performance
Analysis constraints



Measure user experience
Function when system is in temporary overload
Can’t instrument every application
Our approach


Yardstick app to quantify response time
“Load generator” plays back resource profiles
Yardsticks are very demanding


CPU: 30ms service time, 150ms “think time”
Network: 64B command packet, 1200B response, 150ms
“think time”
Sharing ther Server Processor
Event Processing Latency Over
30ms for Yardstick (avg ms)
10000
Photoshop
Netscape
Frame Maker
PIM Applications
1000
100
At least 10x sharing before
QoS is unacceptable
10
1
0
5
10 15 20 25 30 35 40 45 50
Active Users
Sharing ther Interconnection Fabric
Roundtrip Packet Delays for i
Yardstick Application (ms)
60
50
Photoshop
Netscape
Frame Maker
PIM Applications
40
30
20
10
0
1
10
100
Active Users
1000
Summary of Sharing Analysis
Substantial processor sharing is possible
with no noticeable degradation
Network is not the critical resource
Real-world experience: huge savings in
administration cost
Multimedia Applications
High update rates not correlated to input
Typically render directly to frame buffer


Porting cost to use SLIM protocol directly
Overhead to translate to SLIM protocol
Very high bandwidth
Video Applications
Resolution
Format
Performance
Bottleneck
ShowMeTV
720x480
MPEG-II
20Hz
Decompression
and disk I/O
Live TV
640x240
JPEG
16-20Hz
Decompression
Performance is the same
Bandwidth is 20-40Mbps
Simulate 4-way parallelism: 25-28Hz (59-66Mbps)
3D-Rendered Games
Quake from id Software

Good news: we got the source code
Bad news: we only got pixel display code

YUV translation based on 8-bit RGB colormap

Performance



640x480: 18-21Hz (22-26Mbps)
480x360: 28-34Hz (20-24Mbps)
Translation cost dominates
OK
Playable
“Parallelize”

4 320x240: 37-40Hz (46-50Mbps)
Can’t shoot
fast enough!
Related work
X window system
Windows-based terminals

Citrix ICA protocol , Microsoft RDP protocol
VNC
other


MaxStation
Desk Area Network (DAN)
Conclusions and future work
evaluation methodology to characterize
interactive performance of modern systems.
characterizing the I/O properties of real-world,
interactive applications executing
actual implementation of the SLIM systerm
necessary to provide interactive performance
guarantees in a shared environment
move to a model where there are a large number
of users sharing a large number of servers