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 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 ProcessingAdobe Pthotoshop 3.0 Web BrousingNetscape Communicator 4.02 Word ProcessingAdobe Frame Maker 5.5 PIMPersonal Information Management tools Streaming VideoMPEG-II decoder and live video player 3-D CamesQuake from id Software

Performance of SLIM components BenchmarkResult Respnse time over a 100Mbps switched IF550us x11perf/Xmark x11perf/Xmark93 – no display data sent on IF7.505 Protocol CommandStartup CostCost per Pixel SET5000ns270ns BITMAP11080ns22ns FILL5000ns2ns COPY5000ns10ns CSCS(16bits/pixel)24000ms205ns CSCS(12bits/pixel)24000ms193ns CSCS(8bits/pixel)24000ms178ns CSCS(5bits/pixel)24000ms150ns

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 Human input rates << monitor refresh rates

Sizes of Pixel Updates Updates affect small fraction of display

SLIM Protocol Efficiency

Display Update Transmission Sizes Compressed display updates are small 100Mbps transmission takes a few ms

Console Protocol Processing Cost Response time is below perception threshold

Display Bandwidth Requirements BW is very low SLIM & X are competitive

Effects of Bandwidth Constraints

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 At least 10x sharing before QoS is unacceptable

Sharing ther Interconnection Fabric

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 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)OK 480x360: 28-34Hz (20-24Mbps)Playable Translation cost dominates “ 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