Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

Unix

I/O

Performance

in

Workstations

and

Mainframes

Peter

M.

Chen

Computer

Science

and

Engineering

Division

Electrical

Engineering

and

Computer

Science

Department

University

of

Michigan

David

A.

Patterson

Computer

Science

and

Engineering

Division

Electrical

Engineering

and

Computer

Science

Department

University

of

California

at

Berkeley

Abstract

Rapid

advances

in

processor

performance

have

shifted

the

performance

bottleneck

to

I/O

systems

The

relatively

slow

rate

of

improvement

in

I/O

is

due

in

part

to

a

lack

of

quantitative

performance

analysis

of

software

and

hardware

alternatives

Using

a

new

self-scaling

I/O

benchmark

we

provide

such

an

evaluation

for

hardware

configurations

using

variations

of

the

Unix

operating

system

In

contrast

to

processor

performance

comparisons

where

factors

of

are

considered

large

we

find

differences

of

factors

of

to

in

I/O

systems

The

principal

performance

culprits

are

the

policies

of

different

Unix

operating

systems

some

policies

on

writes

to

the

file

cache

will

cause

processors

to

run

at

magnetic

disk

speeds

instead

of

at

main

memory

speeds

These

results

suggest

a

greater

emphasis

be

placed

on

I/O

performance

when

making

operating

system

policy

decisions

Introduction

Input/output

has

long

been

the

orphan

of

computer

architecture

receiving

little

attention

or

respect

Processor

performance

has

improved

spectacularly

thanks

to

focussed

efforts

but

Amdahl

's

Law

tells

us

that

neglecting

any

portion

of

the

computation

will

ultimately

limit

overall

performance

We

see

the

impact

of

these

limits

today

with

massively

parallel

processors

unable

to

deliver

the

promised

performance

on

some

applications

due

to

I/O

bottlenecks

This

I/O

bottleneck

looms

for

workstations

as

well

Without

advances

in

I/O

performance

advances

in

processor

design

will

be

wasted

The

first

step

in

improving

I/O

performance

is

to

understand

what

really

affects

performance

Alas

there

is

little

quantitative

evaluation

of

I/O

The

main

purpose

of

this

paper

is

to

provide

such

quantitative

information

for

Unix

I/O

A

second

purpose

is

to

explore

some

of

the

folklore

of

I/O

performance

Certainly

one

popular

saying

is

that

mainframe

computers

have

outstanding

I/O

performance

This

last

point

is

particularly

topical

as

many

customers

are

considering

replacing

their

mainframes

with

networks

of

workstations

Table

shows

the

machines

and

operating

systems

evaluated

in

this

paper

They

were

selected

to

be

representative

of

operating

systems

and

hardware

systems

in

use

today

This

selection

was

bounded

by

the

systems

available

at

the

University

of

Michigan

and

the

University

of

California

at

Berkeley

and

by

the

generosity

of

volunteers

at

other

sites

willing

to

run

our

benchmark

Our

evaluation

shows

that

I/O

performance

is

limited

by

the

weakest

link

in

the

chain

between

the

disk

and

the

operating

system

The

hardware

determines

potential

I/O

performance

but

the

operating

system

determines

how

much

of

that

potential

is

delivered

In

particular

for

Unix

systems

the

file

cache

performance

is

critical

to

I/O

performance

Our

main

observations

are

that

file

cache

performance

of

Unix

on

mainframes

and

minisupercomputers

is

no

better

than

workstations

and

that

file

caching

policy

is

of

overriding

importance

Optimized

memory

systems

can

increase

read

performance

but

the

operating

system

policy

on

writes

can

result

in

orders

of

magnitude

differences

in

file

cache

performance

These

results

are

found

in

the

next

three

sections

Sections

and

of

this

paper

evaluate

the

performance

of

disks

and

file

caches

both

assuming

a

workload

of

only

reads

Section

shows

that

operating

system

policies

for

writes

drastically

affect

I/O

performance

Section

describes

the

new

I/O

benchmark

that

we

used

to

collect

performance

data

for

this

paper

This

benchmark

has

two

components

self-scaling

and

predicted

performance

As

a

quick

overview

this

University

of

Michigan

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

benchmark

tailors

a

series

of

workloads

for

each

system

that

exercises

the

memory

system

and

the

disks

-LRB-

Previous

publications

have

recorded

the

accuracy

and

usefulness

of

this

benchmark

this

paper

relies

on

that

accuracy

and

focuses

on

using

this

benchmark

to

evaluate

I/O

performance

-RRB-

Sections

to

use

a

KB

average

access

size

with

half

of

the

accesses

being

sequential

and

the

accesses

being

generated

by

a

single

process

Multiple

runs

determine

performance

for

varying

balances

of

reads

and

writes

with

each

section

picking

the

appropriate

mix

Readers

with

more

questions

about

the

experimental

method

should

see

Section

or

read

-LSB-

-RSB-

We

conclude

this

paper

with

a

summary

of

results

a

recommendation

that

more

emphasis

in

operating

systems

be

given

to

I/O

performance

and

a

short

section

on

future

directions

Disk

Subsystem

Performance

A

comprehensive

evaluation

of

disk

performance

is

problematic

To

see

why

let?s

review

how

I/O

works

The

data

written

to

disks

comes

from

main

memory

and

main

memory

is

also

the

destination

of

data

read

from

disks

Figure

shows

there

are

many

component

between

memory

and

disks

I/O

performance

is

limited

by

the

slowest

component

between

memory

and

disks

it

can

be

the

main

memory

the

CPU-memory

bus

the

bus

adapter

the

I/O

bus

the

I/O

controller

or

the

disks

themselves

The

trend

towards

open

systems

exacerbates

the

complexity

of

measuring

I/O

performance

for

a

particular

machine

can

be

configured

with

many

different

kinds

of

disks

disk

controllers

and

even

I/O

busses

In

addition

to

Table

Machines

and

operating

systems

evaluated

in

this

paper

Note

that

the

oldest

machines

is

the

Convex

which

first

shipped

in

AIX/ESA

is

run

under

VM

because

there

are

not

enough

people

at

that

installation

to

justify

running

it

native

For

cache

parameters

the

first

level

-LRB-

-RRB-

number

is

the

instruction

cache

size

and

the

second

number

is

the

data

cache

size

a

single

number

means

a

unified

cache

Computer

Alpha

AXP

DecStation

DecStation

HP

IBM

RS

Sun

SparcStation

Sun

SparcStation

Convex

IBM

Operating

System

-LRB-

-RRB-

Sprite

LFS

Ultrix

A

HP/UX

AIX

SunOS

Solaris

ConvexOS

AIX/ESA

on

VM

Processor

Model

400 200 200 730

VF

Year

Proc

Shipped

1993 1990 1990 1991

1991 1989 1992 1988

Approx

as

tested

k

Proc

Clock

Rate

MHz

MHz

MHz

MHz

MHz

MHz

MHz

MHz

MHz

Proc

Perf

Cache

Size

-LRB-

Levels

-RRB-

KB

KB

KB

KB

KB

KB

KB

KB

MB

KB

Memory

Size

MB

MB

MB

MB

MB

MB

MB

MB

MB

VM

partition

Memory

Perf

MB/s

MB/s

MB/s

MB/s

MB/s

MB/s

MB/s

MB/s

I/O

bus

Turbochannel

SCSI-I

SCSI-I

Fast

SCSI-II

SCSI

SCSI-I

SCSI-I

IBM

Channel

Disk

-LRB-

s

-RRB-

SCSI

DEC

CDC

Wren

-LRB-

RAID

-RRB-

DEC

HP

IBM

CDC

Wren

IV

Seagate

Elite

-LRB-

RPM

-RRB-

DKD

-LRB-

RAID

-RRB-

IBM

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

the

hardware

components

the

policies

of

the

operating

system

affect

I/O

performance

of

a

workload.The

sheer

number

of

combinations

of

components

leads

to

less

than

satisfying

results

for

the

conclusions

we

can

draw

from

a

few

data

points

are

limited

If

we

were

interested

in

comparing

I/O

performance

of

hardware-software

systems

then

ideally

we

would

use

many

of

the

same

components

to

reduce

the

number

of

variables

This

ideal

has

several

practical

obstacles

First

few

workstations

manufacturers

share

the

same

operating

system

CPU

or

CPU-memory

bus

so

they

may

be

unique

to

each

machine

And

a

different

CPU-memory

bus

requires

a

different

bus

adaptor

This

leaves

the

I/O

bus

I/O

controller

and

disks

to

be

potentially

in

common

The

problem

now

is

that

there

is

no

standard

configuration

of

these

components

across

manufacturers

so

it

is

unlikely

that

customers

would

normally

buy

the

same

configuration

from

different

manufacturers

This

leaves

the

evaluator

the

unattractive

alternative

of

purchasing

computer

systems

with

common

I/O

subsystems

simply

to

evaluate

performance

few

organizations

have

the

budgets

for

such

an

ef

fort

Practical

hope

for

more

general

results

depends

on

an

I/O

benchmark

becoming

so

popular

that

many

combinations

of

components

on

each

machine

would

be

tested

possibly

requiring

dozens

of

different

configurations

per

model

of

processor

Until

an

I/O

benchmark

becomes

nearly

universal

we

won?t

have

enough

data

points

to

generalize

safely

about

classes

of

computers

Section

describes

one

I/O

benchmark

that

has

the

potential

to

evaluate

many

different

I/O

systems

We

can

now

present

our

results

in

proper

context

Figure

shows

disk

performance

when

reading

for

the

machines

in

Table

The

Convex

minisupercomputer

with

the

RAID

of

four

disks

and

the

fast

I/O

bus

is

at

the

top

of

the

chart

the

SPARCStation

is

second

due

to

its

the

fast

single

disk

The

mainframe

with

its

single

disk

comes

in

a

surprisingly

low

sixth

place

Given

the

warnings

above

we

can

not

say

that

IBM

mainframes

have

lower

disk

performance

than

workstations

nor

that

Convex

has

the

fastest

disk

subsystem

We

can

say

that

the

IBM

running

AIX/ESA

under

VM

performs

KB

reads

to

a

single

IBM

disk

drive

much

more

slowly

than

a

Convex

running

ConvexOS

reads

KB

blocks

from

a

RAID

It

is

not

clear

what

would

happen

for

example

if

many

disks

were

used

on

the

IBM

mainframe

or

if

another

operating

system

ran

on

the

mainframe

The

conclusions

we

draw

from

Figure

are

that

many

workstation

I/O

subsystems

can

sustain

the

performance

of

a

high-speed

single

disk

that

a

RAID

disk

array

can

deliver

much

higher

performance

and

that

the

performance

of

a

single

mainframe

disk

on

a

model

running

AIX/ESA

under

VM

is

no

faster

than

many

workstations

Figure

Basic

components

of

an

I/O

subsystem

The

I/O

bus

is

also

called

a

string

with

the

I/O

controller

called

a

string

controller

The

lowest

performance

component

between

memory

and

disks

limits

disk

performance

seen

by

the

application

CacheI/O

busI/OcontrollerDiskDiskGraphicsoutputNetworkI/OcontrollerI

Ocontrolle

rCPU?memory

busCPUBusadapterMainmemory

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

Basic

File

Cache

Performance

For

Unix

systems

the

most

important

factor

in

I/O

performance

is

not

how

fast

the

disk

is

or

how

efficiently

it

is

used

but

whether

it

is

used

Unix

systems

use

a

file

cache?a

buffer

in

main

memory?to

reduce

accesses

to

disks

-LSB-

-RSB-

found

that

in

one

Unix

workstation

environment

file

caches

fulfill

of

the

data

read

requests

depending

on

the

size

of

file

cache

-LSB-

-RSB-

found

that

accesses

to

fi

le

meta

data

had

even

higher

success

rates

Since

main

memory

is

much

faster

than

disks

file

caches

yield

a

substantial

performance

improvement

and

are

found

in

every

Unix

operating

system

One

portion

of

our

benchmark

varies

its

workload

to

be

sure

to

access

only

the

file

cache

when

measuring

performance

of

a

system

Figure

shows

this

file

cache

performance

for

the

machines

of

Table

The

first

thing

to

notice

is

the

change

in

scale

of

the

chart

machines

read

from

their

file

caches

to

times

faster

than

from

their

disks

The

performance

of

the

file

cache

is

determined

by

the

processor

cache

CPU-memory

bus

main

memory

and

operating

system

Except

for

the

size

of

memory

and

perhaps

the

operating

system

there

is

little

choice

in

these

components

when

selecting

a

computer

Hence

observations

about

commercial

systems

can

be

drawn

about

file

cache

performance

with

much

more

confidence

than

with

the

disks

since

this

portion

of

the

system

will

be

common

at

most

sites

The

biggest

surprise

is

that

the

mainframe

and

minisupercomputers

did

not

dominate

this

chart

given

their

much

greater

cost

and

reputation

for

high-bandwidth

memory

systems

and

CPU-memory

busses

The

four

top

performers

are

DEC

Alpha

IBM

model

HP

and

IBM

running

AIX

all

with

file

cache

performance

of

approximately

MB/s

This

chart

also

shows

rapid

file

cache

improvement

in

workstations

For

example

both

the

SPARCStation

and

DEC

Alpha

are

more

than

four

times

faster

than

their

predecessors

the

SPARCStation

and

the

DECStation

In

addition

Figure

shows

the

impact

of

operating

systems

on

I/O

performance

the

Sprite

operating

system

offers

times

the

file

cache

performance

of

Ultrix

running

on

the

same

DECStation

hard

Figure

Disk

performance

for

the

machines

in

Table

These

results

are

for

reads

of

KB

Except

where

otherwise

noted

in

the

figure

the

machines

use

SCSI

I/O

buses

SCSI

controllers

and

SCSI

disks

that

rotate

at

RPM

Read

performance

is

from

to

times

faster

than

write

performance

except

for

the

Sprite

system

Sprite?s

Log-Structured

File

System

is

optimized

for

writes

which

are

times

faster

than

reads

on

the

DS

-LRB-

Section

explains

the

measurement

method

of

data

collection

we

started

with

the

measured

read

performance

at

nominal

access

sizes

and

then

interpolated

to

determine

performance

for

a

common

KB

access

size

The

only

numbers

adjusted

by

more

than

was

for

the

Convex

Table

shows

the

multipliers

used

for

interpolation

-RRB-

Machine

and

Operating

System

Megabytes

per

Second

Sprite

Ultrix

SunOS

AIX/ESA

HP

HP/UX

AIX

SS

Solaris

Convex

RAID

RPM

SCSI-II

disk

IBM

Channel

IBM

Disk

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

ware

Sprite

does

fewer

copies

when

reading

data

from

the

file

cache

than

does

Ultrix

-LSB-

-RSB-

hence

its

higher

performance

The

Impact

of

Operating

System

Policies

on

File

Cache

Performance

Given

that

Unix

systems

have

common

ancestors

we

expected

that

the

operating

system

policies

towards

I/O

to

be

the

same

on

all

machines

Instead

we

find

that

different

systems

have

very

different

I/O

policies

and

some

policies

alter

I/O

performance

by

factors

of

to

These

machines

are

aimed

largely

at

the

same

customers

running

the

same

applications

which

calls

into

question

the

low

performance

of

some

of

these

policies

One

reason

for

this

wide

variation

may

be

the

sparsity

of

published

results

comparing

file

cache

performance

on

several

workstations

and

operating

systems

-LRB-

-LSB-

-RSB-

is

one

of

the

few

recent

examples

-RRB-

and

so

there

has

been

little

quantitative

input

into

these

decisions

File

Cache

Size

Since

main

memory

must

be

used

for

running

programs

as

well

as

for

the

file

cache

the

first

policy

decision

is

how

much

main

memory

should

be

allocated

to

the

file

cache

The

second

is

whether

or

not

the

size

of

the

file

cache

can

change

dynamically

Early

Unix

systems

give

the

file

cache

a

fixed

percentage

of

main

memory

this

percentage

is

determined

at

the

time

of

system

generation

and

is

typically

set

to

More

recent

systems

allow

the

barrier

between

file

cache

and

program

memory

to

vary

allowing

file

caches

to

grow

to

be

virtually

the

full

size

of

main

memory

if

warranted

by

the

workload

-LSB-

-RSB-

File

servers

for

example

will

surely

use

much

more

of

their

main

memory

for

file

cache

than

will

most

client

workstations

Our

benchmark

varies

the

amount

of

data

and

measures

performance

to

determine

the

maximum

file

cache

size

for

each

system

Figure

shows

these

maximum

file

cache

sizes

both

in

absolute

size

and

as

a

percentage

of

main

memory

The

reason

for

the

large

variation

in

percentage

of

main

memory

is

the

fi

le

cache

size

policy

HP/UX

version

Ultrix

and

AIX/ESA

all

reserve

small

fixed

portions

of

main

memory

Figure

File

cache

performance

for

machines

in

Table

This

plot

is

for

KB

reads

with

the

number

of

bytes

touched

limited

to

fit

within

the

file

cache

of

each

system

-LRB-

Section

explains

the

measurement

method

of

data

collection

we

started

with

the

measured

read

performance

for

accesses

within

the

respective

file

caches

at

nominal

access

sizes

and

then

interpolated

to

determine

performance

for

a

common

KB

size

Table

shows

the

factors

the

only

numbers

adjusted

by

more

than

were

for

the

Convex

-RRB-

Machines

and

Operating

Systems

Megabytes

per

Second

SunOS

Ultrix

Sprite

Convex

SS

Solaris

AIX/ESA

HP

HP/UX

AIX

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

for

the

fi

le

cache

HP/UX

version

in

contrast

supports

dynamically

varying

file

cache

size

leading

to

an

lar

ger

file

cache

for

the

HP

-LSB-

-RSB-

demonstrated

that

Unix

workloads

benefit

from

larger

file

caches

so

this

fixed-size

policy

surely

hurts

I/O

performance

Note

that

Sprite

running

on

the

same

hardware

as

Ultrix

has

more

than

six

Figure

File

cache

size

The

bar

graph

shows

the

maximum

percentage

of

main

memory

for

the

fi

le

cache

in

the

I/O

workload

of

Section

while

the

line

graph

shows

the

maximum

size

in

MB

using

the

log

scale

on

the

right

Thus

the

HP

HP/UX

version

uses

only

of

its

MB

main

memory

for

its

file

cache

or

just

MB

and

the

Convex

uses

of

its

MB

main

memory

or

MB

to

be

its

file

cache

-LRB-

Section

explains

that

the

Sprite

file

cache

really

has

two

components

is

the

size

of

the

lar

ger

one

-RRB-

Main

Memory

for

FIle

Cache

HP/UX

Sprite

SunOS

SS

Solaris

Alpha

AIX

HP/UX

Convex

File

Cache

Size

-LRB-

MB

-RRB-

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

times

the

file

cache

size

and

that

the

SPARCStation

has

a

file

cache

almost

as

large

as

the

IBM

even

though

the

mainframe

has

four

times

the

physical

memory

of

the

workstation

When

the

flexible

file

cache

boundary

policy

is

combined

with

large

main

memories

we

can

get

astounding

file

caches

the

Convex

file

cache

is

almost

MB

Thus

workloads

that

would

require

disk

accesses

on

other

machines

will

instead

access

main

memory

on

the

Convex

Write

Policy

Thus

far

we

have

unrealistically

left

the

O

out

of

I/O

There

is

often

some

confusion

about

the

definition

and

implications

of

alternative

write

strategies

for

caches

To

lessen

that

confusion

we

first

review

write

policies

of

processor

caches

-LRB-

Readers

interested

in

more

about

caches

can

consult

textbooks

such

as

-LSB-

-RSB-

-RRB-

The

simplest

write

policy

is

write-through

writes

update

the

cache

and

the

next

level

of

the

memory

hierarchy

behind

the

cache

To

offer

reasonable

write

performance

almost

all

write-through

caches

use

a

write

buffer

the

write

buffer

allows

the

processor

to

continue

immediately

after

writing

the

data

to

the

cache

and

the

buffer

the

buffer

then

writes

to

the

next

level

of

the

memory

hierarchy

while

the

processor

does

other

work

The

operating

systems

community

uses

the

terms

asynchronous

writes

or

delayed

writes

for

writes

that

allow

the

processor

to

continue

after

updating

the

write

buffer

If

writes

occur

infrequently

then

this

buffer

works

well

if

writes

are

frequent

then

the

processor

may

eventually

have

to

stall

until

the

write

buffer

empties

limiting

the

speed

to

that

of

the

next

level

of

the

memory

hierarchy

Note

that

a

writebuffer

does

not

reduce

the

number

of

writes

to

the

next

level

it

just

allows

the

processor

to

continue

while

I/O

is

in

progress

provided

the

write-buffer

is

not

full

Because

all

writes

must

go

to

disk

in

a

writethrough

file

cache

we

expect

the

write

throughput

of

such

a

system

to

be

limited

by

disk

speeds

The

alternative

write

policy

to

write-through

is

called

write-back

writes

simply

update

the

cache

block

setting

a

dirty

bit

so

that

the

processor

knows

it

must

write

the

block

to

memory

when

it

is

replaced

Multiple

updates

to

the

same

location

simply

re-write

the

appropriate

file

cache

blocks

cancelling

earlier

writes

to

that

location

write-through

caches

in

contrast

send

every

write

to

the

next

level

of

the

memory

hierarchy

Because

this

ability

to

cancel

writes

drastically

changes

system

performance

for

writes

and

because

there

has

been

confusion

about

the

distinction

between

write-through

with

write

buffers

versus

write-back

we

categorize

systems

as

being

either

write-through

-LRB-

all

writes

must

go

through

to

disk

-RRB-

or

write-cancelling

The

effectiveness

of

caches

for

writes

also

depends

on

the

policy

of

flushing

dirty

data

to

the

disk

to

protect

against

losing

information

in

case

of

failures

a

flushing

process

-LRB-

also

called

a

write-back

update

or

sync

daemon

-RRB-

will

occasionally

issue

a

command

that

forces

modified

data

out

of

the

cache

and

onto

the

disk

Most

Unix

operating

systems

have

a

policy

of

periodically

writing

dirty

data

to

disk

to

limit

the

amount

of

data

that

can

be

lost

in

a

crash

typically

the

window

is

seconds

-LSB-

-RSB-

Though

the

flushing

process

causes

more

data

to

be

written

to

disk

it

should

not

have

a

major

effect

on

the

performance

of

applications

that

stay

in

the

file

cache

This

is

because

such

applications

touch

only

file

cache

blocks

while

the

flushing

process

operating

in

the

background

mainly

uses

the

disk

That

is

the

application

should

never

have

to

wait

for

the

flushing

process

Figure

shows

the

file

cache

performance

as

we

vary

the

mix

of

reads

and

Clearly

HP/UX

-LRB-

both

with

a

second

and

infinite

flushing

interval

-RRB-

Sprite

and

with

write-cancellation

use

a

write-cancelling

cache

because

they

perform

writes

at

a

speed

faster

than

the

disk

system

can

sustain

While

it

is

hard

to

see

using

this

figure

the

Sun

OS

write

performance

is

nearly

as

fast

as

reads

and

much

faster

than

disks

so

it

also

cancels

writes

We

can

tell

that

the

other

operating

systems

use

writethrough

because

their

write

performance

matches

disk

speed

Note

that

three

of

the

highest

performers

in

Figure

IBM

and

Alpha

-LRB-

with

write-through

-RRB-

fall

to

the

back

of

the

pack

unless

the

percentage

of

reads

is

over

A

write-cancelling

cache

-LRB-

independent

of

the

flushing

interval

-RRB-

should

perform

at

memory

speeds

for

both

reads

and

writes

hence

their

lines

should

be

fairly

fl

at

in

Figure

Of

the

systems

in

Figure

that

cancel

writes

this

holds

true

for

Sprite

SunOS

and

HP/UX

with

an

infi

nite

flushing

interval

The

others

-LRB-

HP/UX

with

flushing

and

with

write-cancellation

and

infi

nite

flushing

interval

-RRB-

per

-LRB-

The

confusion

alluded

to

above

concerns

the

difference

between

write

buffers

and

write-back

some

of

the

developers

we

talked

to

insisted

that

their

systems

were

using

write-back

when

they

were

using

write-through

with

a

write

buffer

-RRB-

For

we

show

performance

with

the

system

configured

to

be

write-through

-LRB-

the

default

-RRB-

and

also

configured

as

write-cancelling

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

form

writes

much

slower

than

reads

To

investigate

this

further

we

lengthened

the

flushing

interval

for

HP/UX

to

infinity

this

caused

a

huge

increase

in

write

performance

from

MB/s

to

MB/s

Note

that

both

these

numbers

are

higher

than

disk

performance

yet

somehow

the

flushing

process

slows

performance

by

a

factor

of

four

In

further

measurements

we

found

that

this

phenomenon

is

less

pronounced

Figure

File

cache

performance

vs.

read

percentage

reads

means

writes

Note

that

the

high

performance

of

the

file

caches

of

the

and

-LRB-

write-through

-RRB-

are

only

evident

for

workloads

with

reads

Systems

with

write-cancelling

performance

are

shown

in

bold

with

underlined

labels

Access

sizes

are

KB

-LRB-

Section

explains

the

measurement

method

of

data

collection

we

started

with

the

measured

performance

for

accesses

within

the

respective

file

caches

at

nominal

access

sizes

and

then

interpolated

to

determine

performance

for

a

common

KB

size

The

only

numbers

adjusted

by

more

than

was

for

the

Convex

Table

shows

the

multipliers

Section

also

explains

the

Sprite

file

cache

really

has

two

components

this

is

performance

for

the

smaller

one

-RRB-

write-cancelling

Solaris

-LRB-

-RRB-

HP/UX

HP/UX

infi

nite

flushing

interval

-LRB-

HP

-RRB-

Convex

Sprite

-LRB-

-RRB-

Ultrix

-LRB-

-RRB-

Sun

OS

-LRB-

-RRB-

Reads

Megabytes

per

Second

infinite

flushing

interval

-LRB-

AXP

-RRB-

-LRB-

AXP

-RRB-

AIX

-LRB-

-RRB-

write-through

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

when

touching

less

MB

-LRB-

Figure

-RRB-

We

hypothesize

that

once

the

flushing

process

schedules

a

block

to

be

written

to

disk

it

locks

the

file

cache

block

and

any

future

application

writes

to

that

block

must

wait

for

the

disk

write

to

complete

Applications

that

touch

less

MB

create

less

work

for

the

flushing

process

to

do

hence

the

flushing

process

does

not

slow

those

application

as

drastically

The

short

lives

of

files

means

that

files

will

be

deleted

or

overwritten

and

so

their

data

need

not

be

written

to

disk

Baker

et

al

found

that

this

window

captures

to

of

the

lifetimes

for

all

files

-LSB-

-RSB-

Their

paper

claims

this

percentage

represents

only

small

files

and

so

almost

all

data

is

written

through

In

a

correction

to

that

claim

Hartman

and

Ousterhout

reported

that

to

of

the

bytes

written

do

not

survive

a

second

window

this

number

jumps

to

to

in

a

second

window

-LSB-

-RSB-

According

to

another

study

a

small

non-volatile

file

cache

can

reduce

write

traffic

by

-LSB-

-RSB-

Given

that

such

short

lifetimes

mean

that

file

cache

blocks

will

be

rewritten

we

recommend

that

all

operating

system

developers

consider

using

a

write-cancellation

policy

enabling

writes

to

the

fi

le

cache

to

perform

at

memory

speeds

Write

Policy

for

Client/Server

Computing

Thus

far

we

have

been

ignoring

the

network

and

the

possibility

that

the

files

exist

on

a

file

server

We

tested

this

performance

with

two

experiments

one

experiment

used

one

SPARCStation

as

client

and

another

as

a

server

and

a

second

experiment

using

a

HP

as

a

client

and

a

HP

as

a

server

Both

client-server

pairs

were

connected

by

an

Ethernet

local

area

network

Figure

shows

file

cache

performance

versus

the

percentage

of

reads

when

the

files

are

reached

over

the

networks

This

experiment

brings

us

to

the

issue

of

consistency

of

files

in

multiple

file

caches

The

concern

is

that

multiple

copies

of

files

in

the

client

caches

and

on

the

server

create

the

possibility

that

someone

will

access

the

wrong

version

of

the

data

This

brings

us

to

a

policy

decision

how

to

ensure

that

no

one

accesses

stale

data

The

NFS

solution

used

by

SunOS

is

to

make

all

client

writes

go

to

the

server

s

disk

when

the

file

is

closed

-LSB-

-RSB-

Taking

an

outsider

s

perspective

it

seems

inconsistent

that

a

second

delay

would

be

satisfactory

for

writes

to

local

disk

but

not

for

writes

to

the

server

disk

Hence

HP/UX

offers

an

alternative

network

protocol

called

DUX

which

allows

client-level

caching

of

writes

The

server

keeps

track

of

potential

conflicts

and

takes

the

appropriate

action

only

when

the

file

is

shared

and

someone

is

writing

it

Using

a

shared

bus

multiprocessor

as

a

rough

analogy

to

our

workstations

on

the

local

area

network

DUX

offers

write-cancellation

with

cache

coherency

while

NFS

does

write

through

without

write

buffers

Readers

interested

in

more

details

of

file

cache

policies

should

see

-LSB-

-RSB-

Figure

File

cache

performance

vs.

percentage

of

reads

for

client-server

computing

Using

a

SPARCStation

for

both

a

client

and

the

file

server

running

NFS

is

literally

a

hundred

times

slower

than

a

HP

client

using

a

HP

server

running

the

DUX

network

file

system

-LRB-

These

are

results

as

measured

with

nominal

average

access

sizes

of

KB

for

Sparc

and

KB

for

HP

Interpolating

to

a

common

KB

size

would

increase

performance

of

Sparc

by

and

HP

by

-RRB-

DUX

NFS

Reads

Megabytes

per

Second

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

The

read

case?the

rightmost

portion

of

the

graph?shows

the

differences

in

performance

of

the

HP

and

Sparc

hardware

where

HP

is

times

faster

The

rest

of

the

graph

shows

the

differences

in

performance

due

to

the

write

policies

of

their

operating

systems

The

HP

system

is

the

clear

winner

it

is

literally

times

faster

than

the

Sparc

system

in

workloads

with

mostly

writes

and

still

times

faster

even

when

only

of

the

accesses

are

writes

Put

another

way

for

all

but

the

most

heavily

read-oriented

workloads

the

SPARCStation

client

operates

at

disk

speed

while

the

HP

client

runs

at

main

memory

speed

Adding

non-volatile

RAM

such

as

Legato

System?s

Prestoserve

board

would

increase

NFS

performance

somewhat

-LSB-

-RSB-

However

writing

through

to

NVRAM

on

a

server

is

still

limited

by

network

speeds

In

this

experiment

Ethernet

would

limit

write

performance

of

NFS

to

MB/s

A

New

I/O

benchmark

Self-scaling

and

Predicted

Performance

This

section

describes

the

I/O

benchmark

used

to

collect

the

data

seen

in

the

prior

sections

Current

I/O

benchmarks

suffer

from

several

chronic

problems

they

quickly

become

obsolete

they

do

not

stress

the

I/O

system

and

they

do

not

help

in

understanding

I/O

system

performance

-LSB-

-RSB-

This

led

to

a

new

approach

to

I/O

performance

analysis

-LSB-

-RSB-

The

first

step

is

a

self-scaling

benchmark

that

automatically

and

dynamically

adjusts

aspects

of

its

workload

according

to

the

performance

characteristics

of

the

system

being

measured

By

doing

so

the

benchmark

automatically

scales

across

a

wide

range

of

current

and

future

systems.This

scaling

is

more

general

than

the

scaling

found

in

TPC-B

-LSB-

-RSB-

and

LADDIS

-LSB-

-RSB-

for

scaling

here

varies

more

than

the

load

on

the

system

This

first

step

aids

in

understanding

system

performance

by

reporting

how

performance

varies

according

to

each

of

five

workload

parameters

these

parameters

determine

the

first-order

performance

effects

in

I/O

systems

The

benchmark

reports

throughput

however

response

time

can

easily

be

calculated

for

any

given

workload

according

to

Little?s

Law

since

concurrency

and

request

size

are

known

Here

are

the

five

I/O

parameters

Number

of

unique

bytes

touched

This

is

the

number

of

unique

data

bytes

read

or

written

in

a

workload

essentially

it

is

the

total

size

of

the

data

set

It

models

locality

using

the

LRU

stack

model

with

the

average

access

depth

in

the

LRU

stack

set

at

half

this

parameter

-LSB-

-RSB-

The

benchmark

varies

this

parameter

to

reveal

file

cache

size

-LRB-

Figure

-RRB-

Percentage

of

reads

The

percentage

of

writes

is

minus

this

percentage

Once

the

size

of

the

files

cache

were

determined

we

measured

its

performance

as

the

read

percentage

varied

to

plot

Figures

and

We

also

used

the

read

performance

results

for

the

disks

and

file

caches

to

plot

Figures

and

Average

I/O

request

size

We

chose

sizes

from

a

Bernoulli

distribution

with

a

coef

ficient

of

variation

equal

to

Percentage

of

sequential

requests

This

is

the

percentage

of

requests

that

sequentially

follow

the

prior

request

When

set

at

half

of

the

accesses

are

to

the

next

sequential

address

Number

of

processes

This

is

the

concurrency

in

the

workload

that

is

the

number

of

processes

simultaneously

issuing

I/O

Load

can

further

be

adjusted

by

varying

the

amount

of

time

a

process

thinks

between

I/Os

-LRB-

CPU

think

time

-RRB-

For

this

paper

we

set

CPU

think

time

to

zero

to

maximally

exercise

the

I/O

system

This

allows

us

to

look

at

how

well

these

memory

system

designs

and

operating

system

policies

will

work

with

the

much

faster

CPUs

of

the

future

The

general

idea

of

the

benchmark

is

to

vary

a

single

parameter

while

the

other

four

parameters

remain

at

a

fixed

nominal

value

For

the

machines

reported

in

this

paper

the

nominal

values

are

reads

sequential

accesses

and

a

single

process

issuing

I/O

requests

Because

of

the

very

different

performance

for

file

cache

and

disk

accesses

the

benchmark

automatically

picks

two

values

for

number

of

bytes

accessed

-LRB-

If

there

were

a

third

region

of

very

different

performance

it

would

add

that

value

to

be

explored

see

-LSB-

-RSB-

for

more

details

on

picking

parameters

-RRB-

Table

shows

the

nominal

values

selected

for

the

machines

and

operating

systems

in

this

paper

The

parameters

of

Table

can

be

considered

workloads

that

use

the

resources

of

the

machine

effectively

For

example

the

RAID

system

of

the

Convex

achieves

significantly

higher

bandwidth

with

larger

average

access

sizes

hence

the

larger

nominal

access

size

of

KB

Another

example

is

the

modest

size

of

main

memory

and

fixed

file

cache

size

policy

of

the

DECStation

running

Ultrix

are

refl

ected

in

the

number

of

bytes

touched

just

MB

The

resulting

I/O

performance

is

then

plotted

for

each

of

the

parameters

These

plots

can

contain

some

surprises

For

example

Figure

plots

performance

versus

the

first

parameter

the

number

of

unique

bytes

for

the

Sprite

and

Ultrix

operating

systems

running

on

the

DECStation

The

Sprite

curve

shows

three

performance

plateaus

to

MB

to

MB

and

MB

This

middle

plateau

was

auto

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

matically

uncovered

by

the

self-scaling

benchmark

it

discovered

that

reads

were

much

faster

than

writes

in

this

plateau

This

is

due

to

the

effective

write

cache

of

Sprite

's

Log

Structure

File

System

-LRB-

LFS

-RRB-

being

much

smaller

than

the

read

cache

so

reads

are

cached

in

this

region

while

writes

are

not

The

write

cache

of

LFS

is

smaller

because

LFS

limits

the

number

of

dirty

cache

blocks

to

avoid

deadlock

during

cleaning

For

writes

the

ef

fective

file

cache

size

is

only

MB

while

for

reads

it

is

MB

This

result

surprised

the

Sprite

developers

and

it

demonstrates

the

value

of

a

benchmark

that

automatically

explores

the

parameter

space

over

a

benchmark

with

a

fixed

set

of

parameters

Figure

shows

the

performance

for

recent

workstations

and

mainframes

using

the

nominal

parameters

values

collected

by

the

self-scaling

benchmark

once

again

as

a

function

of

unique

bytes

touched

These

plots

give

insights

into

appropriate

workloads

and

resulting

performance

The

width

of

the

high-performance

parts

of

the

curves

is

determined

by

the

size

of

the

file

cache

Under

default

operating

system

configurations

the

HP

offers

the

highest

performance

for

applications

that

touch

a

small

amount

of

Table

The

values

of

the

parameters

selected

automatically

by

the

self-scaling

benchmark

for

the

systems

in

Table

The

nominal

values

of

the

other

parameters

are

reads

sequential

accesses

and

one

process

-LRB-

As

explained

below

the

Sprite

DS

file

cache

has

two

sizes

-RRB-

DEC

AXP

DEC

DS

Sprite

DEC

DS

Ultrix

HP

IBM

Sun

SS

Sun

SS

Convex

IBM

Average

Access

Size

-LRB-

KB

-RRB-

No

MB

Touched

File

Cache

No

MB

Touched

Disk

80 42 157 1376

Figure

I/O

performance

of

two

operating

systems

on

the

DECStation

varying

the

number

of

megabytes

accessed

Note

that

the

X

axis

is

on

a

log

scale

The

small

size

and

write-through

policy

of

the

Ultrix

file

cache

explain

its

low

performance

The

Sprite

curve

shows

three

performance

plateau

see

the

accompanying

text

for

an

explanation

-LRB-

Results

are

as

measured

with

reads

adjusting

for

common

access

sizes

would

make

no

relative

difference

in

these

two

curves

-RRB-

Sprite

Ultrix

Number

of

MB

Touched

Megabytes

per

Second

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

yet

workloads

that

would

need

to

go

to

disk

on

other

systems

can

be

satisfied

by

the

very

large

fi

le

cache

of

the

Convex

The

self-scaling

benchmark

increases

our

understanding

of

a

system

and

scales

the

workload

to

remain

relevant

as

technology

advances

It

complicates

the

task

of

comparing

results

from

two

systems

however

The

problem

is

the

benchmark

may

choose

different

workloads

on

which

to

measure

each

sys

Without

the

flushing

process

applications

on

the

HP

can

get

very

high

performance

-LRB-

MB/s

-RRB-

with

up

to

MB

of

file

space

Figure

Performance

vs.

megabytes

touched

for

recent

workstations

and

the

mainframes

in

this

paper

Note

the

log-log

scale

In

contrast

to

other

figures

these

results

use

the

nominal

values

selected

by

the

self

scaling

benchmark

The

primary

difference

is

the

use

of

reads

and

an

average

access

size

of

KB

for

the

Convex

adjusting

for

a

common

access

size

would

halve

Convex

performance

but

make

little

change

to

the

other

lines

in

this

plot

10 100 1000

Number

of

MB

Touched

Megabytes

per

Second

HP

-LRB-

default

-RRB-

HP

infinite

fl

ushing

interval

AXP

write-cancelling

infinite

fl

ushing

interval

AXP

-LRB-

default

-RRB-

SPARCStation

Convex

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

tem

Also

although

the

output

graphs

from

a

self-scaling

evaluation

apply

to

a

wider

range

of

applications

than

today

's

I/O

benchmarks

they

stop

short

of

applying

to

all

workloads

Hence

the

second

part

of

this

new

approach

is

to

estimate

performance

of

other

workloads

We

estimate

performance

for

unmeasured

workloads

by

assuming

the

shape

of

a

performance

curve

for

one

parameter

is

independent

of

the

values

of

the

other

parameters

This

assumption

leads

to

an

overall

performance

equation

of

where

X

Y

Z

are

the

parameters

Thus

to

use

the

same

average

access

sizes

in

Figures

and

we

adjusted

performance

in

the

self-scaling

benchmark

plot

by

the

ratio

of

the

performance

at

KB

to

the

performance

at

the

nominal

access

size

-LRB-

see

Table

in

the

Appendix

-RRB-

-LSB-

-RSB-

has

shown

that

this

technique

yields

accurate

performance

estimates

within

for

most

workloads

This

paper

is

a

perfect

example

of

the

use

of

predicted

performance

We

came

into

this

paper

without

preconceived

notions

about

what

the

results

should

be

much

less

what

values

to

set

the

nominal

parameters

The

results

from

a

single

run

of

the

self-scaling

benchmark

were

used

to

discover

the

problems

about

write

policy

for

file

caches

Although

it

would

be

possible

to

go

back

to

all

systems

and

rerun

the

workloads

with

a

common

block

size

and

percentage

of

reads

thereby

making

the

collection

of

data

of

other

parameters

unnecessary

there

is

little

reason

to

do

so

The

numbers

collected

in

the

original

pass

are

close

for

all

but

one

system

It

seems

difficult

to

justify

such

a

new

run

it

would

take

weeks

to

arrange

time

to

remeasure

systems

and

new

measurements

would

not

change

our

conclusions

Readers

interested

in

a

copy

of

the

self-scaling

benchmark

can

obtain

it

via

anonymous

FTP

from

the

Internet

host

ftp.cs.Berkeley.EDU

under

the

directory

ucb/benchmarks/pmchen

Conclusion

Using

a

new

approach

to

I/O

benchmarking?self

scaling

evaluation

and

predicted

performance?we

have

evaluated

I/O

performance

of

hardware/software

systems

As

mentioned

in

the

introduction

I/O

is

limited

by

the

weakest

link

in

the

chain

between

the

disk

and

the

operating

system

The

hardware

determines

the

potential

I/O

performance

but

the

operating

system

determines

how

much

of

that

potential

is

delivered

We

have

found

differences

of

factors

of

given

processor

battles

are

won

or

lost

on

factors

of

I/O

seems

ripe

for

attention

and

respect

This

benchmark

exercises

I/O

systems

exclusively

and

while

many

systems

are

not

yet

I/O

bound

the

continuing

per

year

advance

in

processor

speed

suggests

most

will

soon

become

so

As

a

result

of

the

studies

in

this

paper

we

conclude

File

cache

performance

in

workstations

is

improving

rapidly

with

over

four-fold

improvements

in

three

years

for

DEC

-LRB-

vs.

DECStation

-RRB-

and

Sun

-LRB-

SPARCStation

vs.

SPARCStation

-RRB-

File

cache

performance

of

Unix

on

mainframes

and

minisupercomputers

is

no

better

than

on

workstations

Current

workstations

can

take

advantage

of

high

performance

disks

RAID

systems

can

deliver

much

higher

disk

performance

File

caching

policy

determines

performance

of

most

I/O

events

and

hence

is

the

place

to

start

when

trying

to

improve

I/O

performance

Given

the

wide

range

of

performance

from

systems

aimed

at

the

same

market

we

recommend

that

operating

system

developers

take

a

closer

quantitatively-based

look

at

their

policies

concerning

file

cache

sizes

and

write-cancellation

policies

Future

Directions

We

hope

that

this

paper

inspires

others

to

stress

and

evaluate

the

I/O

system

beyond

the

file

cache

For

example

determining

the

maximum

number

of

disks

that

each

system

could

support

would

offer

insight

into

the

capacity

of

these

systems

As

we

mentioned

in

Section

this

is

no

small

effort

It

would

also

be

important

to

understand

which

architectural

options?interleaved

memory

block

copy

hardware

high-performance

DRAMs?will

give

the

highest

potential

file

cache

performance

And

of

course

it

would

be

interesting

to

expand

the

study

in

this

paper

to

more

machines

and

operating

systems

One

potential

future

direction

for

the

benchmark

is

changing

how

manufacturers

and

users

evaluate

I/O

If

manufacturers

published

its

results

over

a

range

of

I/O

options

for

a

particular

system

users

could

use

predicted

performance

to

estimate

without

further

measurements

the

I/O

performance

of

their

specific

workloads

As

the

price

of

each

configuration

is

easily

calculated

the

price/performance

of

systems

that

P

e

rf

o

r

man

c

e

X

Y

Z

-LRB-

-RRB-

P

e

r

f

o

r

manc

e

X

n

o

m

i

n

a

l

Y

n

o

m

i

n

a

l

Zn

o

m

i

n

a

l

-LRB-

-RRB-

fX

X

-LRB-

-RRB-

f

Y

Y

-LRB-

-RRB-

f

Z

Z

-LRB-

-RRB-

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

match

the

users

needs

are

also

easily

calculated

simplifying

the

trade-off

between

number

of

disks

faster

disks

more

main

memory

and

so

on

References

-LSB-

-RSB-

Mary

G.

Baker

John

H.

Hartman

Michael

D.

Kupfer

Ken

W.

Shirriff

and

John

K.

Ousterhout

Measurements

of

a

Distributed

File

System

In

Proceedings

of

the

ACM

Symposium

on

Operating

Systems

Principles

pages

October

-LSB-

-RSB-

Mary

Baker

Satoshi

Asami

Etienne

Deprit

John

Ousterhout

and

Margo

Seltzer

Non

Volatile

Memory

for

Fast

Reliable

File

Systems

In

Fifth

International

Conference

on

Architectural

Support

for

Programming

Languages

and

Operating

Systems

-LRB-

ASPLOS-V

-RRB-

pages

October

-LSB-

-RSB-

Peter

M.

Chen

and

David

A.

Patterson

A

New

Approach

to

I/O

Performance

Evaluation

Self-Scaling

I/O

Benchmarks

Predicted

I/O

Performance

-LRB-

conference

version

-RRB-

In

Proceedings

of

the

ACM

SIGMETRICS

Conference

on

Measurement

and

Modeling

of

Computer

Systems

pages

May

-LSB-

-RSB-

Peter

M.

Chen

and

David

A.

Patterson

Storage

Performance?Metrics

and

Benchmarks

Proceedings

of

the

IEEE

-LRB-

-RRB-

August

-LSB-

-RSB-

John

H.

Hartman

and

John

K.

Ousterhout

Letter

to

the

Editor

Operating

Systems

Review

-LRB-

-RRB-

January

-LSB-

-RSB-

John

L.

Hennessy

and

David

A.

Patterson

Computer

Architecture

A

Quantitative

Approach

Morgan

Kaufmann

Publishers

Inc.

-LSB-

-RSB-

Jonathan

Kay

and

Joseph

Pasquale

A

Performance

Analysis

of

TCP/IP

and

UDP/IP

Networking

Software

for

the

DECStation

Technical

Report

Sequoia

Technical

Report

University

of

California

at

Berkeley

December

-LSB-

-RSB-

Samuel

J.

Leffler

Marshall

Kirk

McKusick

Michael

J.

Karels

and

John

S.

Quarterman

The

Design

and

Implementation

of

the

BSD

Unix

Operating

System

Addison-Wesley

Publishing

Company

-LSB-

-RSB-

Bob

Lyon

and

Russel

Sandberg

Breaking

Through

the

NFS

Performance

Barrier

Technical

report

Legato

Systems

Inc.

-LSB-

-RSB-

Marshall

Kirk

McKusick

William

N.

Joy

Samuel

J.

Leffler

and

Robert

S.

Fabry

A

Fast

File

System

for

UNIX

ACM

Transactions

on

Computer

Systems

-LRB-

-RRB-

August

-LSB-

-RSB-

Michael

N.

Nelson

Brent

B.

Welch

and

John

K.

Ousterhout

Caching

in

the

Sprite

Network

File

System

ACM

Transactions

on

Computer

Systems

-LRB-

-RRB-

February

-LSB-

-RSB-

John

K.

Ousterhout

Why

aren?t

operating

systems

getting

faster

as

fast

as

hardware

In

Proceedings

USENIX

Summer

Conference

pages

June

-LSB-

-RSB-

B.

Ramakrishna

Rau

Program

Behavior

and

the

Performance

of

Interleaved

Memories

IEEE

Transactions

on

Computers

-LRB-

-RRB-

March

-LSB-

-RSB-

Russel

Sandberg

David

Goldbert

Steve

Kleiman

Dan

Walsh

and

Bob

Lyon

Design

and

Implementation

of

the

Sun

Network

Filesystem

In

Proceedings

of

the

Summer

Usenix

Conference

-LSB-

-RSB-

Hal

Stern

Virtual

Amnesia

Advanced

Systems

-LRB-

previously

SunWorld

-RRB-

pages

February

-LSB-

-RSB-

Andrew

S.

Tanenbaum

and

Robbert

Van

Renesse

Distributed

Operating

Systems

Peter

M.

Chen

David

A.

Patterson

Unix

I/O

Performance

in

Workstations

and

Mainframes

Computing

Surveys

-LRB-

-RRB-

December

-LSB-

-RSB-

TPC

Benchmark

B

Standard

Specification

Technical

report

Transaction

Processing

Performance

Council

August

-LSB-

-RSB-

Mark

Wittle

and

Bruce

E.

Keith

LADDIS

The

next

Generation

in

NSF

File

Server

Benchmarking

In

Proceedings

of

the

Summer

USENIX

Technical

Conference

Appendix

Other

I/O

Measurement

Table

These

are

the

file

cache

and

disk

performance

values

at

the

nominal

access

size

for

reads

sequential

one

process

The

multipliers

in

the

fourth

and

last

rows

were

used

to

adjust

Figures

and

to

determine

performance

at

the

same

KB

average

access

size.The

number

of

unique

bytes

used

to

ensure

file

cache

or

disk

accesses

are

listed

in

Table

Acknowledgments

The

work

described

here

was

supported

in

part

by

the

National

Science

Foundation

under

grants

and

and

the

National

Aeronautics

and

Space

Administration

and

the

Defense

Advanced

Research

Projects

Agency

under

contracts

and

We

would

like

to

thank

the

following

people

for

either

running

the

benchmark

or

giving

us

access

to

the

machines

Jon

Forrest

Karem

Sakallah

and

Mike

Riepe

-LRB-

Alpha

AXP

-RRB-

Eugene

Miya

Dave

Tweten

and

Tom

Woodrow

-LRB-

Convex

-RRB-

Carl

Staelin

-LRB-

HP

-RRB-

Shashi

Sathaye

-LRB-

IBM

-RRB-

Sid

Bytheway

-LRB-

-RRB-

and

Ed

Kelly

Rajiv

Khemani

and

Jim

Voll

-LRB-

SPARCStation

-RRB-

We

would

also

like

to

thank

the

following

people

for

making

helpful

comments

on

a

draft

of

this

paper

Remzi

Arpaci

Mary

Baker

Ann

Drapeau

Mike

Dahlin

John

Hartman

John

Ousterhout

Ken

Shirriff

and

Randy

Wang

DEC

Alpha

DEC

DS

Sprite

DEC

DS

Ultrix

HP

IBM

Sun

SS

Sun

SS

Convex

IBM

Nominal

Average

Access

Size

-LRB-

KB

-RRB-

File

Cache

Performance

at

nominal

Size

-LRB-

MB/sec

-RRB-

File

Cache

Performance

at

KB

Size

-LRB-

MB/sec

-RRB-

File

Cache

Performance

Multiplier

to

adjust

to

KB

size

Disk

Performance

at

nominal

Size

-LRB-

MB/sec

-RRB-

Disk

Performance

at

KB

Size

-LRB-

MB/sec

-RRB-

Disk

Performance

Multiplier

to

adjust

to

KB

size

O O O O O O O B O B O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O B O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O B I O O O O O O O B O O O O B I O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O B O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O B I B O O O O B O O O O O O B I B O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O B O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O B O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O B O O B O B B O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B I O O O B O O B O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B I B I O O O O O B I O B I B I B I O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O B O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O B O O O O O B O O O O B O O O O B O O O O O B O O O O B O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O B B O O O O O O O O O O O O O O O O O O B O B O O O O O O O B I B O B O O O O O O O B O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B O O O O O O O B O O O O O O O B O O O O O O O O O O B I O O B O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O B I B O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O B O O B O O O O O O B I B O O O O O O B I O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O B O B O O O O O O O B O O O O O O O O B I O O O O O O O O O O B O O O O O O O O O B I B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O B I O O O O O O O O B I O O O O O B I O O O O O O O O O O O B I O O O O O B O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O B I O O O O O O O B O O O O O O O B O O O O B I O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O B I O O O O O O B O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O B B I O O O O O O O O O O O O O O O O O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B O B O O O O O O O B I O O O O O B I O O B I O O O O O B I O O O O B O O O O O O O O B O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B I O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B I O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B I O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B I O B O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O B I O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O B I O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O B O O O O O B I O O O O O O O O O B I B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B I O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O B I O O O O B I O B I O O O O B I B O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B B O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B I O O O O O O O O O B I B I O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O

benchmark
bus
convex c2
decstation 5000
disk
evaluation
file cache
hp 730
ibm 3090
main memory
mainframe
minisupercomputer
performance
sparcstation 1
sparcstation 10
sprite
unix
workstation