TEST REPORT

AUGUST 2006

PC vs. thin client performance in typical office

application scenarios

Executive summary KEY FINDINGS

Intel Corporation (Intel) commissioned Principled
Technologies (PT) to compare the performance of PCs z On 4 different scenarios involving up to 5
and two types of thin clients on test networks with varying systems simultaneously running the same
numbers of active clients, each running the same typical common office tasks, PCs consistently and
office application tasks. We measured the response time dramatically outperformed both Sun Ray 2
users would experience on each system while performing and Wyse Winterm 5150SE thin clients in
common office functions with leading office applications. the multi-client tests.
We tested the following representative client platforms:
z PC performance stayed consistent on most
• PC: Dell OptiPlex 210L PCs, basic managed PC tests as we added simultaneously active
desktops running Windows XP Professional clients, while the performance of both types
• Sun thin client: Sun Microsystems Sun Ray 2 of thin clients plunged as we increased the
thin client running Sun Ray proprietary software number of active clients.
• Wyse thin client: Wyse Winterm 5150SE, Linux- z With 5 simultaneously active users, PCs
based thin clients running Wyse Linux V6 delivered basically the same response time
on each system, while different thin client
We set up test networks that supported five of each type of users often experienced dramatically
client and were otherwise as identical as possible given different response times.
the demands of the thin clients. Each network used a
standard file server, an HP ProLiant DL360 3.4 MHz server with an Intel Xeon processor and Microsoft Windows
Server 2003 Enterprise Edition. Where necessary, this server also ran the software to support the thin clients. The
Sun Ray 2 test network additionally required a Sun Fire V240 server, which translates the proprietary Sun thin
client protocol into RDP for the Windows Server. We installed Microsoft Office 2003 and Adobe Acrobat 7.0
Standard on each platform, locally on the PC and on the shared server for the thin clients. To make the
comparison as apples-to-apples as reasonably possible, in all but one case, in which storing a file locally on the
PCs seemed more like what real users would do, we stored the test data files on the file server.

We focused on operations that would typically make users wait, because those operations by their nature tend to
be the ones on which users would most appreciate performance improvements. We tested the following four
scenarios, two with a single active task and two with multiple tasks running at the same time:

• Single task scenarios

o Calculating subtotals in Microsoft Office Excel 2003
o Compressing a PDF from within Adobe Acrobat 7.0 Standard
• Multitasking scenarios
o Changing the view in a Microsoft Office PowerPoint 2003 presentation while compressing a
folder in Windows Explorer
o Opening large XML files in Microsoft Office Word 2003 and Microsoft Office Excel 2003

We tested each scenario first on a single client with exclusive access to the file server and then repeated the
scenario with 2, 3, 4, and 5 clients running concurrently. We collected the response time on each of the
participating clients. Our results graphs and tables show the effect the load of additional clients had on response
time. Figure 1 illustrates the results for a simple single-task scenario, calculating Excel subtotals.

As you can see, the performance of the PCs stayed the same as we added more simultaneously active users. By
being able to do the computation work locally, the PCs did not have to rely on the file server for more than
supplying the data.
The thin clients, by contrast, delivered dramatically worse response time as more clients worked at the same time,
with performance dipping to below 20 percent of what it was with a single active client. This performance dip
occurred because all the active thin clients had to rely on the single shared server to not only supply the data files
but also do the computation work.

Normalized Excel subtotals task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80

Dell OptiPlex 210L

0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5
Number of simultaneously active clients

Figure 1: Results for the Excel subtotals task for all three client platforms. All results are normalized to the one-client PC
result. Higher comparative ratings are better.

As Figure 1 also shows, the different types of clients delivered similar response time with only a single client
running the test. In this case, each thin client had the server acting as essentially a dedicated PC for that client, so
it is no surprise that the PCs and the thin clients performed about the same. The moment we added a second
active client, however, thin client performance plunged, because those two clients then had to share the server.

In our tests, all the clients performed the same task at the same time, though each had its own copies of all data
files. Though typically people are not doing exactly the same thing at exactly the same time, most networks with a
similarly capable server would be supporting a lot more than a mere 5 simultaneous users. Further, during normal
work hours a great many of those users would be working on different tasks at the same time. Our test cases are
thus probably less demanding on the server than real user networks.

In the following sections we discuss our test application scenarios (Application scenarios), examine the results of
our tests (Test results and analysis), and provide detailed information about how we actually performed the tests
(Test methodology). In the appendices, we present the configurations of the test systems, explain how to
manually execute the application functions in our scenarios, and discuss some issues in the development of the
test scripts.

Principled Technologies, Inc.: PC vs. thin client performance in typical 2

office application scenarios
Application scenarios
To gauge performance on typical office applications, we developed a set of 4 test scenarios. We focused primarily
on processor-intensive operations that often force users to wait, because users are likely to appreciate
performance improvements on such operations. Each scenario contains 1 to 3 timed common business functions.
We created 2 scenarios that include a single task and 2 that include multiple tasks running at the same time.
Single task scenario: Calculating subtotals in Microsoft Excel
In our first scenario, Carson, the head of sales for a specialty retailer, is reviewing a sales report in Excel and
wants to get totals for each of her associates. Her spreadsheet is a 1.79MB Excel file on the file server. The
worksheet has 11,511 rows of sales data in 11 columns. She selects Data/Subtotals from the Excel menu. The
Subtotals dialog displays, and she fills in information on the subtotal she needs. She presses Enter and waits for
the recalculation to complete.

We timed this task from the point she presses Enter until the Excel status bar displays Ready at the end of the
calculation.
Single task scenario: Compressing a PDF from within Adobe Acrobat
In our second scenario, Parker, the assistant to a marketing director, has a 4.01MB PDF of a white paper that he
wants to put on the company’s Web site. He plans to save download time for customers by reducing the files size.
He has the file open in Adobe Acrobat 7.0 Standard and selects File/Reduce File Size. When the Reduce File
Size dialog displays, Parker changes the Make Compatible with: selection to Acrobat 7.0 or later and presses OK.
In the Save As dialog, he enters compressed.pdf as the file name and presses Save. Acrobat compresses the file
and then displays a Conversion Warning saying that the PDF contained image masks that were not down-
sampled. Parker presses OK, and Acrobat displays his compressed PDF.

We timed this task from the point he presses OK in the Reduce File Size dialog until the Conversion Warning
appears at the end of the compression.
Multitasking scenario: Changing the view in a Microsoft PowerPoint presentation while
compressing a folder in Windows Explorer
In the third scenario, Maya, a project manager, has a 265MB folder in her My Documents folder that she wants to
compress and copy to an FTP site for a customer. (We stored this folder locally on the PCs, because a typical PC
user would likely work on such a large amount of data locally. We necessarily stored the folder on the file server
for the thin clients.) She locates the folder in Windows Explorer, right-clicks it, and selects Send to/Compressed
(zipped) Folder from the drop-down menu that displays. She continues working while Windows Explorer
compresses the file. Her next task is to edit a PowerPoint deck for an upcoming customer presentation. The
PowerPoint file is on the file server. While the compression is still running, she opens the 30.4MB, 36-slide
PowerPoint deck and selects View\Slide Sorter so she can find the slide she wants. She then must wait for the
slides to display. She will later copy the 195MB compressed (zipped) folder to the FTP site.

We timed 3 tasks:

• the Windows Explorer task, from the time Maya starts the compression until the Compressing dialog
disappears
• the PowerPoint open task, from the time she clicks the desktop shortcut to open the file until PowerPoint
displays all the slide snapshot on the left
• the PowerPoint change view task, from the time she selects View\Slide Sorter until PowerPoint displays
all the slide images.
Multitasking scenario: Opening large XML files in Microsoft Word and Microsoft Excel
In this scenario, Akhil, a financial analyst, wants to update an 11MB Word XML file with data from a 29.9MB Excel
spreadsheet that is also in XML format. He opens Windows Explorer and locates the file server folder that holds
the files. He selects both files, presses Enter, and waits for the files to display.

We timed 2 tasks:

Principled Technologies, Inc.: PC vs. thin client performance in typical 3

office application scenarios
 • the Excel open, from when he presses Enter until Excel opens the file and displays Ready in its status bar
• the Word open, from when he presses Enter until Word opens the document and updates the page count
in its status bar

For more details on how we executed and measured these scenarios, our specific test functions, and the files the
scenarios use, see Appendix B.

Test results and analysis

In this section we examine the results of the tests run with the application scripts we created. We ran each
scenario 5 times on each of the 3 test platforms for each client count (1 active client, 2 active clients, and so on up
to 5 active clients).

For each of those results sets, we present a single time: the mean response time, in seconds, of all the
participating clients in one of the five runs of the scenario. We call that run the representative run.

We used a different process to select the representative run for single-task and multitasking scenarios. For single
task scenarios, we calculated the mean response time for all the clients participating in each test run of a script.
That process yielded one result for each of the five runs. We consider the representative run to be the one with
the median of those results.

For multitasking scenarios, we had to consider the results of all the tasks we timed. Because the foreground task
is the one on which, by definition, users are waiting, we used the foreground task to select a representative run.
So, as we did with the single-task scripts, we calculated the mean response time on the foreground task for all the
clients participating in each test run of a multitasking script. That process yielded one foreground result for each of
the five runs. We consider the representative run to be the one with the median of those results. We then
calculated the mean response time of each other task for all the clients on that run, and we report those results.

In the following sub-sections we explore these results in more detail. Because our goals were to compare how
well the thin clients fared against the PCs and to show how well each type of client performed as we added more
simultaneously active clients, we normalized all comparisons to the performance of the tests with a single active
PC. The result for a run with one active PC is thus always 1.00, because that run is the comparison basis. Results
higher than 1.00 indicate how much faster a given client type ran with a particular client count and script than a
single active PC with the same script. Results lower than 1.00 indicate how much slower a given client type ran
with a particular client count and script than a single active PC with the same script. Because of the normalization,
higher result numbers are better. For example, a result of 0.80 for 2 active clients of type X would mean those
clients completed the script 20 percent slower than a single PC running the same script.

We present the results for each task in each scenario in both tabular and graphical form. Each results table shows
the results of each type of client with 1, 2, 3, 4, and 5 simultaneously active clients. Each graph shows how each
type of client's response time changed as we moved from 1 active client to 5 active clients.

As all the results show, with just 5 clients simultaneously running the same script, the PC clients always
dramatically outperformed the thin clients.

For more details on each scenario, see the Application scenarios section and Appendix B.
Single task scenario: Calculating subtotals in Microsoft Excel
Figure 2 shows the response times for each of the client platforms running this Excel subtotals task. Though all
clients of all types were getting the test file from the file server, the PCs were able to perform the computation
locally, while the thin clients had to rely on sharing the server's processor to do the same work. The server was
able to handle the file requests from the PCs without slowing under load, but having to perform the computations
for the thin clients caused the server to slow as we added more clients.

The result, as you can see, is that PC performance held steady as we added clients, while with 5 active clients the
performance of both types of thin clients fell to about 20 percent that of the PCs. Consequently, PC users would

Principled Technologies, Inc.: PC vs. thin client performance in typical 4

office application scenarios
 Normalized Excel subtotals task response times
Response times normalized to the one-

1.00
client run of the Dell Optiplex 210L

0.80

Dell OptiPlex 210L

0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5

Number of simultaneously active clients

Figure 2: Results for the Excel subtotals task for all three client platforms. All results are normalized to the one-client PC result.
Higher comparative ratings are better.

have experienced the same response time as we added users, while thin client users would have experienced
dramatically worse response time with only 5 of them running the test.

Figure 3 details the response times for each of the three client platforms running this task. The performance
results in the left section of the table show the mean response time, in seconds, of all the participating clients in
each run of the test. Lower performance results are better. The center column shows the number of
simultaneously active clients in the test whose results that row provides. The comparative ratings in the right
section of the table show the response time normalized to the result with 1 active PC client. Higher comparative
ratings are better.

PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING

PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

12.9 13.2 13.1 1 1.00 0.98 0.98

12.8 30.2 29.7 2 1.01 0.43 0.43
12.7 45.5 41.9 3 1.02 0.28 0.31
12.9 58.3 57.3 4 1.00 0.22 0.23
12.8 68.1 67.9 5 1.01 0.19 0.19
Figure 3: Results for the Excel subtotals task for all three client platforms. All results are normalized to the one-client PC
result. Higher comparative ratings are better.

As Figure 3 also shows, the percentage differences in performance between PCs and thin clients translate into
time differences users most definitely notice. With a single client active, all the clients completed the task in
roughly 13 seconds. With 5 clients doing the same test, PC performance stayed basically the same, while thin
client performance went to about 68 seconds--an increase of 55 seconds, or nearly a minute, in response time.

Principled Technologies, Inc.: PC vs. thin client performance in typical 5

office application scenarios
Single task scenario: Compressing a PDF from within Adobe Acrobat
Figure 4 and 5 show the performance for each of the three types of clients on this Acrobat PDF compression task.

PC response time again held basically steady as we added clients, with the response time for 5 simultaneously
active clients at worst 4 percent lower than the response time with a single client. Both thin clients, by contrast,
dropped greatly as we added clients, going to 68 percent (Sun Ray 2; 67 percent for Wyse Winterm 5150SE) as
fast with only 2 clients active and dropping to 30 percent (Sun Ray 2; 29 percent for Wyse Winterm 5150SE) as
fast with 5 simultaneously active clients.

Normalized Acrobat compress PDF task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80
Dell OptiPlex 210L

0.60 Sun Ray 2

Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5

Number of simultaneously active clients

Figure 4: Results for the Acrobat compress PDF task for all three client platforms. All results are normalized to the one-
client PC result. Higher comparative ratings are better.
As the one-client results in Figure 5 show, the thin clients were actually a tiny bit, 1 to 3 percent, faster with only
one client active. The reason for this slight performance edge is that in the one-client test each thin client basically
has the full power of the server available to it.

PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING

PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

16.1 16.0 15.6 1 1.00 1.01 1.03

16.4 23.8 24.0 2 0.98 0.68 0.67
16.5 33.0 33.1 3 0.98 0.49 0.49
16.6 43.7 44.3 4 0.97 0.37 0.36
16.7 54.0 55.1 5 0.96 0.30 0.29
Figure 5: Results for the Acrobat compress PDF task for all three client platforms. All results are normalized to the 1-
client PC result. Higher comparative ratings are better.
In this scenario, the PCs again used the server purely to hold the files; both the initial and the compressed files
were on the server. The PCs performed the compression locally. The thin clients, by contrast, had to rely on the

Principled Technologies, Inc.: PC vs. thin client performance in typical 6

office application scenarios
server not only to hold the files but also to compress them, so as the number of clients sharing the server
increased, the response time also increased.

The response-time differences for the thin clients were ones users would definitely notice, with response time
going from about 16 seconds in the one-client case to 54 to 55 seconds in the five-client case--an increase of 39
seconds.
Multitasking scenario: Changing the view in a Microsoft PowerPoint presentation while
compressing a folder in Windows Explorer
In this scenario, the users are running multiple tasks at the same time: a folder compression via Microsoft
Explorer in the background, and opening and then changing the view of a PowerPoint presentation in the
foreground. We present the results of our tests of each of those tasks in this section.
Windows Explorer task results
Figures 6 and 7 show the performance of each of the types of clients on the background Windows Explorer file
compression task.

As Figure 6 shows, response time for the PCs held basically constant as we added test clients, while the thin

Normalized Windows Explorer task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80

Dell OptiPlex 210L

0.60
Sun Ray 2

Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5

Number of simultaneously active clients

Figure 6: Results for the Windows Explorer task for all three client platforms. All results are normalized to the one-client PC
result. Higher comparative ratings are better.

client performance both started lower than that of the PCs with 1 client active and then dropped dramatically as
we went to 5 active clients. The slight increase in PC performance is probably because as the server became
busier supplying the PowerPoint file for the file open, the PCs had to wait briefly and so had more processor
cycles available for the file compression.

As Figure 7 details, the single PC actually finished the task 4.2 seconds faster than the Sun Ray 2 thin client and
3.6 seconds faster than the Wyse Winterm 5150SE thin client. As we added clients running the test, however, this
performance lead widened dramatically, because PC performance stayed basically the same as thin client
performance plunged.

Principled Technologies, Inc.: PC vs. thin client performance in typical 7

office application scenarios
 PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING
PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

33.8 38.0 37.4 1 1.00 0.89 0.90

34.5 63.7 58.5 2 0.98 0.53 0.58
31.6 84.4 84.2 3 1.07 0.40 0.40
32.1 116.1 122.3 4 1.05 0.29 0.28
32.5 141.4 142.7 5 1.04 0.24 0.24

Figure 7: Results for the Windows Explorer task for all three client platforms. All results are normalized to the one-client PC
result. Higher comparative ratings are better.

With 5 clients running the test simultaneously, the PCs finished the task 108.9 seconds faster than the Sun Ray 2
thin clients and 110.2 seconds faster than the Wyse Winterm 5150SE thin clients--differences of nearly two
minutes.
Microsoft PowerPoint file open task results
The two foreground tasks in this test suffered on all platforms as the server had to supply all the clients with the
data they needed. Figures 8 and 9 illustrate this effect on the performance of all the types of clients on the
Microsoft PowerPoint file open task.

As you can see in Figure 8, as we added clients the performance of all three types of clients dipped. With 5 active
PCs, PC performance dropped to 55 percent of that of a single PC; a single PC completed the task in 9.9

Normalized M icrosoft PowerPoint file open task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80
Dell OptiPlex 210L
0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5
Number of simultaneously active clients

Figure 8: Results for the Microsoft PowerPoint file open task for all three client platforms. All results are normalized to the
one-client PC result. Higher comparative ratings are better.
seconds, while with 5 PCs the response time was 18.1 seconds. The PCs still dramatically out-performed both
types of thin clients, however: as Figure 9 shows, thin client response time dropped to 11 percent (Wyse Winterm
5150SE) or 12 percent (Sun Ray 2) of the response time of the single-PC case. Both types of thin clients

Principled Technologies, Inc.: PC vs. thin client performance in typical 8

office application scenarios
completed the task in less than 13 seconds with only 1 client active, but with 5 clients active the task took over 80
seconds--over 70 seconds slower.

PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING

PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

9.9 12.4 12.5 1 1.00 0.80 0.79

11.0 29.6 26.3 2 0.90 0.33 0.38
12.9 48.4 46.4 3 0.77 0.20 0.21
15.6 61.2 58.4 4 0.63 0.16 0.17
18.1 82.9 87.7 5 0.55 0.12 0.11
Figure 9: Results for the Microsoft PowerPoint file open task for all three client platforms. All results are normalized
to the one-client PC result. Higher comparative ratings are better.

Microsoft PowerPoint change view task results

As Figures 10 and 11 show, PC performance on the second foreground task, the Microsoft PowerPoint change
view task, once again held steady as we added clients even though the background Windows Explorer task was
still running. Both types of thin clients actually beat the PC in the single-client test case, but their performance
dropped in half when we added a second simultaneously active client. With five active clients the Sun Ray 2 thin
clients turned in noticeably better times than the Wyse Winterm 5150SE systems, but both were far below the

Normalized Microsoft PowerPoint change view task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80
Dell OptiPlex 210L
0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5
Number of simultaneously active clients

Figure 10: Results for the Microsoft PowerPoint change view task for all three client platforms. All results are normalized to
the one-client PC result. Higher comparative ratings are better.
PCs in performance.

The actual time penalties were again ones that users would notice. As Figure 11 shows, the average response
time of the Sun Ray 2 thin clients went from 4.8 seconds with 1 active client to 22.4 seconds with 5 active clients,
while the response time of the Wyse Winterm 5150SE thin clients dropped from 5.2 seconds with 1 client to 37.3
seconds with 5 clients.

Principled Technologies, Inc.: PC vs. thin client performance in typical 9

office application scenarios
 PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING
PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

5.7 4.8 5.2 1 1.00 1.19 1.10

5.6 11.4 11.3 2 1.02 0.50 0.50
5.6 17.2 11.9 3 1.02 0.33 0.48
5.5 15.2 22.4 4 1.04 0.38 0.25
5.5 22.4 37.3 5 1.04 0.25 0.15
Figure 11: Results for the Microsoft PowerPoint change view task for all three client platforms. All results are normalized to
the one-client PC result. Higher comparative ratings are better.

In this multitasking scenario, even with the data files residing on the server the PCs were able to use their local
computing power to response dramatically more quickly than the thin clients on the foreground tasks and to
complete the background task more than 4 times faster than the thin clients--a performance win on all fronts for
users.
Multitasking scenario: Opening large XML files in Microsoft Word and Microsoft Excel
Our last test scenario includes two tasks that both read large data files from the server and are processor-
intensive: opening XML files in Microsoft Word and Microsoft Excel at the same time. The test begins both file
opens at the same time, so the two tasks begin running simultaneously.
Microsoft Excel XML file open task results
Figures 12 and 13 show the response times for each of the client platforms running the Windows Explorer task in
this scenario.

As the graph shows, performance for all the platforms dipped as we added clients and the server had to do more
work to service the additional systems. The PCs, however, stayed significantly ahead of the thin clients as we
added clients, with the 5 PCs running at 64 percent the speed of the single-PC case; by contrast, the thin clients

Normalized Microsoft Excel XML file open task response times

Response times normalized to the one-
client run of the Dell Optiplex 210L

1.00

0.80
Dell OptiPlex 210L
0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5
Number of simultaneously active clients

Figure 12: Results for the Microsoft Excel file open task for all three client platforms. All results are normalized to the one-
client PC result. Higher comparative ratings are better.

Principled Technologies, Inc.: PC vs. thin client performance in typical 10

office application scenarios
ended at less than 30 percent of the performance of the single-PC case.

As both this graph and the detailed results in Figure 13 show, the single Sun Ray 2 thin client was actually 9
percent faster the single PC--but the Sun Ray 2 effectively had the file server dedicated to it (and the requisite
Sun Fire V240 server also supporting it).

PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING

PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

14.0 12.8 14.3 1 1.00 1.09 0.98

13.8 20.6 20.7 2 1.01 0.68 0.68
15.2 30.1 29.4 3 0.92 0.47 0.48
18.6 38.5 41.3 4 0.75 0.36 0.34
22.0 47.8 50.3 5 0.64 0.29 0.28
Figure 13: Results for the Microsoft Excel XML file open task for all three client platforms. All results are normalized to
the one-client PC result. Higher comparative ratings are better.
The time differences among the client types grew from small (just over a second) in the one-client case to quite
large with 5 active clients, where the PCs finished in 22 seconds, while the Sun Ray 2 thin clients took 47.8
seconds to do the same work, and the Wyse Winterm 5150SE thin clients needed 50.3 seconds.
Microsoft Word XML file open task results
Running at the same time as the Excel XML file open, the Microsoft Word XML file open task also involved
opening a substantial file on the server and processing the XML to yield the Word file. Figures 14 and 15 show
the results for this task. As you can see, the results were quite similar to those on the Excel XML file open task,
though this time the single PC outperformed both single thin clients. The reason for this difference is probably the
load the server was facing. While each PC ran the XML processing locally, the thin clients were relying on the

Normalized Microsoft Word XML file open task response times

Response times normalized to the one-client

1.00
run of the Dell Optiplex 210L

0.80
Dell OptiPlex 210L
0.60 Sun Ray 2
Wyse Winterm 5150SE

0.40

0.20

0.00
1 2 3 4 5
Number of simultaneously active clients

Figure 14: Results for the Microsoft Word XML file open task for all three client platforms. All results are normalized to the
one-client PC result. Higher comparative ratings are better.

Principled Technologies, Inc.: PC vs. thin client performance in typical 11

office application scenarios
server to do that work--and the server also had to supply the data files and handle the Word XML processing for
them at the same time.

As Figure 15 shows, with 5 active clients the PCs, which, like the thin clients, had to rely on the server to supply
the files, ran at 48 percent the speed of the single-PC case. The thin clients, by contrast, ran at only 20 percent
(Sun Ray 2) and 19 percent (Wyse Winterm 5150SE) of the speed of the single PC.

PERFORMANCE RESULTS (in seconds) COMPARATIVE RATING

PC solution Thin-client solutions Number of PC solution Thin-client solutions
simultaneously
Dell OptiPlex Wyse Winterm active clients Dell OptiPlex Wyse Winterm
Sun Ray 2 Sun Ray 2
210L 5150SE 210L 5150SE

10.2 15.3 12.2 1 1.00 0.67 0.84

11.7 26.1 25.2 2 0.87 0.39 0.40
15.5 34.0 33.1 3 0.66 0.30 0.31
17.7 43.4 44.7 4 0.58 0.24 0.23
21.1 51.3 53.6 5 0.48 0.20 0.19

Figure 15: Results for the Microsoft Word XML file open task for all three client platforms. All results are normalized to the
one-client PC result. Higher comparative ratings are better.

In the five-client case, these percentage differences translated into time savings of more than 30 seconds for the
PCs as compared to the thin clients.

As we noted earlier, to provide an apples-to-apples comparison, we forced all the clients to store the data they
needed on the server. The PCs, of course, could have stored the data locally. Had we allowed the PCs to do so,
their performance edge in the multi-client tests would almost certainly have been much larger.
Uneven service
In all of our results discussions to this point, we have focused on average response time. In multi-user networks,
all systems of the same type should generally receive the same type of response time when performing the same
operations on the same files. In our tests, that was certainly the case with the PCs. Consider, for example, the
Microsoft PowerPoint change view task. Figure 16 shows the range of response times for the five-client tests of
this task on each of the client types. The PCs, as we would hope and expect, showed remarkably little variance,
with the difference between the best response time a system received (5.3 seconds) and the worst (5.8 seconds)
only half a second.

Range of response times for the five-client results on the Microsoft PowerPoint change view task
Dell OptiPlex 210L Sun Ray 2 Wyse Winterm 5150SE
Minimum response time (seconds) 5.3 14.1 16.8
Maximum response time (seconds) 5.8 30.8 27.9
Range of response times (seconds) 0.5 16.7 11.1
Figure 16: Range of response times for the runs of the five-client test for the PowerPoint change view task for all three
client platforms. Lower numbers are better.

As the same table shows, on some tasks the thin clients, by contrast, delivered very different response times to
each user, a phenomenon we refer to as "uneven service." In the five-client test of this PowerPoint operation, one
Sun Ray 2 thin client finished the test in 14.1 seconds, while another took 30.8 seconds--a difference of 16.7
seconds. The Wyse Winterm 5150SE thin clients ranged in completion times from 16.8 seconds to 27.9 seconds,
a difference of 11.1 seconds. This level of uneven service would result in different users having very different
computing experiences, something IT managers generally want to avoid.

Principled Technologies, Inc.: PC vs. thin client performance in typical 12

office application scenarios
Test methodology
We evaluated the performance of each of the application scenarios (see “Application scenarios”) both by hand
and with automated test scripts, which we developed with IBM’s Visual Test 6.5. Appendix B details the steps we
followed when we hand-timed the scenarios. In this paper, we concentrate our discussions on the results of the
automated scripts, because those results are generally more repeatable than hand timings, especially in tests
involving multiple clients running simultaneously.

We created a test network for each of the client types: Dell OptiPlex 210L PCs, Sun Ray 2 thin clients, and Wyse
Winterm 5150SE thin clients. Each test network included a file server, five client systems, and, for the Sun Ray 2
thin clients, the special Sun server they require. We used a pair of identical file servers to allow us to have two
networks under test at a time. Appendix A provides detailed configuration information on all of the different
systems we used in our test. We used a 100-Mbps network infrastructure whenever possible, because that
infrastructure is common in enterprises today.

For the Sun Ray 2 thin client test network, we set up user accounts and Windows Terminal Server on the file
server. For the Wyse Winterm 5150SE thin client test network, we set up the file server so it would have accounts
for all five Wyse Winterm 5150SE thin clients and run the Citrix Access Essentials software they required to be
able to execute the office applications in our test scripts. In all of these test networks, we assigned each system a
static IP address, with one exception: the Sun Fire V240 server automatically assigned IP addresses to the Sun
Ray 2 thin clients. The PCs required no special setup.

We installed the Microsoft Office 2003 and Adobe Acrobat 7.0 Standard applications so that they would be
available to all the clients. The test scripts run tasks in these applications. Because the thin clients do not have
disks, all their applications and data files reside on the file server. We installed the PC applications on each PC,
but to make the performance comparison as fair as possible, we stored the data files on the server except in one
case in which storing a file locally made more sense in the usage model.

We ran four test scripts on each test network with five client configurations:

• 1 client running the script

• 2 clients simultaneously running the script
• 3 clients simultaneously running the script
• 4 clients simultaneously running the script
• 5 clients simultaneously running the script

This approach allowed us to gauge the response-time effects on end users of adding clients to each test network.

For each test script on each test network, we first performed the following script setup steps:

• reboot (in the appropriate order; more on that in the discussions below) the systems in the test network
• create a desktop shortcut for the test script
• create a desktop shortcut for the setup script that prepares the data files for testing
• create a desktop shortcut for the script that cleans up data files between runs of the script
• run the setup script

After we finished this setup process for each script, we ran that script on that network five times in each of the
above five client configurations. If any test or script failed, we discarded that test’s results and ran the test again.
We rebooted the test network systems between each run of each test script.

We refer in this paper only to the median results of each set of five runs on each test network configuration. The
scripts produce times (in milliseconds), with lower times to complete a given function indicating better
performance. We round those times to tenths of seconds in this report.

Principled Technologies, Inc.: PC vs. thin client performance in typical 13

office application scenarios
In the following sections we discuss how to set up each test network and how to execute the tests on that
network.
Test network setup
Some setup steps were the same for all the test networks, while others were specific to each network.

We performed the initial setup of the shared file server the same way on all the test networks. The first subsection
below outlines that process. The thin clients do not have disks, so the file server held both their applications and
the test data. For the PC test network, the file server held only the test data; we installed the applications locally,
as typical users would.

The subsequent subsections discuss each test network and the steps we took to set it up. Each of those
discussions includes three sections:

• Instructions for setting an additional server: The Sun Ray 2 thin clients required a special Sun server.
• Test network-specific setup instructions for the file server. On each thin client test network, the file server
also ran the software necessary to support the thin clients. We outline the steps necessary to set up that
software in this section.
• Instructions for setting up the clients.
Setting up the file server for all three test networks
We followed this process to initially prepare the file server.

1. Install an OEM copy of Microsoft Windows 2003 Server Enterprise Edition, Service Pack 1.
2. Create two partitions: one for the server, and one for the test applications and files the clients use.
3. Apply the following updates from the Microsoft Windows Update site:
• Windows Server 2003 Security Update for Windows Server 2003 (KB908531)
• Windows Server 2003 Windows Malicious Software Removal Tool - April 2006 (KB890830)
• Windows Server 2003 Security Update for Windows Server 2003 (KB911562)
• Windows Server 2003 Cumulative Security Update for Internet Explorer for Windows Server 2003
(KB912812)
• Windows Server 2003 Cumulative Security Update for Outlook Express for Windows Server 2003
(KB911567)
• Windows Server 2003 Security Update for Windows Server 2003 (KB913446)
• Windows Server 2003 Security Update for Windows Server 2003 (KB911927)
• Windows Server 2003 Security Update for Windows Server 2003 (KB908519)
• Windows Server 2003 Security Update for Windows Server 2003 (KB912919)
• Windows Server 2003 Security Update for Windows Server 2003 (KB904706)
• Windows Server 2003 Update for Windows Server 2003 (KB910437)
• Windows Server 2003 Security Update for Windows Server 2003 (KB896424)
• Windows Server 2003 Security Update for Windows Server 2003 (KB900725)
• Windows Server 2003 Security Update for Windows Server 2003 (KB901017)
• Windows Server 2003 Security Update for Windows Server 2003 (KB899589)
• Windows Server 2003 Security Update for Windows Server 2003 (KB902400)
• Windows Server 2003 Security Update for Windows Server 2003 (KB905414)
• Windows Server 2003 Security Update for Windows Server 2003 (KB899591)
• Windows Server 2003 Security Update for Windows Server 2003 (KB890046)
• Windows Server 2003 Security Update for Windows Server 2003 (KB899587)
• Windows Server 2003 Security Update for Windows Server 2003 (KB896358)
• Windows Server 2003 Security Update for Windows Server 2003 (KB896422)
• Windows Server 2003 Security Update for Windows Server 2003 (KB896428)
• Windows Server 2003 Security Update for Windows Server 2003 (KB893756)
• Windows Server 2003 Security Update for Windows Server 2003 (KB899588)
• Windows Server 2003 Security Update for Windows Server 2003 (KB901214)
• Windows Server 2003 Update for Windows Server 2003 (KB898715)

Principled Technologies, Inc.: PC vs. thin client performance in typical 14

office application scenarios
 4. Install Microsoft Office 2003.
5. Apply all Microsoft Office 2003 updates (as of May 31, 2006) from the Microsoft Office Update Web site.
6. Turn off Windows Service Pack 2 Security Center Pop-up Alerts. Doing so prevents such alerts from
occurring during testing and affecting results.
a. Open the system Control Panel.
b. Choose Security Center.
c. Click Change the way Security Center Alerts me on the left.
d. Uncheck Firewall, Automatic Updates, and Virus Protection.
7. Turn off Windows Automatic Updates. Doing so prevents such updates from occurring during testing and
affecting results.
a. Open the system Control Panel.
b. Choose Automatic Updates.
c. Select Turn off Automatic Updates.
8. Turn off System Restore. Doing so prevents such events from occurring during testing and affecting
results.
a. Open the system Control Panel.
b. Choose System.
c. Choose the System Restore tab.
d. Select Turn off System Restore on all drives.
9. Set up the script folders for each test system (PC or thin client):
a. Create a folder named User Files.
b. Within that folder, create five folders, named User1 through User5. These folders will hold the
individual script directories.
10. Copy the four script folders into each of these directories. You will end up with five copies of the scripts,
one for each user. These folders contain all of the files the scripts need to execute. Each of the four script
folder's names identifies the test script. Each of those folders contains a folder named SC1. Each SC1
folders contains the same three subfolders:
a. Content: all the test files the script uses
b. Results: initially empty but will contain the results file the script creates
c. Scripts: the script’s source and executable files.
11. To ensure as consistent a starting point as possible for the performance measurements, defragment the
hard disk.
12. Using Symantec’s Ghost utility, make an image of the hard disk. (This image lets us return to a clean and
consistent starting point whenever necessary.)
Setting up the PC test network
Figure 17 illustrates the test network for the PC clients. Connect the systems as this diagram shows.

Principled Technologies, Inc.: PC vs. thin client performance in typical 15

office application scenarios
 Figure 17: The PC test network. The blue lines represent 100-Mbps network connections.

Setting up any additional servers in the PC test network

The PC test network does not require any servers beyond the file server.
Additional file server set up for the PC test network
The PC test network does not require any specific file server setup beyond the steps we outlined above.
Setting up the PC clients
Repeat these steps on each of the five PC clients.

1. Start with the OEM image of the systems.

2. Apply all XP critical updates (as of May 31, 2006) from the Microsoft Windows Update Web site, including
Windows XP SP2. Do not install any of the optional updates.
3. Install Microsoft Office 2003.
4. Apply all Office 2003 updates (as of May 31, 2006) from the Microsoft Office Update Web site.
5. Turn off Windows Service Pack 2 Security Center Pop-up Alerts. Doing so prevents such alerts from
occurring during testing and affecting results.
a. Open the system Control Panel.
b. Choose Security Center.
c. Click Change the way Security Center Alerts me on the left.
d. Uncheck Firewall, Automatic Updates, and Virus Protection.
6. Turn off Windows Automatic Updates. Doing so prevents such updates from occurring during testing and
affecting results.
a. Open the system Control Panel.
b. Choose Automatic Updates.
c. Select Turn off Automatic Updates.
7. Turn off System Restore. Doing so prevents such events from occurring during testing and affecting
results.
a. Open the system Control Panel.
b. Choose System.
c. Choose the System Restore tab.
d. Select Turn off System Restore on all drives.
8. Change the PC's IP address to 192.168.1.5[X], where X is the client number of the PC. (We numbered
the PCs 1 through 5.)
a. Click Start Æ Control Panel Æ Select Network Connections.
b. Select Local Area Connection.

Principled Technologies, Inc.: PC vs. thin client performance in typical 16

office application scenarios
 c. In the Local Area Connection Status dialog, select Properties.
d. In the Local Area Connection Properties dialog, select Properties.
e. Select the Use the following IP address radio button.
f. Enter the IP Address.
g. Select OK on the top two open dialog boxes.
h. Select Close to close the third dialog box.
9. Map the network drive Q: to \\[servername]\fileserver\user files\user[X], where X is as above.
a. Right-click My Computer.
b. Select Map Network Drive.
c. Select Q: from the Drive drop-down menu.
d. Type \\[servername]\fileserver\user files\user[X], where X is as above, as the Folder name.
e. Click Finish.
10. Create a desktop shortcut to the Q: network drive. This shortcut's name will be of the form "Shortcut to
UserX on [servername]".
11. Configure the Visual Test Runtime application so that it will work with all the test scripts:
a. Copy the following five Visual Test dll files into \WINDOWS\SYSTEM32:
• IEHelper.dll
• Vtaa.dll
• VTest60.dll
• Vtres.dll
• WebDrive.dll
b. Open a command prompt.
c. Type cd \WINDOWS\SYSTEM32, and press Enter.
d. For each of the following three dlls, type regsvr32 [dll filename], and press Enter. (This command
registers a dll with the system.)
• IEHelper.dll
• Vtaa.dll
• WebDrive.dll
12. Install Adobe Acrobat 7.0 Standard.
13. To ensure as consistent a starting point as possible for the performance measurements, defragment the
hard disk of each PC.
14. Using Symantec’s Ghost utility, make an image of each PC's hard disk. (This image let us return to a
clean and consistent starting point whenever necessary.)
Setting up the Sun Ray 2 thin client test network
Figure 18 shows the test network for the Sun Ray 2 thin clients. Those clients require the Sun Fire V240 server.
They also require the file server to run the Windows Terminal Server software. We used a 1-Gbps connection
between the Sun Fire V240 server and the file server to minimize any performance effect that connection might
have. Connect the systems as this diagram shows.

Principled Technologies, Inc.: PC vs. thin client performance in typical 17

office application scenarios
 Figure 18: The Sun Ray 2 thin client test network. The blue lines represent 100-Mbps network connections. The red line
represents a 1-Gbps network connection.

Setting up any additional servers in the Sun Ray 2 thin client test network
We followed this process to set up the Sun Fire V240 server:

1. Following the instructions for the V240 on Sun’s Web site (http://www.sun.com/products-n-
solutions/hardware/docs/html/819-4209-10/), set up a server with two NICs: one for the connection with
the Sun Ray 2 thin clients, and one for the connection with the file server.
2. Install the following products that the V240 needs to support the Sun Ray 2 thin clients:
• Sun Ray Server Software 3.1
• Sun Ray Connector for Windows OS 1.0
• Sun Desktop Manager 1.0
3. Using the default settings, configure the thin client NIC to have an exclusive network for the Sun Ray 2
thin clients.
4. When the installation software asks whether it should configure the Sun Fire server to have controlled
access mode, select Yes. This configuration lets the Sun Fire server directly control how the Sun Ray 2
thin clients boot.
5. Create a user account, ruser, with the password, “password”, to allow telnetting into the server.
Additional file server set up for the Sun Ray 2 thin client test network
We set up the file server so it would have accounts for all five Sun Ray 2 thin clients, run the Windows Terminal
Server software they required to be able to execute the office applications in our test scripts, and contain the
Adobe Acrobat and Visual Test software the scripts required.

1. Create five users (RUSER1 through RUSER5). Give each remote desktop privileges and the password
“password”.
2. Change the IP address of the Sun Fire V240 server to 10.41.1.80.
3. Configure the Visual Test Runtime application so that it will work with all the test scripts:
a. Copy the following five Visual Test dll files into /WINDOWS/SYSTEM32:
• IEHelper.dll
• Vtaa.dll
• VTest60.dll
• Vtres.dll
• WebDrive.dll

Principled Technologies, Inc.: PC vs. thin client performance in typical 18

office application scenarios
 b. Open a command prompt.
c. Type cd \WINDOWS\SYSTEM32, and press Enter.
d. For each of the following three dlls, type regsvr32 [dll filename], and press Enter. (This command
registers a dll with the system.)
• IEHelper.dll
• Vtaa.dll
• WebDrive.dll
4. Make sure Windows Terminal Services is active on the server and supporting the thin clients.
5. Install Adobe Acrobat 7.0 Standard.
4. To ensure as consistent a starting point as possible for the performance measurements, defragment the
hard disk.
5. Using Symantec’s Ghost utility, make an image of the hard disk. (This image let us return to a clean and
consistent starting point whenever necessary.)
Setting up the Sun Ray 2 thin clients
Repeat these steps on each of the five Sun Ray 2 thin clients.

1. Boot the file server.

2. Boot the Sun Fire v240.
3. Log in as ruser[X] on the Sun Ray 2, where X is the number of this client (1 to 5).
4. Configure it to run terminal services immediately upon boot.
5. Configure it to have a display resolution of 1024x768 and 24-bit color depth.
6. Map the network drive Q: to \\[servername]\fileserver\user files\user[X], where X is as above.
a. Right-click My Computer.
b. Select Map Network Drive.
c. Select Q: from the Drive drop-down menu.
d. Type \\[servername]\fileserver\user files\user[X], where X is as above, as the Folder name.
e. Click Finish.
7. Create a desktop shortcut to the Q: network drive. This shortcut's name will be of the form "Shortcut to
UserX on [servername]".
8. Log out of the thin client.
9. Log on to the file server as administrator.
10. Open a command prompt.
11. Type telnet 10.41.1.180, and press Enter. You can access the Sun Fire V240 only via telnet, because it
does not have a monitor, keyboard, or mouse.
12. When the system prompts you for a username, log in as ruser with password “password”.
13. Wait for the login process to complete.
14. Type su to log on as the administrator with password “password”.
15. Type sync;sync;init 6, and press Enter.
16. On the file server, click Start Æ Shut Down.
17. Make sure that in the list box under What do you want the computer to do?, you have selected Restart.
18. Type an explanatory comment in the comment box.
19. Press enter.
20. You may see a warning dialog that says shutting down will close remote connections and that asks if you
want to end them. Click Yes, and the file server will restart.
Setting up the Wyse Winterm 5150SE thin client test network
Figure 19 illustrates the test network for the Wyse Winterm 5150SE thin clients. Those clients require the file
server to run the Citrix Essentials software. Connect the systems as this diagram shows.

Principled Technologies, Inc.: PC vs. thin client performance in typical 19

office application scenarios
 Figure 19: The Wyse Winterm 5150SE thin client test network. The blue lines represent 100-Mbps network connections.

Setting up any additional servers in the Wyse Winterm 5150SE thin client test network
The Wyse Winterm 5150SE test network does not require any servers beyond the file server.
Additional file server set up for the Wyse Winterm 5150SE thin client test network
We set up the file server so it would have accounts for all five Wyse Winterm 5150SE thin clients, run the Citrix
Access Essentials software they required to be able to execute the office applications in our test scripts, and
contain the Adobe Acrobat and Visual Test software the scripts required.

1. Create five users (RUSER1 through RUSER5). Give each remote desktop privileges and the password
“password”.
2. Install Citrix Access Essentials using all defaults.
3. Set up RUSER1 through RUSER5 so each account has Citrix user permissions.
4. Change the Citrix connection settings to permit the Wyse Winterm 5150SE thin clients to run unpublished
applications.
a. Open the Citrix Connection Configuration tool.
b. Double-click the ica-tcp connection to open its properties.
c. Click the Advanced button in the lower left.
d. In the Initial Program group box, uncheck the Only launch Published Applications checkbox if it is
checked.
5. Configure the Visual Test Runtime application so that it will work with all the test scripts:
a. Copy the following five Visual Test dll files into /WINDOWS/SYSTEM32:
• IEHelper.dll
• Vtaa.dll
• VTest60.dll
• Vtres.dll
• WebDrive.dll
b. Open a command prompt.
c. Type cd \WINDOWS\SYSTEM32, and press Enter.
d. For each of the following three dlls, type regsvr32 [dll filename], and press Enter. (This command
registers a dll with the system.)
• IEHelper.dll
• Vtaa.dll
• WebDrive.dll

Principled Technologies, Inc.: PC vs. thin client performance in typical 20

office application scenarios
 6. Install Adobe Acrobat 7.0 Standard.
7. To ensure as consistent a starting point as possible for the performance measurements, defragment the
hard disk.
8. Using Symantec’s Ghost utility, make an image of the hard disk. (This image lets us return to a clean and
consistent starting point whenever necessary.)
Setting up the Wyse Winterm 5150SE thin clients
Repeat these steps on each of the five Wyse Winterm 5150SE clients.

1. Boot the file server.

2. Boot the Wyse Winterm 5150SE thin client.
3. Change the IP address of the thin client to 192.168.1.5[X], where X is the number of the client.
a. Click Start Æ Control Panel Æ Select Network Connections.
b. Select Local Area Connection.
c. In the Local Area Connection Status dialog, select Properties.
d. In the Local Area Connection Properties dialog, select Properties.
e. Select the Use the following IP address radio button.
f. Enter the IP Address.
g. Select OK on the top two open dialog boxes.
h. Select Close to close the third dialog box.
4. Configure each Wyse Winterm 5150SE to have a display resolution of 1024x768 and 24-bit color depth.
5. Create a remote desktop connection with the file server.
a. Click Start Æ Connection Manager.
b. In the Connection manager window, click the Add button.
c. In the first window, select ICA, and click Next.
d. Under the Network tab, enter the following:
I. In the Description box: TCSERVER
II. In the Browser Server box: 192.168.1.250
III. In the Server box: 192.168.1.250.
e. Under the Window tab, set the Window Colors to 16 Million and the Window Size to Full screen.
f. Under the Login tab, enter the following:
I. In the User Name box: RUSER[X], where X is as above
II. For the password: password
III. For the domain: TCSERVER
IV. Click the Connect automatically after login check box
6. Map the network drive Q: to \\[servername]\fileserver\user files\user[X], where X is as above.
a. Right-click My Computer.
b. Select Map Network Drive.
c. Select Q: from the Drive drop-down menu.
d. Type \\[servername]\fileserver\user files\user[X], where X is as above, as the Folder name.
e. Click Finish.
7. Create a desktop shortcut to the Q: network drive. This shortcut's name will be of the form "Shortcut to
UserX on [servername]".
8. Log on to the file server as administrator.
9. Click Start Æ Shut Down.
10. Make sure that in the list box under What do you want the computer to do?, you have selected Restart.
11. Type an explanatory comment in the comment box.
12. Press enter.
13. You may see a warning window that says shutting down will close remote connections and that asks if
you want to end them. Click Yes, and the file server will restart.

Principled Technologies, Inc.: PC vs. thin client performance in typical 21

office application scenarios
Running the tests
Setting up the servers and clients is much more complicated than the testing process. When you have correctly
set up the clients, they will automatically connect to the server(s). Executing the tests on a particular type of client
involves three relatively straightforward phases:

1. Getting the systems ready to go. In this phase, you make sure all the systems in the test network are on,
appropriately connected (e.g., clients are connected to the file server), and ready for testing.
2. Setting up the test script you want to run. Each script has a setup script that you must run once on each
client before testing on that client with that script. The setup script makes sure the data files are ready,
the application windows are where the test script expects to find them, and so on.
3. Running the test scripts and recording results. You must reboot the test network systems before each run
of each test script and start the test script at the same time on all the clients under test.

Phase 1 varies for each test network. We detail it below in the sections on the test networks. In all of these
discussions, we assume you have already completed the setup process we outlined earlier. We also assume any
client systems you do not want to include in a test will not be on.

Phase 2 is the same regardless of the type of client you are testing. Once you have readied all the systems to go
and are working on a client, follow this process to prepare the client to run a test script:

1. Double-click the desktop shortcut Shortcut to UserX at [servername], where X is the number of the client
and servername is the name you gave the file server.
2. You will see four folders, one for each script. Open the folder that contains the script you are testing.
3. Inside that folder is a folder named SC1. Double-click that folder.
4. You will see three folders: Content, Results, and Scripts. The Scripts folder contains the individual script
files. Double-click the Scripts folder.
5. In the Scripts folder, find the files SC1-Setup.pc6 and SC1main.pc6. Create desktop shortcuts to each of
them.
6. Some scripts require an additional preparation or cleanup program. If so, the Script folder will contain a
third file named SC1-Prep.pc6 or SC1cleanup.pc6, respectively. If either file exists, create a desktop
shortcut to it.
7. Run SC1-Setup.

Phase 3 is largely the same regardless of the type of client. Once you have finished the above script setup phase,
do the following for each test you want to run:

1. Reboot all the servers and the clients you will be using in the test. This process varies by client type; we
outline it for each client test network below.
2. Wait 10 seconds after the Windows hourglass has disappeared on all the clients to ensure a consistent
starting state.
3. On each client you want to test, if there is a shortcut to SC1-Prep or SC1cleanup, do the following:
a. Double-click that shortcut.
b. Wait until you see a confirmation window that prep has completed, or, in the case of SC1cleanup,
wait 30 seconds.
4. Start the script at the same time on all the clients you are testing by clicking the Shortcut to SC1main and
pressing Enter on each client.
5. When the test completes, record the results of each client.

As we discussed at the beginning of the Test methodology section, we ran each script five times on each test
configuration of each network (e.g., five times with one active PC, five times with two active PCs, and so on.)

In the following three subsections, we detail the first phase for each of the three types of test networks. As
Testing the PC clients
This section provides the test execution preparation steps specific to the PC test network.

Principled Technologies, Inc.: PC vs. thin client performance in typical 22

office application scenarios
 1. Power on the file server.
2. When the server is fully active, power on all the PCs you are testing.
Getting the PC test network systems ready to go
Follow these steps to ready the file server and PCs for testing:
1. Power on the file server.
2. When the server is fully active, power on the PCs you are testing.
Reboot the PC test network systems
Follow these steps to reboot the file server and PCs for testing:

1. Log on to the file server as administrator.

2. Click Start Æ Shut Down.
3. Make sure that in the list box under What do you want the computer to do?, you have selected Restart.
4. Type an explanatory comment in the comment box.
5. Press Enter.
6. You may see a warning window that says shutting down will close remote connections and that asks if
you want to end them. Click Yes, and the file server will restart.
7. When the server is fully active, power on the PCs you are testing.
Testing the Sun Ray 2 thin clients
This section provides the test execution preparation steps specific to the Sun Ray 2 test network.
Getting the Sun Ray 2 test network systems ready to go
Follow these steps to ready the file server, the Sun Fire V240 server, and the Sun Ray 2 thin clients for testing:
3. Power on the Sun Fire V240 server.
4. Power on the file server.
5. When both servers are fully active, power on the Sun Ray 2 thin clients you are testing.
6. When each Sun Ray 2 prompts you to log on, log on as ruser[X], where X is the number of the client.
Rebooting the Sun Ray 2 test network systems
Follow these steps to ready the file server, the Sun Fire V240 server, and the Sun Ray 2 thin clients for testing:

1. Log on to the file server as administrator.

2. Open a command prompt.
3. Type telnet 10.41.1.180, and press Enter.
4. When the system prompts you for the username, log in as ruser with password “password”.
5. Wait for the login process to complete.
6. Type su to log on as the administrator with password “password”.
7. Type sync;sync;init 6, and press Enter.
8. Click Start Æ Shut Down.
9. Make sure that in the list box under What do you want the computer to do?, you have selected Restart.
10. Type an explanatory comment in the comment box.
11. Press Enter.
12. You may see a warning window that says shutting down will close remote connections and that asks if
you want to end them. Click Yes, and the file server will restart.
13. When both servers are fully active, power on the Sun Ray 2 thin clients you are testing.
14. When each Sun Ray 2 prompts you to log on, log on as ruser[X}, where X is the number of the client.
Testing the Wyse Winterm 5150SE thin clients
This section provides the test execution preparation steps specific to the Wyse Winterm 5150SE test network.
Getting the Wyse Winterm 5150SE test network systems ready to go
Follow these steps to ready the file server and Wyse Winterm 5150SE thin clients for testing:
1. Power on the file server.
2. Wait two minutes after the server finishes booting. (This step avoids potential thin-client connection
issues.)
3. Power on all the Wyse Winterm 5150SE thin clients you are testing.

Principled Technologies, Inc.: PC vs. thin client performance in typical 23

office application scenarios
Rebooting the Wyse Winterm 5150SE test network systems
Follow these steps to ready the file server and Wyse Winterm 5150SE thin clients for testing:

1. Log on to the file server as administrator.

2. Click Start Æ Shut Down.
3. Make sure that in the list box under What do you want the computer to do?, you have selected Restart.
4. Type an explanatory comment in the comment box.
5. Press Enter.
6. You may see a warning window that says shutting down will close remote connections and that asks if
you want to end them. Click Yes, and the file server will restart.
7. Wait two minutes after the server finishes booting. (This step avoids potential thin-client connection
issues.)
8. When the server is fully active, power on the Wyse Winterm 5150SE thin clients you are testing.

Principled Technologies, Inc.: PC vs. thin client performance in typical 24

office application scenarios
Appendix A: Test system configuration information
This appendix provides detailed configuration information about the each of the several types of systems we used
in this test

Test PCs Dell OptiPlex 210L

System configuration information

General
Processor and OS kernel: (physical, core, logical) / (UP, MP) 1P1C2L / MP
Number of physical processors 1
Single/Dual-Core processors Single
System Power Management Policy Home/Office Desk
CPU
System type Desktop
Vendor Intel
Name Intel Pentium 4 650
Stepping 3
Socket type LGA775
Core frequency (GHz) 3.4
Front-side bus frequency (MHz) 800
L1 Cache 16 KB + 12 Kμops
L2 Cache 2 MB
Platform
Vendor Dell
Motherboard model number 0HC918
Motherboard chipset Intel i915G Chipset
Motherboard revision number B1
Motherboard serial number 5PT4V91
BIOS name and version Dell A01
BIOS settings Default
Memory module(s)
Vendor and model number Samsung M378T3354CZ3-CD5
Type PC4300 DDR-2
Speed (MHz) 533
Speed in the system currently running @ (MHz) 266
Timing/Latency (tCL-tRCD-tRP-tRASmin) 4-4-4-11
Size 512 MB
Number of sticks 2
Chip organization Double-sided
Channel Dual
Hard disk
Vendor and model number Samsung HD080HJ/P
Number of disks in system 1
Size 80 GB
Buffer Size 8 MB
RPM 7200
Type SATA
Controller Intel 82801FB (ICH6)
Driver Intel 7.0.0.1011
Operating system

Principled Technologies, Inc.: PC vs. thin client performance in typical 25

office application scenarios
 Name Microsoft Windows XP Professional
Build number 2600
Service pack SP2
File system NTFS
Kernel ACPI Multiprocessor PC
Language English
Microsoft DirectX version 9.0c
Graphics
Vendor and model number Intel 915G
Type Integrated
Chipset Intel 82915G Express Chipset
BIOS version 3414
Memory size 128 MB Shared
Resolution 1024 x 768
Driver Intel 6.14.10.4299
Network card/subsystem
Vendor and model number Intel PRO/100 VE
Type Integrated
Driver Intel 8.0.15.0
Other Network Card Information Intel PRO/100 VE
Optical drive 1
Vendor and model number LG GWA4164B
Type DVD-RW
Dual/Single layer Dual
USB ports
# of ports 6
Type of ports (USB1.1, USB2.0) USB 2.0
Figure 20: Detailed system configuration information for the test PCs (Dell OptiPlex 210L systems).

Thin clients Sun Ray 2 Wyse Winterm 5150SE

General
Processor and OS kernel: (physical, core,
Unknown 1P1C1L / UP
logical) / (UP, MP)
Number of physical processors 1 1
CPU
System type Thin Client Thin Client
Vendor Raltron AMD
Name CO66 Geode GX
Core frequency (MHz) 48 Unknown
Front-side bus frequency (MHz) Unknown PCI 66MHz bus
Memory module(s)
Size Unknown 64 MB Flash / 128 MB DDR
Operating system
Name None Wyse Linux V6
Graphics
Vendor and model number VGA VGA- type (DB-15)
Type Integrated Integrated
Resolution 1024 x 768 1024 x768
Network card/subsystem
Vendor and model number 10/100 Base-T 10/100 Base-T

Principled Technologies, Inc.: PC vs. thin client performance in typical 26

office application scenarios
 Type Integrated Integrated
USB ports
Number 2 4
Type USB 1.1 USB 2.0
Monitor
Type ViewSonic Optiquest Q7 ViewSonic Optiquest Q7
Screen size 17” 17”
Refresh rate 75 Hz 75 Hz
Figure 21: Detailed system configuration information for the Sun Ray 2 and Wyse Winterm 5150SE thin clients we tested.

File server both the PCs and thin clients used HP ProLiant DL360 1U Rack Server

System configuration information

General
Processor and OS kernel: (physical, core, logical) / (UP, MP) 1P1C2L / MP
Number of physical processors 1
Single/Dual-Core processors Single
System Power Management Policy AC/Always On
CPU
Vendor Intel
Name Intel Xeon
Stepping A
Socket type mPGA-604
Core frequency (GHz) 3.4
Front-side bus frequency (MHz) 800
L1 Cache 16 KB + 12 Kμops
L2 Cache 2 MB
Platform
Vendor and model number HP
Motherboard model number 382146-405
Motherboard chipset Intel E7520 Chipset
Motherboard revision number A05
Motherboard serial number USE617N2DF
BIOS name and version HP P54
BIOS settings Default
Memory module(s)
Vendor and model number Infineon HYS72T128000HR-5-A
Type PC2-3200 DDR-2
Speed (MHz) 400
Speed in the system currently running @ (MHz) 200
Timing/Latency (tCL-tRCD-iRP-tRASmin) 3-3-3-11
Size 2048 MB
Number of RAM modules 2
Chip organization Double-sided
Channel Single
Hard disk
Vendor and model number Maxtor 6L160M0
Number of disks in system 2
Size 160GB
Buffer Size 8 MB
RPM 7200

Principled Technologies, Inc.: PC vs. thin client performance in typical 27

office application scenarios
 Type SATA
Controller Intel 6300ESB (ICH-S)
Controller driver Microsoft 5.2.3790.1830
Operating system
Microsoft Windows 2003 Server, x32
Name
Enterprise Edition
Build number 3790
Service Pack SP1
File system NTFS
Kernel ACPI Multiprocessor PC
Language English
Microsoft DirectX version 9.0c
Graphics
Vendor and model number ATI Rage XL
BIOS version GR-xlcpq-5.882-4.333
Type Integrated
Memory size 8 MB shared
Resolution 1024 x 768
Driver ATI 5.10.2600.6014
Network card/subsystem
Vendor and model number HP NC7782 Dual-port Gigabit Server Adapter
Type Integrated
Driver HP 8.39.1.0
Optical drive
Vendor and model number HLDS GCR-8240N
Type CD-ROM
USB ports
# of ports 2
Type of ports (USB 1.1, USB 2.0) USB 2.0
Figure 22: Detailed system configuration information for the server both the PCs and the thin clients used.

Server the Sun Ray 2 thin clients required Sun Fire V240

System configuration information

General
Processor and OS kernel: (physical, core, logical) / (UP, MP) 2P3C3L
Number of physical processors 2
Single/Dual-Core processors Single
System Power Management Policy N/A
CPU
Vendor Sun Microsystems
Name UltraSPARC IIIi
Socket type mPGA-959
Core frequency (GHz) 1.5
L1 Cache 32 KB + 64 KB
L2 Cache 1 MB
Platform
Vendor and model number Sun Microsystems
Motherboard model number PWA-EENXs
Motherboard serial number 0328MIC-0616H01Y8R
Memory module(s)

Principled Technologies, Inc.: PC vs. thin client performance in typical 28

office application scenarios
 Vendor and model number Micron MT18VDDT6472G
Type PC2100
Speed (MHz) 266
Speed in the system currently running @ (MHz) 266
Timing/Latency (tCL-tRCD-iRP-tRASmin) CL2
Size 2048 MB
Number of RAM modules 4
Chip organization Double-sided
Channel Dual
Hard disk
Vendor and model number Fujitsu MAW3073NC
Number of disks in system 2
Size 72 GB
Buffer Size 8 MB
RPM 10000
Type SCSI
Controller LSA0725 / LSI53C1010R
Operating system
Name Solaris 10
Build number 3/05
Service Pack N/A
File system UFS
Language English
Network card/subsystem
Type Integrated
Optical drive
Vendor and model number TEAC DV-28E-N93
Type DVD-ROM
USB ports
# of ports 2
Type of ports (USB 1.1, USB 2.0) USB 1.1
Figure 23: Detailed system configuration information for the server the Sun Ray 2 thin clients required.

Principled Technologies, Inc.: PC vs. thin client performance in typical 29

office application scenarios
Appendix B: Instructions for running the application scenarios
This appendix summarizes the script for each application scenario and explains how we manually tested and
timed each of those scenarios. Though the vast majority of our discussions in this report focus on the results of
the automated tests, we verified that manually performing the same functions yielded results similar to those of
the automated scripts.

As the instructions below reflect, to get the most consistent possible timings and to make our hand-timed actions
more like the ones the automated scripts perform, we sometimes chose to follow procedures for launching
applications that were different from those typical users would follow. (See Appendix C for additional information
on scripting issues.) When we made such choices, we also independently verified that the typical user procedures
would still show similar results.

Consequently, we are confident that the benefits PCs delivered in these scenarios are benefits that users can
expect to realize in real work situations and are not artifacts of the measurement or scripting technology.

We ran all application scenarios five times on each of the systems under test, and we reported the median of
those runs.

The following subsections, which assume you have already completed all of the setup work in the Test
methodology section, describe how to run each of the individual scenarios.

Single task scenario: Calculating subtotals in Microsoft Excel

The application involved
• Microsoft Office Excel 2003
The data file involved
• Sales2002a1.xls, a 1.79MB Excel worksheet (located on the file server)
The script
The script for the scenario performs the following tasks:

• Open Sales2002a1.xls. (We did not time that task, because we focused on a single function.)
• Start the Excel timer, and perform the subtotal function.
• Stop the Excel timer when Excel finishes calculating the subtotals.
• Close Excel. (We did not time that task, because we focused on a single function.)

The manual process

To execute the test, follow these instructions. You will need a stopwatch.

1. Reboot the system.

2. Open Sales2002a1.xls.
3. Select Data/Subtotals...
4. Fill in the Subtotal dialog as follows:
• At each change in: Size.
• Use function: Average.
• Add subtotal to: Quantity.
• Uncheck Replace current subtotals.
5. Start stopwatch, and press OK.
6. Stop stopwatch when the Inserting Subtotals progress bar goes away and the status bar says Ready.
7. Close Excel, choosing No when Excel asks whether you want to save.

Principled Technologies, Inc.: PC vs. thin client performance in typical 30

office application scenarios
Single task scenario: Compressing a PDF from within Adobe Acrobat
The application involved
• Adobe Acrobat 7.0 Standard
The data file involved
• Computing.pdf, a 4.01MB PDF file (on the file server)
The script
The script for the scenario performs the following tasks:

• Open Computing.pdf. (We did not time that task, because we focused on a single function.)
• Start the Acrobat timer, and tell Acrobat to compress the PDF.
• Stop the Acrobat timer when the Conversion Warning dialog displays.
• Close the Conversion Warning window.
• Close Acrobat.
• Delete Compress.pdf, the file the script just created. (We did not time these three final tasks, because we
focused on a single function.)
The manual process
To execute the test, follow these instructions. You will need one stopwatch.

1. Reboot the system.

2. Open Computing.pdf.
3. Select File/Reduce File Size.
4. In Reduce File Size dialog, select Acrobat 7.0 or later.
5. Press OK.
6. In the Save As dialog, give the new file the name, Compress.
7. Start the Acrobat stopwatch, and press Save.
8. Stop the Acrobat stopwatch when a Conversion Warning dialog displays.
9. Press Enter to close the Conversion Warning dialog.
10. Exit Acrobat.
11. Delete Compress.pdf.
12. Empty the recycle bin.

Multitasking scenario: Changing the view in a Microsoft PowerPoint presentation while

compressing a folder in Windows Explorer
The applications involved
• Microsoft Windows Explorer for Windows XP Professional (Service Pack 2)
• Microsoft Office PowerPoint 2003
The data files involved
• FourFiles, a 265MB folder that the scenario uses to create a 168MB compressed (zipped) folder (on the
file server for the thin clients; local for the rich clients)
• Content.ppt, a 30.4MB Microsoft PowerPoint presentation (on the file server)
The script
The script for the scenario performs the following tasks:

• Open Windows Explorer. (We did not time this task, because it occurs outside the multitasking section of
the script.)
• Navigate to FourFiles.
• Start the timer for Explorer Compress, and start compressing FourFiles.
• Start the PowerPoint Open timer, and double-click the Content.ppt desktop shortcut.
• Stop the PowerPoint Open timer when the bottom slide in the slide viewer loads.
• Start the PowerPoint Change View timer, and select View/Slide Sorter.

Principled Technologies, Inc.: PC vs. thin client performance in typical 31

office application scenarios
 • Stop the PowerPoint Change View timer when the last slide loads in the Slide Sorter view.
• Stop the Explorer Compress timer when Explorer finishes compressing the file.
• Close all open applications. (We did not time these tasks, because they occur outside the multitasking
section of the script.)
The manual process
First, prepare each system by following these steps once:

1. Open Windows Explorer.

2. Ensure that it allows enough space on the right to allow double-clicking a desktop shortcut there.
3. Create a desktop shortcut to Content.ppt. Place it on the right side of the desktop, to the right of the
Explorer window.

To execute the test, follow these instructions. You will need three stopwatches to time three different tasks.

1. Reboot the system.

2. Open Windows Explorer.
3. Navigate to the folder that contains FourFiles.
4. Start the first stopwatch, and click Send to/Compressed (zipped) folder.
5. Start the second stopwatch, and double-click the Content.ppt desktop shortcut.
6. Stop the second stopwatch when the slide viewer finishes displaying the slides that fit in the PowerPoint
window.
7. Start the third stopwatch, and select View\Slide Sorter from the PowerPoint menu.
8. Stop the third stopwatch when the slider sorter finishes displaying the slides that fit in the PowerPoint
window.
9. Stop the first stopwatch when Explorer finishes creating the compressed FourFiles.zip.
10. Close all open applications, choosing No if any application asks whether to save changes.
11. Delete FourFiles.zip.
12. Empty the recycle bin.

Multitasking scenario: Opening large XML files in Microsoft Word and Microsoft Excel
The applications involved
• Microsoft Office Excel 2003
• Microsoft Office Word 2003
• Microsoft Windows Explorer for Windows XP Professional (Service Pack 2)
The data files involved
• SalesSummary.xml, an 11MB XML document (on the file server)
• Excel2minlarge.xml, a 28.9MB XML document (on the file server)
The script
The script for the scenario performs the following tasks:

• Open Windows Explorer. (We did not time this task, because it occurs outside the multitasking section of
the script.)
• Navigate to the directory that contains SalesSummary.xml and Excel2minlarge.xml.
• Open SalesSummary.xml and Excel2minlarge.xml, and starts one timer for the Word document open and
one timer for the Excel document open.
• Stop the Excel timer when the Excel document finishes loading and Ready appears in the lower left of the
document.
• Stop the Word timer when the Word document finishes loading and the page count on the bottom of the
page equals the actual page count of the document.
• Close all open applications. (We did not time these tasks, because they occur outside the multitasking
section of the script.)

Principled Technologies, Inc.: PC vs. thin client performance in typical 32

office application scenarios
The manual process
First, prepare each system by following these steps once:

1. Open SalesSummary.xml and Excel2minlarge.xml.

2. Arrange their windows so that both are visible and you can see at least the lower left of the Excel status
bar and enough of the Word status bar to be able to see the document page count.

To execute the test, follow these instructions. You will need two stopwatches.

1. Open Windows Explorer.

2. Navigate to the directory that contains SalesSummary.xml and Excel2minlarge.xml.
3. Select both SalesSummary.xml and Excel2minlarge.xml.
4. Start both stopwatches, and hit Enter to open both SalesSummary.xml and Excel2minlarge.xml.
5. Stop the first stopwatch when Excel finishes loading Excel2minlarge.xml and the Ready statement
appears in the lower left of the document.
6. Stop the second stopwatch when Word finishes loading SalesSummary.xml and the page count on the
bottom of the page shows 1/42.
7. Close all the applications.

Principled Technologies, Inc.: PC vs. thin client performance in typical 33

office application scenarios
Appendix C – Issues in script development
To the best of our knowledge, despite its age IBM’s Visual Test 6.5 remains the tool most widely used today for
constructing application-based benchmarks and performance tests for PCs running various versions of Microsoft
Windows. We have used this product (and previous versions of it) for many years to build performance tests. The
tool does, however, have some stated limitations that unavoidably affect the way one develops performance tests
with it.

First, the product’s own documentation notes that its primary goal is to be a tool for automating application testing,
not for benchmark development. Consequently, the granularity of some of its functions and the way some of its
functions behave are not ideal for benchmark development.

IBM also does not officially support Visual Test 6.5 for the Windows XP operating system. Because Windows XP
is the leading and most current desktop version of Windows today, we nonetheless felt it was essential to use that
operating system in our tests.

The presence of any scripting tool has the potential to affect the performance of a system. The tool unavoidably
must, for example, occupy some memory and consume some processing power. Consequently, developing a
performance-measurement script with such a tool involves maintaining a delicate balance between using the tool
to automate typical real user behavior and minimizing the effects of the tool on system performance. To make
sure the results of our scripts were accurate, we also hand-timed each of the functions we scripted.

To minimize these limitations and problems, we sometimes had to use scripting techniques that would achieve
the same results as typical user behavior but not exactly mirror that behavior. Such techniques include inserting
delays to mimic user think time and launching applications by clicking the OK button of a pre-filled Run command
line. The hand timing instructions we provide in Appendix B reflect those techniques, so following those
instructions will yield results similar to those the scripts produce. Whenever we had to use one of these alternative
techniques, we manually verified that doing so did not materially alter the way the system behaved and that real
users performing the same actions in more typical ways would see the type of performance benefits we describe.

The timings the scripts produce also inevitably contain some variability. This variability is a result of the
combination of the tool’s limitations and the generally asynchronous nature of the many processes Windows XP
and other modern operating systems have running at any given time.

Finally, though one of the goals of this effort was to produce reliable scripts, we were not trying to build bulletproof
benchmarks for wide distribution and use. We developed the scripts to mimic user behavior on our specific test
systems; on different systems the scripts might show different levels of performance benefits or even fail to work.
So, although the scripts are as reliable, self-contained, and free of system dependencies as we could reasonably
make them within the project’s timeframe, they do sometimes fail or encounter problems. Should a problem occur,
rebooting the system and running the script again will generally yield a good result.

Principled Technologies, Inc.: PC vs. thin client performance in typical 34

office application scenarios
 Principled Technologies, Inc.
4813 Emperor Blvd., Suite 100
Durham, NC 27703
www.principledtechnologies.com
[email protected]

Principled Technologies is a registered trademark of Principled Technologies, Inc.

Intel and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and
other countries. All other product names are the trademarks of their respective owners

Disclaimer of Warranties; Limitation of Liability:

PRINCIPLED TECHNOLOGIES, INC. HAS MADE REASONABLE EFFORTS TO ENSURE THE ACCURACY AND VALIDITY OF ITS
TESTING, HOWEVER, PRINCIPLED TECHNOLOGIES, INC. SPECIFICALLY DISCLAIMS ANY WARRANTY, EXPRESSED OR IMPLIED,
RELATING TO THE TEST RESULTS AND ANALYSIS, THEIR ACCURACY, COMPLETENESS OR QUALITY, INCLUDING ANY IMPLIED
WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE. ALL PERSONS OR ENTITIES RELYING ON THE RESULTS OF ANY
TESTING DO SO AT THEIR OWN RISK, AND AGREE THAT PRINCIPLED TECHNOLOGIES, INC., ITS EMPLOYEES AND ITS
SUBCONTRACTORS SHALL HAVE NO LIABILITY WHATSOEVER FROM ANY CLAIM OF LOSS OR DAMAGE ON ACCOUNT OF ANY
ALLEGED ERROR OR DEFECT IN ANY TESTING PROCEDURE OR RESULT.

IN NO EVENT SHALL PRINCIPLED TECHNOLOGIES, INC. BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES IN CONNECTION WITH ITS TESTING, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL
PRINCIPLED TECHNOLOGIES, INC.’S LIABILITY, INCLUDING FOR DIRECT DAMAGES, EXCEED THE AMOUNTS PAID IN
CONNECTION WITH PRINCIPLED TECHNOLOGIES, INC.’S TESTING. CUSTOMER’S SOLE AND EXCLUSIVE REMEDIES ARE AS SET
FORTH HEREIN.

Principled Technologies, Inc.: PC vs. thin client performance in typical 35

office application scenarios