Tracing Windows95
Min Zhou and Alan Jay Smith
Rep ort No. UCB/CSD-99-1037
January 1999
Computer Science Division EECS
University of California
Berkeley, California 94720
Tracing Windows95
y
Min Zhou and Alan Jay Smith
January 1999
dicult and imp ortant part of trace based analy- Abstract
sis. [Smit81]
Most published research on system b ehavior and
Multi-user time-sharing computer systems such
workload characterization has b een based on ei-
as UNIX systems and mainframe computer sys-
ther Unix systems or large, usually IBM or IBM-
tems have b een extensively studied. Much compre-
compatible, mainframe systems. It is reasonable to
hensive system tracing and related work has b een
b elieve that user b ehavior and workloads are di er-
done on these systems. [Smit81] [Bake91] [Oust85]
ent for PC systems. Further, the asp ects of system
[Cost85] [Hans85] Far less system tracing and anal-
design most needing study havechanged from the
ysis have b een done for p ersonal computers, which
mainframes dominant in the 1960s and 1970s, and
have already b ecome the most widely used typ e
the Unix systems that b ecame so p opular in the
of computer. Wehave/had in mind a number of
1980s to the PCs that seem to b e rapidly taking over
research studies directed towards the PC environ-
many or most asp ects of computing. Windows95 is
ment, and accordingly, our rst step has b een to
currently the most widely used computer op erating
write and run a tracer for such systems. Since the
system, and is very similar to the newly released
most dominant PC op erating system and architec-
Windows98. In this pap er, we describ e our tracer,
ture are Microsoft Windows95 and the Intel x86
which runs on Intel Pentium based PCs running
based Architecture IA resp ectively,wechose In-
the Microsoft Windows95 op erating system. Fol-
tel based PCs running Windows95 as our tracing
lowing the discussion of our tracing metho dology,
target systems. We will call Intel based PCs run-
Windows95 op erating system, and a tracing to ol we
ning the Microsoft Windows95 op erating system as
develop ed for Windows95, we give some descriptive
"PC systems" in the rest of this pap er. We note
and statistical results based on the traces collected
that the newly released Windows98 is very similar
from 29 PC users.
to Windows95, and we b elieve that user b ehavior
and workload characteristics for Windows98 should
also b e very similar to those for Windows95.
1 Intro duction
We b elieve that traces taken from PC systems
will di er from those taken from multi-user time-
System tracing is widely used for obtaining re-
sharing systems in a numberofways:
alistic workloads for computer system analysis and
First, the workload on a PC system with a sin-
p erformance tuning. It is a standard technique
gle activeinteractive user is likely to b e di erent
in computer architecture and op erating system re-
from the other systems, b oth b ecause there is only
search. The traces are often used to characterize
one user, and b ecause the applications are likely to
the b ehavior of the system as well as the workload
b e di erent. The interleaved activityofanumber of
represented by the traces, and can b e further used
users will di er from the individual streams of activ-
in b enchmark development. The traces can also b e
ity.Even in the case of a single-user Unix worksta-
applied to trace driven simulation to evaluate var-
tion, it is common to havemultiple pro cesses active
ious algorithms and design-prototyp es. Obtaining
at a given time. Further, we b elieve that PC users
a set of valid and suitable traces is often the most
are likely to run much shorter and less computa-
The authors' research has b een supp orted in part by the
tionally intensive jobs. The PCs are more likely to
State of California under the MICRO program, and by Mi-
b e used by the users for their private work. This is
crosoft, Fujitsu Micro electronics, Cirrus, Toshiba, Quantum,
very much the case for those home PC users.
Sun Microsystems, and Intel Corp oration.
y
Computer Science Division, EECS Department, Univer-
Second, time-sharing UNIX op erating systems
sity of California, Berkeley, CA 94720-1776
and Windows95 op erate di erently. Unlike UNIX, 1
Windows95 was designed to b e backward compati- metho dology, our tracer design implementation, as
ble with old software applications including old MS- well as the tracer installation and exp eriments. We
DOS applications and 16-bit Windows applications. give information ab out the users and the systems
For instance, Windows95 uses an improved version b eing traced in the same section. Section 4 dis-
of the MSDOS-FAT format le system, and Win- cusses the description and the statistics of the traces
dows95 also supp orts several di erent memory mo d- that we collected. The trace description is followed
els. Windows95 is not a true preemptive op erating by the discussion of the tracer overhead and limi-
system nor is it a secure op erating system, and it tations. Finally, section 5 summarizes our tracing
is not as stable as larger time-sharing systems as and gives the directions of our future work. In the
well. [Schu95] [Oney96] [Petz96] [Nort97] We will app endices, we provide an overview of Windows95
further discuss Windows95 and its le system, vir- and a more detailed discussion of the trace formats.
tual machine, memory system and pro cess schedul-
ing in the next ma jor section.
2 Related Work
Third, time-sharing systems and PC system do
not always share the same typ e of application soft-
In this section, we discuss some previous related
ware. Large time-sharing system applications are
system tracing work. We concentrate on related
more likely to b e scienti c computation oriented or
work by these others and others at Berkeley, but
enterprise server software. The most p opular UNIX
cite some other work as well; this is a small fraction
workstation testing workload are the SPEC b ench-
of the dozens to hundreds of trace based system
mark suite [Sp ec98] and TPC database b enchmark
studies. We also brie y highlight the ma jor di er-
suite [TPC98]. PC software applications are more
ences and similarities b etween those related tracers
likely to b e graphic user interface GUI oriented,
and our Windows95 tracer.
p ersonal information pro cessing intended, and more
interactive with the users. MS-Word and Lotus-123
2.1 Tracing UNIX Workstations and
are such examples.
Finally, hardware and software develop ers of
Mainframe Computers
workstation and mainframe computers often em-
Da Costa [Cost85] presented a BSD 4.2 UNIX
phasize such issues as p erformance, capacity and
le system tracing package. See also [Zhou85].
reliability. In comparison, PC develop ers are more
Ousterhout et al [Oust85] [Bake91] traced the
concerned with cost, convenience, p ower consump-
Sprite distributed le system via kernel instrumen-
tion, etc.
tation. In most cases, UNIX tracers were imple-
For this pro ject, wehave designed and devel-
mented via mo difying the UNIX le system kernel.
op ed a Windows95 PC system tracer, WMonitor,
Zivkov et al. [Zivk96] used several sets of main-
which collects traces of user and le system activ-
frame computer traces to characterize disk refer-
ity. In this part of the pro ject, our ob jective has
encing patterns and study disk caching. Their DB2
also b een to characterize the PC workload. Our
disk reference traces were collected from IBM DB2
tracing guideline is to achieve a reasonable compro-
customer sites using DB2PM, an IBM DB2 p er-
mise among the requirements of comprehensiveness,
formance monitoring package, and GTF, an IBM
exibility, minimum user interference and simplicity
general tracing package. The IMS disk referencing
of analysis.
traces were generated from IMS online system log
The selection of users traced will have a signif-
les. The GCOS traces were collected by instru-
icant impact on the characteristics of the workload
menting the GCOS op erating system.
collected. In this pap er, we rep ort on traces col-
The ab ove pro jects were all primarily fo cused on
lected from 29 real users, including engineers, sci-
the le systems of time-shared multi-user computer
entists, managers, home users and scho ol students,
systems. Similarly to our Windows95 le system
using a variety of system con gurations. Since we
tracing, these le system tracing pro jects were also
are interested in PC workload characteristics, which
done at the logical level, and le system call func-
include those of users and le systems, our trace
tion names and logical addresses were recorded with
events include user inputs, application switches, and
time stamps. Most sets of traces were similar to our
le system calls.
traces, whichcover the le system activities over a
The rest of this pap er is organized as follows:
p erio d of a few days to one week. Our tracing is dif-
Section 2 discusses and compares some previous
ferent from other tracing pro jects in that our targets
related research. Section 3 discusses our tracing 2
counter inside Intel's Pentium pro cessors. Similar are single user PC systems, and our tracing do es not
to Intel's \PowerMonitor", Chen et al [Chen96] pre- need to mo dify the kernel co de of Windows95.
sented a Windows to ol which studies the Pentium Hanson et al [Hans85] used a mo di ed UNIX
pro cessor's p erformance. These twoPentium PC C Shell to trace the user inputs in the UNIX shell
to ols are primarily used to monitor the pro cessor command environment. She also combined UNIX
activities. They only provide pro ling information. accounting information with the user input data
Microsoft also provides a system p erformance in her research on UNIX shell usage characteriza-
monitor to ol with Window95, \System Monitor", tion. The command line user interface has largely
or \SysMon" [Chon95]. It provides very rich p er- b een replaced by the graphical user interface in a
formance metrics on a variety of system resources: mo dern op erating system environment, suchasMS-
le system read/write, virtual memory page faults, Windows, MacOS and Op enWin. Compared to
swap le use, disk cache, pro cessor usage, free mem- Hanson's UNIX shell usage tracing, our Windows
ory, thread usage, etc. In comparison, our Win- tracing also collects information on mouse inputs
dows95 tracer only monitors the logical level le and window switches in addition to the keyb oard
system calls and user input activities. However, inputs.
Windows95 \SysMon" has a ma jor disadvantage, Ruemmler [Ruem93] used a kernel-level trace
likeIntel \PowerMonitor", is it is a real-time mon- facility built into HP-UX to trace physical disk I/Os
itor with no data capture capability. and describ ed the direct disk access patterns. In
Other relevant PC pro ling and tracing to ols in- comparison, our Windows95 tracing do es not collect
clude Intel's VTune [Inte98], TracePointTechnol- information on computer system activities at the
ogy's HiProf [Trac98], and Rational Software's Vi- physical level, such as the disk drive direct I/Os
sual Quantify [Rati98]. The VTune to ol collects, studied in [Ruem93].
analyses, and provides Intel Architecture-sp e ci c
software p erformance data from the system-wide
2.2 Tracing PC systems
view down to a sp eci c mo dule, function, and in-
Douglis et al [Doug94] traced the le system
struction in the application co des. HiProf provides
level disk activities of Apple Powerb o ok computers.
detailed pro ling information on applications built
Lorchetal [Lorc97] traced and pro led the sys-
with Microsoft's Visual Basic as well as Visual C++
tem resource usage on Power-PC systems with two
to run on Windows. Visual Quantify is a p erfor-
tracing to ols: \StatePro ler" and \PowerMeasure".
mance pro ling to ol for Windows application and
These are b oth MacOS sp eci c.
software comp onent p erformance analysis.
Li et al [Li94] traced the le system level disk ac-
tivities of DOS/Windows-3.1. Zhou et al [Zhou96]
3 Metho dology
also traced the user and disk activities of Windows-
3.1. These tracing to ols used the DOS TSR termi-
In order to obtain a valid set of traces which can
nate and Stay Resident technique, which is rarely
appropriately represent p ersonal computer work-
used in Window95. In Windows95, TSR programs
load characteristics, three ma jor tracing issues need
can only run from a DOS prompt. The roles of
to b e addressed: rst, what information should b e
TSR programs have b een replaced by virtual device
monitored and recorded; second, how to trace Win-
drivers. Lee et al [Lee98] traced and characterized
dows95 and get all the information we need; third,
several Windows applications under Windows NT
what typ es of users and machines should b e traced.
on the x86 pro cessor. They used a binary instru-
mentation engine, Etch, for the x86-Windows NT in
their trace collection. Instruction set level desktop
3.1 Tracing Ob jects
application p erformance was studied from the p er-
In this subsection, we discuss what data we
sp ectives of computer architecture. These desktop
collect and why. This tracing pro ject was b egun
applications were contrasted to the programs in the
with three end-uses in mind for the data. First,
integer SPEC95 b enchmark suite.
we are studying p ower management in p ortable
Intel Corp oration [Inte97] develop ed a Win-
computer systems see e.g. [Lorc97] , and we
dows \PowerMonitor" to monitor the Windows sys-
wanted to collect those activities re ecting certain
tem device drive access and the pro cessor activities.
asp ects of p ower consumption: user activity and
The implementation of Intel's \PowerMonitor" has
and disk activity. Second, we are interested in ex-
taken advantage of the features of a p erformance
tending some of our previous studies in disk caching 3
[Zivk96] [Smit85] to PC-typ e systems. Third, we 3.2.1 WMonitor, the Windows95 tracer
are also interested in characterizing the PC work-
Our Windows95 system tracing relies on two
load, which is the fo cus of the work describ ed in
standard Windows OS features: our user activity
this pap er. A separate pap er, which concentrates
tracing relies on the Windows message ho ok pro ce-
solely on workload analysis and characterization,
dure supp ort, and our le system tracing relies on
and whichgoeswell b eyond what is presented here,
Windows95's installable le system supp ort.
is available as [Zhou99].
For user activity tracing, we rely on the fact that
As we discussed earlier, we exp ect that the work-
windows inter-pro cess communication heavily de-
load we observe on the PC will di er from previ-
p ends on Windows message passing. User applica-
ously studied systems: the op erations of p ersonal
tion pro cesses accept user inputs, such as mouse ac-
computer systems are more tightly coupled with
tions and keystrokes, in the form of Windows mes-
user activities for instance, there are almost no
sages generated by the Windows OS. Windows ho ok
batchorbackground jobs in PC workloads ; the PC
is a mechanism by which a function can intercept
workload is more bursty and more GUI oriented;
user input messages or system event messages b e-
and Windows95 usually do es not b ehave in an opti-
fore they reach an application. The function can
mized way b ecause it was designed to supp ort b oth
act on events, mo dify, or discard them. Functions
32-bit Windows applications and old MS-DOS as
that receiveevent messages are called lter func-
well as 16-bit Windows applications.
tions and are classi ed according to the typ e of
Our traces include two parts: user activity
event message they intercept. For instance, a l-
traces and le system traces. User activity traces
ter function mightwant to receive all keyb oard or
consist of user keyb oard input traces, user mouse
mouse event messages. For Windows to call a lter
input traces and active application software traces,
function, the lter function must b e attached to a
i.e. the traces of user-input-fo cused windows where
Windows ho ok, such asakeyb oard ho ok. Windows
the user mouse inputs and keyb oard inputs are ac-
provides the API of SetWinodwsHookEx and Un-
cepted. Since the virtual memory swapping of Win-
hookWindowsHookEx to the users to maintain and
dows95 is implemented on top of the le system,
access lter functions. Attaching one or more lter
our le system traces also include virtual memory
functions to a ho ok is known as setting a ho ok. If
swapping information. Our le system traces con-
a ho ok has more than one lter function attached,
tain logical le system accesses; physical addresses
achain of lter functions is maintained in the Win-
could b e derived with le maps.
dows OS kernel. The most recently attached func-
In addition to satisfying the requirementofob-
tion is at the b eginning of the chain.
taining valid traces, our tracing should also min-
Three Windows message ho oks are used:
imize tracing overhead and anyinterference with
WM KEYBOARD, WM MOUSE, and WM CBT
the user, and the trace data should b e easy to use
Computer Based Training , to monitor keyb oard
in analysis. We recognize that these requirements
inputs, mouse inputs, and switches of user-input-
con ict with each other. In our tracing design and
fo cused window, resp ectively. Since WMonitor mes-
implementation, we b elieve that a reasonable com-
sage lter functions will b e mapp ed into the logi-
promise has b een achieved.
cal address spaces of other applications, to which
the messages are sent, the WMonitor message l-
3.2 Tracing Windows95
ter functions need to b e implemented in a dynamic
linked library DLL . Regular Windows EXE appli-
In this section, we describ e howwe use Win-
cations can b e mapp ed into only one logical address
dows95 standard system services to obtain the user
space.
activity traces and le system traces. We will use
For le system tracing, we rely on the fact that
one gure and several examples to illustrate the way
Windows95 allows third party software and hard-
our tracer, WMonitor, works. In app endix I, we
ware vendors to write their own File System Drivers
provide a description of the Windows95 op erating
FSDs for their pro ducts as part of Windows95's
system; a reader not familiar with the appropriate
le system. These FSDs are in the format of Win-
Microsoft software may wish to read that section
dows virtual device drivers VxDs . This le system
rst.
supp ort is also called Windows95's installable le
system supp ort. These installable le system VxDs
can b e dynamically loaded into the Windows95 ker-
nel. All le system calls will b e visible to the instal- 4
lable le system VxDs. A le system call will b e tracing message pro cessing mo dule where this trac-
pro cessed by an installable le system VxD which ing message is pro cessed. In the case of a le sys-
claims to pro cess this call. Our le system tracer is tem call: after an application makes a le system
written as such an installable le system VxD. How- call, and b efore the installable le system manager
ever, it do es not claim any pro cessing resp onsibility sends the call to a le system driver which will pro-
except examining each le system call. cess it, WM-VFS.vxd will read this call and gen-
Figure 1 shows the three ma jor WMonitor mo d- erate a user level pro cedure call back to WMoni-
ules and related system blo cks. It also illustrates tor.exe. This WMonitor user level pro cedure will
the control ow of tracing events. These three parts p ost a corresp onding le system tracing message to
of WMonitor are: the WMonitor tracing message pro cessing mo dule
where this tracing message is pro cessed similarly to
WM-VFS.vxd { a Windows95 installable le
the mouse tracing message. Every le system call
system virtual device driver which monitors
due to WMonitor trace dumping, which is referred
the le system calls;
to as a tracer le system call in the rest of this pap er,
is also recorded for the tracer overhead analysis.
MsgHK.dll - a dynamic linked library format
It is very imp ortant that the tracer do es not
mo dule which includes a mouse message ho ok
a ect the workload and regular user b ehavior.
pro cedure, a keyb oard ho ok pro cedure, and a
WMonitor is so designed that it will b e automati-
window switch message ho ok pro cedure;
cally initiated up on the start of Windows95. There
WMonitor.exe - a Windows95 32-bit applica-
is no need for the users b eing traced to op erate the
tion which contains a tracer console mo dule
tracer, since it runs in the background. WMoni-
the WMonitor graphic user interface , a trac-
tor's trace bu er is less than 1 MB. As the reader
ing message pro cessing mo dule, a bu er man-
will see in Table 1, all the PCs b eing traced haveat
agement and online analysis mo dule, and a
least 16MB main memory and sucient disk space.
WM-VFS user level call-back pro cedure.
Therefore, WMonitor's le system calls have little
impact on the regular user activities. bly
WIN95 User APP WMonitor is written in C++ and x86 assem PC Users Trace Msg Buffer Mgmt WM Console
Processing Trc Analysis & WM Init language. Microsoft Visual C++ 2.0 and Microsoft
Drive DevelopmentTo olkit MS-DDK for Win-
User
ws95 are our tracer development to ols. We also Applications KBHkProc FSVxD UserLevel do
CallBack Proc
alter Oney's Windows95 VxD sample MsHkProc referred to W WinHkProc WMonitor.exe
MsgHK.dll co de. [Oney96] WMonitor consists of 57K lines of
bly language co de. WMonitor was
post msgs to msg queue C++ and assem
elop ed at Intel Corp. when the author worked File System Calls dev
WIN95 Kernel tern...... Wm-vfs.vxd there as a summer in KeyBD Hook Entry . . Mouse Hook Entry
WinEvnt Hook Entry
Machines and Users Studied ...... 3.3
Windows Message Queue Message Hook Chain Win95 Installable File System
Di erent PC users p erform very di erent jobs.
Laptop PC users may also b ehave di erently from
Figure 1: Windows95 Tracing To ol WMonitor Mo dule
Desktop PC users. It is very dicult to de ne who
and Related System Blo ck Diagram
are the \typical" PC users and what is the \typical"
PC workload. We've attempted to collect as large
For the example of a mouse input: after a user
anumb er of user traces as p ossible, over as wide
inputs a mouse click, Windows95 will generate a
a range of user typ es and machine typ es, includ-
mouse input message and put it into the Windows
ing b oth laptop and desktop PCs. The users b eing
mouse message queue. Before this message reaches
traced include engineers, managers, assistants, stu-
the current user-input-fo cused window, the WMon-
dents, home PC users, and some others. The work-
itor mouse message ho ok pro cedure has examined
load b eing traced includes software development,
this message. A mouse tracing message will b e
computer aided design, logical synthesis and sim-
generated from the original mouse message by the
ulation, do cument writing, Web browsing, remote-
WMonitor message ho ok pro cedure. The mouse
dialup, PC game playing, etc.
tracing message will b e p osted to the WMonitor
Our Windows95 tracer was installed on a few 5
4.1.1 WMonitor system pro le logs home PCs and a numb er of industry PCs in several
corp orate sites including Intel Corp., Sony Corp.,
System activity pro le log les record the fol-
Toshiba Corp., and Fujitsu Corp. 29 sets of traces
ID, StartDate, Start- lowing information: USER
are discussed here. Each set of traces was collected
Time, StopDate, StopTime, TotalSectionTime,
from a separate PC machine/user over the p erio d
and activity pro ling information. The Start-
of a few days to a few weeks. Since the p ortion of
Date/StartTime and StopDate/StopTime are the
the time that each machine was p owered on varied a
calendar date/time when WMonitor starts and
great deal, our tracing time for each user also varies
stops instrumenting the system activities, resp ec-
a lot.
tively.TotalSectionTime is the total trace calendar
Table 1 lists the pro le information of the ma-
time in seconds b etween start time and stop time.
chine and user b eing traced. We show b oth cal-
Pro ling information records the numb er of tracing
endar time and tracing time. The calendar time
events in each tracing interval; the default tracing
for each user/machine is measured by the number
interval is 5 minutes. The interval can b e set by
of hours b etween the date/time of the rst record
mo difying the LOG INTERVAL record in WMoni-
and that of the last record. The tracing time for
tor initialization le \WMonitor.ini". The pro led
each user/machine is measured by the number of
trace events include keyb oard events, mouse events,
hours when the machine was b oth p owered on and
window switchevents, le system read events, le
the tracer enabled. \Ratio Trc/Cal " is the ratio of
system write events, le system op en events, le
tracing time to calendar time. \TrcEvent Count" in
system close events, le system seek events, le sys-
the table illustrates the total numb er of trace events
tem delete events, le system directory call events,
for each user/machine b eing traced. We also give
le attribute events, paging read events, paging
the average numb ers arithmetic mean value of the
write events, other le system call events, and to-
sample trace set of 29 traces and standard devi-
tal tracing events. The last activity pro ling infor-
ations for the calendar time, the tracing time, the
mation record is the total numb ers for eachtyp e
tracing time ratio, and the trace event countinthe
of pro led tracing events. The format of date
same table.
record is MM:DD:YY. The format of time record
is HH:MM:SS. All the numb ers in the log les are
decimal numb ers.
4 Trace Description
The following le is a WMonitor system pro le
log example:
In this section, we explain the trace le for-
mat and the collected traces. First we describ e the USER_ID: 380
StartDate: 08/07/97
traces; details of the trace formats are in App endix
StartTime: 17:37:41
I I. Second, we provide some overall trace statistics.
Time Keybd Mouse WinEvnt FRead FWrite ... Total
Third, we consider tracing overhead. In the end, we
17:42:41 409 251 23 7556 1056 ... 27699
17:47:41 89 33 8 422 73 ... 2005
discuss the limitations of our tracing work.
17:52:41 131 0 0 0 0 ... 131
17:57:41 0 0 0 1 0 ... 2
4.1 WMonitor trace les 18:02:41 238 6 0 0 0 ... 244
......
There are twotyp es of trace les: system ac-
Total: 894 339 41 7983 1129 ... 30177
StopDate: 08/07/97
tivity pro le log les and system activity trace
StopTime: 18:16:05
record data les. WMonitor system pro le log
Total_Section_Time: 1704 seconds
les are named as \WM001.log", \WM002.log",
..., \WM999.log". WMonitor trace record les
If the users are only interested in the system ac-
are named as \WM001.dat", \WM002.dat", ...,
tivity pro ling information, and the details of each
\WM999.dat". 001, 002, ..., 999 are the three-digit
tracing event can b e neglected, the log les are suf-
trace sequence numb ers. Each sequence number
cient enough to serve this purp ose, and thus trace
corresp onds to a contiguous p erio d of time when
record data les can b e disabled. By disabling trace
the traced PC is p owered on and WMonitor is en-
record data les, the tracer overhead and trace disk
abled. Both typ es of trace les are ASCI I format
space usage are greatly reduced, and the system ac-
text les.
tivity statistics and pro ling information can also
b e obtained more directly and quickly.For example,
if tuning the standard workloads in system b ench-
marking is the only tracing goal, the log le should 6 Num- Brand Model Type Mem Disk Calendar Tracing Ratio TrcEvent Comp User-Type ber -ory (C:/D:/E:) -Time -Time (Trc/Cal) -Count -any 1 Toshiba Protégé-610 laptop 16M 687M 199.5 h 30.96 h 16% 1116999 Intel Engineer/Hdware. 2 Toshiba Protégé-610 laptop 16M 687M 1028.2 h 54.77 h 05% 1990876 Other HomeUser/Pilot 3 Digital HiNote-UltraII laptop 64M 1372M 344.2 h 116.47 h 34% 8122170 Fujitsu Director 4 Fujitsu Lifebk-v655tx laptop 48M 1293M 503.5 h 153.50 h 30% 4753461 Fujitsu Manager 5 Fujitsu Lifebk-v655tx laptop 48M 1293M 719.3 h 195.21 h 27% 4619375 Fujitsu Manager 6 Fujitsu Lifebk-v655tx laptop 48M 1293M 185.1 h 36.74 h 20% 654949 Fujitsu Manager 7 Fujitsu Lifebk-v655tx laptop 48M 1293M 201.5 h 46.16 h 23% 1129639 Fujitsu Engineer/IC 8 Fujitsu Lifebk-v655tx laptop 48M 1293M 215.5 h 60.97 h 28% 605928 Fujitsu Engineer/Docmnt. 9 Fujitsu Lifebk-v655tx laptop 48M 1293M 715.1 h 179.68 h 25% 4188428 Fujitsu Engineer/Cad 10 Toshiba Pentium-PC laptop 24M 500M 215.3 h 15.13 h 07% 165920 Toshiba Engineer/IC 11 Toshiba Satellite-110ct laptop 24M 775M 215.0 h 36.93 h 17% 613989 Toshiba Engineer/Docmnt. 12 PC Pentium-120 desktop 24M 500M/4G 128.5 h 21.22 h 17% 1216834 Intel HomeUser/Engnr 13 PC Pentium-90 desktop 32M 1.2G 86.3 h 19.63 h 23% 648849 Intel Researcher 14 Dell Dimention-133 desktop 32M 1547M 972.4 h 81.91 h 08% 1447485 Other HomeUser/Studnt. 15 Compaq Prolinea-5150 desktop 16M 2G 430.5 h 40.28 h 09% 3648197 Sony Engineer/Sftware. 16 Sony PCV-120 desktop 64M 2G/2G 374.2 h 27.82 h 07% 2603819 Sony Engineer/Sftware. 17 Sony PCV-120 desktop 64M 2G/2G 438.6 h 120.38 h 27% 4246332 Sony Engineer/Sftware. 18 AST MS-T 5166 desktop 64M 2G/2G/1G 459.7 h 51.60 h 11% 9415271 Sony Engineer/Sftware. 19 Gtw2k P5-166 desktop 64M 1.5G 377.8 h 307.98 h 82% 9475388 Sony Engineer/Hdware. 20 Sony PCV-120 desktop 32M 2G 380.3 h 352.98 h 93% 10053795 Sony Engineer/Video 21 Sony PCV-120 desktop 32M 2G 378.7 h 100.96 h 27% 2041658 Sony Manager 22 Sony P55c desktop 32M 2G/2G/1.6G 191.8 h 56.90 h 30% 9166259 Sony Engineer/Sftware. 23 Toshiba Pentium-PC desktop 24M 500M/500M 216.1 h 52.30 h 24% 5240669 Toshiba Assistent 24 Toshiba Pentium-PC desktop 48M 500M/500M 230.8 h 29.96 h 13% 2482814 Toshiba Engineer/CAD 25 Toshiba Pentium-PC desktop 64M 1.2G 215.6 h 46.27 h 21% 954125 Toshiba Engineer/Progmer 26 Toshiba Pentium-PC desktop 48M 1G 238.1 h 59.49 h 25% 1776593 Toshiba Engineer/Progmer 27 Toshiba Pentium-PC desktop 24M 500M/1.5G 188.6 h 42.02 h 22% 5332521 Toshiba Engineer/Docmnt 28 Toshiba Pentium-PC desktop 48M 1.2G 596.1 h 49.17 h 08% 8067977 Toshiba Engineer/CAD 29 Toshiba Pentium-PC desktop 48M 500M/500M 216.8 h 56.82 h 26% 2316542 Toshiba Clerk Average (arithmetic mean) 367.7 h 84.3 h 24.4% 3727478
Standard deviation 238.9 82.6 19.2% 3154425
Table 1: Pro le Data for Machines and Users Traced
USER_ID: 761 b e sucient.
StartTime: 9E9C4F
Time Type Funct Details
4.1.2 WMonitor trace record data les
130 3 OPEN C: [223] \DAT\WMONITOR.INI
0 3 WRITE C: [223] 93
Trace record data les record the following data:
0 3 CLOSE C: [223]
USER ID, StartTime, StopTime, and the trace
0 3 SEEK C: [2A8] 4B400:B
0 3 READ C: [2A8] 200
records. The StartTime and StopTime read the
A 2 [e54] C:\WMONITOR\BIN\WMONITOR.EXE
Windows95 internal millisecond counter when the
0 3 READ C: [271] 1000 MM
WMonitor starts and stops instrumenting the sys-
0 3 FATTR C: \WINDOWS\SYSTEM\MFC40LOC.DLL
tem activities. The Windows95 internal millisecond
0 3 FDOPN C: \WMONITOR\BIN\*.*
DB 0 K_DN 11
counter is the elapsed integer time in milliseconds
96 0 K_UP 91
since the Windows95 system's most recent start.
0 3 FLCKS C: [26B]
Each trace record includes four data elds: time
0 3 RENAM C: \DAT\DATA.ZIP \RECYCLED\DC0.ZIP
0 3 DIR C: QLGD \WMONITOR\BIN\MSGHK.DLL
stamp, trace typ e, function name, and information
0 3 DELET C: \RECYCLED\DESKTOP.INI
detail. We will further discuss the trace record
0 1 START_MV
structure in App endix I I. We can determine the cal-
9E 1 STOP_MV
endar date and time for StartTime, StopTime and
......
Stop_Time: 1D41D3C
each trace record based on the time-stamp and the
readings of StartTime record and StartDate record
With detailed information and time stamps for
in the corresp onding WMonitor system pro le log
every trace eventavailable, WMonitor trace record
le.
data les can b e used in comprehensiveworkload
The following le is a WMonitor trace record
analysis and trace driven simulation. Except for
data le example:
the calendar date and time information, WMonitor 7
system activity pro ling information log les can b e trace record, resp ectively. In this table and the
repro duced from the trace record data les. rest of the pap er, we will use the term \ le sys-
Detailed information on the trace records is tem calls" for simplicity whenever we discuss the
found in App endix I I. regular le system calls; this do es not include the
memory swapping and tracer le system calls. The
PC users input by means of mouse devices as fre-
4.2 Trace Statistics
quently as bykeyb oard. The PC users switch from
one user-input-fo cused window, i.e. a foreground
Windows pro cess, to another window as often as
Item Statistics
ab out once p er minute.
Numb er of Users 29
Number of Trace Files 1546
Total Data Size 2762 M bytes
Category APPLICATION exe,dll
compressed data 180.7 M bytes
WindowsSystem EXPLORER, SHELL32,
Total Records 103,461,579
COMDLG32, WINHELP,
Total Tracing Time 2,443.6 hours
MPRSERV, ...
Total Active Time: 1,505.6 hours
MsOce/GrpWare WINWORD, ACCESS,
idle time<60 sec
POWERPNT, EXCEL,
COREL70, ...
Table 2: Trace Data Overall Statistics for29Traces
EngineerTool MSDEV, DDRAW, ...
MiscTool NOTEPAD, CALC, ...
PHOTOSHOP, WINZIP,
Table 2 describ es the trace size. As shown in
ACRORD32, ...
Browser NETSCAPE, IEXPLORE
the table, the average size of the compressed trace
DosApplication MASM, QUICKEN, ...
p er user is ab out 6M bytes. WMonitor do es not
compress the trace. The archived traces les were
Table 4: Traced Application Categories
compressed with WinZip. The tracing time is de-
ned as the duration during which the traced PC is
powered on and WMonitor is enabled. The average
From the user activity traces, we are able to
tracing time p er user is 52 hours. The PC users are
lter out the names of the most frequently accessed
active during 62 of the tracing time. We de ne a
Windows applications. We divide these applications
user as \active" if one or more tracing events have
into six categories, which are illustrated in Table 4.
taken place during the past 60 seconds.
Table 5 shows the 35 most frequently run ap-
plications \APPLICATION" . We determine the
most frequented run applications by the total time
Total Rec std Percent Rec/hour
in seconds/hour each application was traced to b e
KeyRec 89864 75611 2.57 1637.9
running \TIME" . Note that since we don't actu-
MouseRec 92387 108497 2.64 1271.0
ally collect CPU traces or OS scheduler traces, we
WinRec 3999 3389 0.11 63.9
FSysRec 3227K 2774K 92.57 47121.8
use the active window as the indication of which
MSwapRec 72702 105648 2.08 1314.4
pro cess is active. This leads to some errors see
Total 3486K 100 51408.8
[Zhou99] for a further discussion of this issue , but
we b elieve that they are minor. In the same ta-
Table 3: Trace Data Breakdown Statistics \Rec" is
ble, we also show the average numb er of times each
record numb er, \std " is the standard deviation.
application was invoked p er hour \Invoked" , the
average numb ers of user keyb oard/mouse inputs p er
hour \KeyEvnt"/\MouseEvnt" , the average num-
Table 3 describ es the frequency of tracing
b er of le system calls p er hour \FSCall" , and
events. The data shown in the table are
the average numb er of memory swapping le sys-
the arithmetic mean values of the 29 users'
tem calls p er hour \MmSwap" .
traces. File system trace records account for
Figure 2 shows the measured idle b ehavior in
92.6 p ercent of the total numb er of trace records.
PC systems. The Y axis on the left is the system
\KeyRec", \MouseRec", \WinRec", \FSysRec"
idle time given a certain tracing eventinterval on X
and \MSwapRec" in the table representkeyb oard
axis. For example, the gure shows that if all the
trace record, mouse trace record, window switch
idle p erio ds of 1 second to 2 seconds are added up,
trace record, le system trace record, and Win-
a PC system idles 376 second in total p er hour. For
dows95 virtual memory swapping le system call
another example, if all the idle p erio ds of 1 minute 8
APPLICATION TIME Invoked KeyEvnt MouseEvnt FSCall MmSwap
SCREEN-SAVER 978.26 0.71 0.4 205.8 92056.0 921.2
MSDOS-PROMPT 472.03 20.84 1588.4 3849.1 96143.1 2025.7
EXPLORER.EXE 295.31 10.47 818.3 5762.3 189544.3 6914.6
WINWORD.EXE 227.23 2.71 2669.8 1992.8 72541.5 3018.6
EUDORA.EXE 216.15 1.09 188.5 245.8 8802.2 78.5
MSDEV.EXE 215.72 3.18 333.6 184.8 11064.1 407.1
XVISION.EXE 172.70 0.65 786.0 25.0 5643.0 30.6
NETSCAPE.EXE 167.86 1.54 679.8 2412.9 71988.9 3042.5
SHDOCVW.DLL 139.78 2.10 179.7 1732.3 89917.8 2139.8
EXCEL.EXE 90.72 2.00 709.5 3189.7 93416.5 1906.6
XVL.EXE 76.23 0.32 283.3 87.9 1816.4 19.8
SPTNET32.EXE 66.24 1.39 117.9 18.4 227.3 4.5
POWERPNT.EXE 66.02 0.54 579.0 1625.2 46954.4 3047.3
NOTEPAD.EXE 44.14 0.58 1698.5 2972.2 34740.5 1329.8
EUDORA32.DLL 36.60 0.86 216.4 260.0 16557.8 26.5
HIRAMAIL.EXE 33.48 0.46 0.2 74.2 79.8 0.3
MSOFFICE.EXE 23.41 0.40 1.7 804.0 79919.8 3812.5
WINBIFF.EXE 20.77 0.64 248.9 70.7 52.3 1.1
BRYCE2.EXE 18.40 1.94 6.7 75.8 1841.2 54.4
TELNET.EXE 18.09 0.18 541.6 135.7 4342.6 157.4
RDD.EXE 12.71 0.53 7.6 146.1 3911.6 198.5
COMCTL32.DLL 12.33 1.22 278.7 5355.0 112844.3 2954.8
SUPERTAG.EXE 11.75 0.31 301.4 191.0 646.6 15.6
BPCAP.EXE 11.43 0.06 1.5 56.6 4427.8 88.2
PREMIERE.EXE 11.21 0.63 4.8 95.1 4297.8 58.1
WINHLP32.EXE 11.18 0.70 459.5 8335.2 142248.8 5054.0
SIDEKICK.DLL 11.04 0.06 47.8 12.7 5330.8 65.8
TSTCON32.EXE 10.63 1.29 6.0 140.7 3869.8 15.4
X.EXE 10.60 0.15 138.0 18.3 485.2 3.7
COMDLG32.DLL 9.87 0.85 1077.2 6585.8 108540.3 3338.8
SHELL32.DLL 9.39 2.18 700.4 5342.3 441804.0 11974.6
WINPROJ.EXE 8.65 0.04 10.0 24.2 2709.1 2.1
MSWORKS.EXE 7.89 0.36 136.5 111.8 537.7 41.4
MAILNEWS.DLL 7.40 0.15 687.5 434.3 6491.2 361.3
MPRSERV.DLL 6.04 0.15 1678.9 3821.0 64637.7 988.3
Table 5: The Most Frequently Used Applications \APPLICATION" is the application name, \TIME" is the total seconds
each application was traced p er hour, \INOVKED" is the count of numb er of times each application was invoked p er hour,
\KeyEvnt/MouseEvnt/FSCall/MmSwap" are the counts of di erent events p er hour.
to 2 minutes are added up, a PC system idles 156
seconds in total p er hour. The Y axis on the right
Function Name Percentage
is the p ercentage of cumulative system active time
SEEK 31.64
in the total tracing time. For example, if we set the
READ 24.59
tracing eventinterval to 1 second, a PC system is
FINDNEXT 12.18
WRITE 5.83
considered to b e active for ab out 43 of the total
FINDOPEN 4.56
tracing time. In this case, the system enters idle
FINDCLOSE 4.28
state from active state, if there is no tracing event
FILEATTRIB 3.74
taking place within one second after the previous
OPEN 3.30
CLOSE 3.14
tracing event has completed.
GETDISKINFO 3.09
Table 6 gives the p ercentages of the top 13 most
IOCTL16DRIVE 2.01
frequently invoked Windows95 le system calls.
FILETIMES 1.29
The p ercentages are calculated using the following
DIR 1.01
formula:
Table 6: Most Used File System Calls
29
X
F unctionC al l C ount
=29 100
Al l F S C al l C ount
user =1 9
800 100%
where F unctionC al l C ount is the count of a 724 idle-time 90% certain le system function calls of one user,
700 active-time percentage
Al l F S C al l C ount is the total count of le system 80%
600 calls of this user.
70%
Table 7 shows the numberofbytes p er hour ac-
500 y the le system calls of READ, WRITE, 60% cessed b
400 376 50% virtual memory READ, virtual memory WRITE,
and the p ercentage of total bytes accessed by each,
40%
ely. 300 resp ectiv Idle Time (seconds) 233231 222 30% 187 198 200 156
125 128 123 20% Cumulative Activetime Percentage
unction Bytes p er hour Percentage 100 110 116 F
100 76
31183 K 71.58 52 10% FS Read
6
FS Write 5154 K 11.83
0 0%
ap Read 4176 K 9.58
1/8 s 1/2 s 2s 8s 32s 2m 8m 32m 2h Intervals MemSw
MemSwap Write 3051 K 7.00
Figure 2: System Idle Time Distribution
Table 7: File System Trac
55%
50%
next two gures, Figure 3 and Fig- operating times 50.1% The
operating bytes
w the blo ck size distributions and total
45% ure 4, sho ytes for READ and WRITE le system
40% read/write b
or example, as shown in Figure 3 50.1 of
35% 34.7% calls. F
the bytes were transfered as part of the blo cks with
30%
size of 2049 to 4096 bytes, and 34.7 le READ
25%
calls are with these blo ck sizes.
perentage k
20% As can b e seen from these gures, most blo c termediate, 4KB b eing the most p opular. 15% 13.0% sizes are in 11.7%
11.8% ws95 virtual memory page size 10% Since b oth the Windo
5.8% 7.4%
AT-32 cluster size are 4K bytes, software 4.7% and the F 5% 3.1% 5.1%
2.2% 2.1% 1.3% designers tend to also use 4KB as the le read or 0%
bytes write bu er size.
0 2 8 32 128 512 2k 8k 32k 128k 512k
Figure 5 shows how frequently a PC le is ac-
cessed with an "OPEN" le system call in a 10-
Figure 3: Read File System Call Blo ck Size vs. Access
hour p erio d. The X axis represents the number of
Times and Total Bytes Read
accesses to one le in 10 hours. The Y axis on the
ts the numb er of les that have b een ac-
30% left represen
umb er of times given on the X axis, and 27.4% cessed the n
operating times 25.9%
Y axis on the right represents the p ercentage of
25% operating bytes the
such les out of the total numb er of les. For ex-
ample, there were ab out 10 les that were accessed 20% 19.1%
18.4%
"op ened" an average of 16 times p er 10 hours. It is
tersting to note that an average of 74.8 of the to- 14.8% in
15%
tal PC les have only b een accessed once during 10
percentage hours. Only 0.55 or 32 les are accessed 50 times
10% 8.5% or more during the same time p erio d. In fact, a few
7.1%
ere accessed several hundreds times. Some 5.5% 5.3% 6.9% les w 4.8% 4.7% 5.9%
5%
ere even accessed a few thousand times. Such 4.4% w 2.3% 2.6% 1.7% 1.1% a le can b e a graphic le, a initialization infor-
1.2% 1.7%
he le, or even a user 0% mation le, a temp orary cac bytes
0 2 8 32 128 512 2k 8k 32k 128k 512k
sp eci c le. Some examples of these p opular les
are: CONTROL.INI, EUDORA.INI, SYSTEM.INI,
Figure 4: Write File System Call Blo ck Size vs. Access
UNIMATIC.INI, NPROTECT.LOG, LMOS.TMP,
Times and Total Bytes Written
SCROLLBU.TMP, USER.BIN, M0CP9ESI.GIF, 10
GABENCHMARKS.PPT, USR04993. 4.4 Limitations of the study
e note the following caveats and limitations in 74.8% W 10000 60% 4394 our tracing and analysis:
Number of Files
Lack of pro cessor activity information. We Percentage 50%
1000
studied system activity based only on le sys-
40% tem, virtual memory and user activities. Our system idleness did not consider pro cessor sta-
s 100 as busy pro- 32 tus, i.e. whether the pro cessor w
30%
cessing a task, or the pro cessor was in an idle Percentage
num. of file T" halt instruc- 10 instruction lo op, or a \HL
20%
tion was active. We did not collect the pro-
cessor status trace, nor did we collect the Win-
1 ws pro cess/thread trace. 10% do 0 5 10 15 20 25 30 35 40 45 50
AccessPer10Hours
The dep endency on Windows messaging:
0.55%
ents are time stamp ed
0.1 0% User input tracing ev
when the input message gets removed from
the user-input-fo cused window rather than
Figure 5: File Access OPEN Distribution There are
when it is generated. The le system traces
negative bars in the gure, i.e. some numb ers are less
are time stamp ed when the le system trace
than 1. This is b ecause weare showing the numb er of
messages are pro cessed.
accesses p er 10 hours. Some les were accessed less than
once p er 10 hours on average.
Lack of le system caching information.
It is dicult to estimate the system p erformance
in the absence of pro cessor and caching informa-
4.3 Tracing Overhead
tion. Pro cessor activities were not collected since
the original motivation for this tracer was to study
Because we do not trace the pro cessor activ-
power management of/at the user interface and the
ity and the user inputs are very sparse, le system
I/O system.
tracing dominates our trace. Twotyp es of trac-
Since most of our analyses have used time granu-
ing overheads exist: rst, monitoring and generat-
larities e.g. 1/4 second much larger than the time
ing the trace record; second, dumping the bu ered
stamp quantum .001 second , the lack of ner res-
trace records to the hard drives. Every single trace
olution of the time stamp should not b e a problem.
record is generated by only a few tens of lines C
Even for detailed I/O studies, the .001 second quan-
co de. Compared to the regular le system function
tum should b e sucient.
pro cessing time, the overhead for generating the
In addition, the diversityofPCworkload and
trace records is not signi cant enough to b e consid-
the user level burstyness shown in our traces make
ered. Therefore, the WMonitor overhead measure-
straightforward arithmetic mean values insucient
ment will fo cus on trace record dumping, i.e. le
for detailed analysis. Further detailed PC workload
system call counts contributed by the tracer versus
studies and analysis breakdown into di erentwork-
the non-tracing counts of regular le system calls.
load categories are needed.
Statistics
Tracer FS Op eration Counts 86175
5 Summary and Future work
Regular FS Op eration Counts 3227379
Tracer FS Overhead 2.66
In this pro ject wehave presented a p ersonal
Standard Deviation of Overhead 0.351
computer system tracer and wehave discussed some
90 Con dence Interval 2.55, 2.76
ma jor issues in p ersonal computer system tracing.
A set of PC user and le system traces have b een
Table 8: Tracer Op eration Overhead
collected from a variety of PC users. The traces
collected can b e used in a number of ways to pro-
Table 8 shows the tracer overhead and the 90
vide insights to various asp ects of p ersonal com-
p ercent con dence interval over the 29 samples .
puter system and user b ehaviors. The traces can 11
of the 13th ACM Symposium on Operating b e used in b enchmark developmentaswell as for
Systems Principles , Jul. 1991, 1-15.
trace driven simulation for di erent system resource
[Chen96] Chen, J., Endo, Y., Chan, K., Mazieres, D., management algorithm studies, le caching studies
Dias, A., Seltzer, M., and Smith, M.: The
and p ower management analysis.
Measured Performance of Personal Com-
As an extension to this work, the pro ces-
puter Op erating Systems. ACM Transac-
sor activity pro ling and system resource man-
tions on Computer Systems.,Vol. 14, No.
agement could b e integrated with our Windows95
1, Feb. 1996, 3-40.
tracer. The features of the Pentium pro cessor's
[Chon95] Chong, H.: The Design and Tuning of
p erformance counter make the ab ove prop osal fea-
Microsoft Windows 95. Proceedings of
sible. Another alternative solution is to follow
the 21st International Conference for the
what Microsoft "SYSMON" do es, and use "Win-
Resource Management and Performance
dows95's p erformance metrics stored under the key
Evaluation of Enterprise Computer Sys-
HKEY DYN DATA/PerfStats/StatData with the
tems , Nashville, TN, Dec. 1995, 938-949.
Windows95 standard Registry API. Given informa-
[Cost85] Da Costa, H.: A File System Tracing Pack-
tion ab out the pro cessor activity and other system
age for Berkeley UNIX. Technical Report
resource usage, we could establish a more complete
of Computer Science Division EECS ,
PC user and system mo del. Wewould b e able to
University of California at Berkeley, No.
UCB/CSD-85-235 , Jun. 1985. analsis the pro cessor activities, and how pro cessors
react to the user activities in a Windows environ-
[Doug94] Douglis, F., Kaasho ek, F., Marsh, B.,
C aceres, R., Li, K., Taub er, J. Storage Al- ment.
ternatives for Mobile Computers. Proceed-
Wehave presented some general statistics of
ings of the First USENIX Symposium on
PC users and systems in this pap er. Amuch
Operating Systems Design and Implemen-
more extensive analysis of the workload app ears in
tation , Monterey, CA, Nov. 1994, 25-37.
[Zhou99]. Related and more detailed trace data is
[Gold74] Goldb erg, R.: Survey of Virtual Machine
currently b eing collected from WindowsNT systems
Research. IEEE Computer , Jun. 1974, 34-
at UC Berkeley byJay Lorch. Future pro jects will
45.
use the data collected in these two pro jects for stud-
[Hans85] Hanson, R.: A Characterization of the Use
ies of disk and I/O system optimization, disk design,
of The UNIX C Shell. Technical Report
and p ower management.
of Computer Science Division EECS ,
University of California at Berkeley, No.
UCB/CSD-86-274 , Dec. 1985.
6 Acknowledgments
[Inte97] Intel Corp.: Intel Power Monitor. Avail-
able as URL http://www.intel.com/ial/
The Authors would like to thank Intel Corp.,
ipm/.
for its technical supp ort during the tracer develop-
[Inte98] Intel Corp.: VTune Performance Enhance-
ment. The authors also thank Intel Corp., Toshiba
ment Environment. Available
Corp oration., Fujitsu Microsystems Inc. and Sony
at URL http://supp ort.intel.com/s upp ort/
Research Lab oratories for running the tracer on a
p erformanceto ols/vtune/.
numb er of their machines. The authors owespe-
[Lee98] Lee, D., Crowley,P., Baer, J., Anderson,
cial thanks to Takashi Miura, Gerry Atterbury, and
T., and Bershad, B.: Execution Character-
Act Ratanakul for their help in trace data collec-
istics of Desktop Applications on Windows
tion. Tushar Patel and Dennis Reinhardt at Intel
NT. The 25th Annual International Sym-
Corp. were esp ecially helpful during the tracer de-
posium on Computer Architecture., Jul.
velopment and trace collection. Many other p eople
1998, 27-38.
deserve thanks as well for sacri cing their valuable
[Li94] Li, K., Kumpf, R., Horton, P., Anderson,
time and system resources during the trace collec-
T. A Quantitative Analysis of Disk Drive
tion.
Power ManagementinPortable Comput-
ers. Proceedings of the 1994 Winter
USENIX Conference , San Francisco, CA,
Bibliography
Jan. 1994, 279-291.
[Lorc97] Lorch, J., Smith, A.: Energy Consump-
[Bake91] Baker, M., Hartman, J., Kupfer, M.,
tion of Apple Macintosh Computer. Tech-
Shirri , K., Ousterhout, J.: Measurements
nical Report of Computer Science Division
of a Distributed File System Proceedings
EECS , University of California at Berke- 12
ley, No. UCB/CSD-97-961 , Jun. 1997, to UNIX. Proceedings of USENIX Conference
app ear, IEEE MICRO. and Exhibition ,Portland, Jun. 1985, 407-
419.
[Nort97] Norton, P., Mueller, J.: Peter Norton's
Complete Guide to Windows95, Second
[Zhou96] Zhou, M., Smith, A.:
Edition , 0-672-31040-6, Sams Publishi ng,
A Windows I/O Tracing Package for Note-
Indianap olis , IN, 1997.
book PC Power Management. Available as
URL http://djinn.cs.b erkeley.edu /mzhou /
[Oney96] Oney, W.: System Programming for Win-
pap er/tracer.ps.
dows95 , Microsoft Press, Redmond, WA,
1996.
[Zhou99] Zhou, M. and Smith, A.: Analysis of
[Oust85] Ousterhout, J., Da Costa, H., Harrison,
Personal Computer Workloads. Computer
D., Kunze, J., Kupfer, M., Thompson, J.:
ScienceTechnical Report, UC Berkeley,
ATrace-Driven Analysis of the UNIX 4.2
submitted for publication , Jan. 1999.
BSD File System. Proceedings of the 10th
[Zivk96] Zivkov, B., Smith, A.: Disk Caching in
Symposium on Operating System Princi-
Large Databases and Timeshared Systems.
ples , Orcas Island, WA, Dec. 1985, 15-24.
Technical Report of Computer Science Di-
[Petz96] Petzold, C.: Programming Windows95 ,
vision EECS , University of California
Microsoft Press, Redmond, WA, 1996.
at Berkeley, No. UCB/CSD-96-913 , Sep.
1996. [Rati98] Rational Software Corp.: Visual Quantify.
Available at URL http://
rational4.rational .com/pro ducts/ vi sual q/.
App endix I: Overview of Win-
[Ruem93] Ruemmler, C., Wilkes, J.: UNIX Disk Ac-
cess Patterns. Proceedings of the Winter
dows95
1993 USENIX Conference , San Diego, CA,
Jan. 1993, 405-420.
In this app endix, we summarize some ma jor charac-
[Schu95] Schulman, A.: Unauthorized Windows95:
teristics of the Windows95 op erating system.
A Developer's Guide to Exploring the
Windows95 is a 32-bit protected-mo de op erating
Foundations of Windows Chicago , IDG
system designed to run 16-bit and 32-bit applicatio n
Bo oks, 1995.
programs on Intel architecture based p ersonal comput-
ers. Windows95 uses the VFAT format le system, a
[Smit81] Smith, A.: Long Term File Migration: De-
version of MS-DOS FAT le system with long lename
velopment and Evaluation of Algorithms.
supp ort. Windows95 provides up to 4 gigabyte virtual
Communications of the ACM ,Val. 24, No.
memory. The actual virtual memory size dep ends on
8, Aug. 1981, 521-532.
the physical memory and swap space available . Win-
[Smit85] Smith, A.: Disk Cache-Miss Ratio Analy-
dows95 supp orts preemptivemultitasking of Windows-
sis and Design Considerations. Proceedings
based and MS-DOS-based applicatio ns. Windows95
of the 5th annual Symposium on Computer
runs only on PCs based on Intel architecture pro cessors,
Architecture , Apr. 1985, 242-248.
80386s or more advanced mo dels. Windows95 do es not
[Smit94] Smith, A.: Trace Driven Simulation in
attempt to provide a secure environment in which pro-
Research on Computer Architecture and
gram and data can b e insulated from another program's
Op erating Systems. Proceedings of the
inattentiveorintentional misb ehavior.
Conference on New Directions in Simula-
tion for Manufacturing and Communica-
tions , ed. Moriton, Sakasegawa, Yoneda,
A1.1 Windows95 virtual machine
Fushimi, Nakano, Tokyo, Japan, Aug.
The general concept of virtual machines dates back
1994, 43-49.
to early IBM mainframe computers and the work by
[Sp ec98] The Standard Performance Evaluation
Rob ert Goldb erg. [Gold74] The virtual machines in
Corp oration: Frequently Asked Ques-
the PC world were created when the early versions of
tions FAQ . Available as URL http://
Windows needed to supp ort multiple MS-DOS applica-
op en.sp ecb ench.org/sp ec/faq/
tions and Windows applications running at the same
[TPC98] Transaction Pro cessing Performance Coun-
time. [Oney96] [Petz96] A virtual machine created by
cil: Frequently Asked Questions FAQ .
software reacts to application programs the same way
Available as URL http://www.tp c.org/
a real machine do es, which enables the MS-DOS pro-
faq general.html
grams to own the keyb oard, the mouse, the display
[Trac98] TracePoint
screen, the pro cessor, and the user's attention as if they
Technology Inc.: HiProf. Available at URL
were running on their own dedicated hardware. Sp ecif-
http://www.tracep oint.com/.
ically, in the kernel of the Windows95 op erating sys-
[Zhou85] Zhou, S., Da Costa, H., Smith, A.: A
tem, a Virtual Machine Manager VMM manages all
le System Tracing Package for Berkeley 13
into the pro cessor's segment registers to access more virtual machines. The VMM works with Virtual Device
than 64 KB of memory. The 32-bit programs partici- Drivers VxDs to simulate hardware devices and to pro-
pate in preemptivemultitasking under the overall con- vide system services to applicatio ns and to each other.
trol of the scheduling subsystem of the virtual machine There is at least one virtual machine running on a Win-
manager, while the 16-bit Windows application s must dows95 system, the system virtual machine, which runs
co op eratively multi-task amongst themselves { from this all Windows applications and the Windows95 system
p oint of view, sometimes Windows95 is not viewed as itself. One or more MS-DOS virtual machines running
a preemptivemultitaskin g system. MS-DOS program MS-DOS applications can co-exist on a Windows95 sys-
multitasking dep ends on the scheduling among di er- tem.
ent virtual machines.
Most of the time, one or a few windows are asso-
A1.2 Windows95 memory mo del
ciated with one Windows program. Similarly to the
Generally sp eaking, Windows95 supp orts three dif-
UNIX foreground pro cess, a user-input-fo cused window
ferent memory mo dels: Windows3.1 protected-mo de
in Windows is the foreground window to which the user
segmented memory mo del, WindowsNT at memory
input will b e p osted.
mo del, and Virtual-86 mo del. In the protected-mo de
segmented memory mo del, the pro cessor uses a selec-
A1.4 Window95 le system
tor which p oints to a segment descriptor entry in the
Windows95 uses an installabl e le system manager memory descriptor table and an o set pair to refer-
IFS manager , the highest layer in the le system, to ence a memory lo cation. The virtual memory is divided
handle all le system calls from Windows 32-bit appli- into segments of up to 64KB each. In the at mem-
cations, Windows 16-bit applicatio ns and MS-DOS ap- ory mo del, there is only one segment which contains all
plications. We will discuss IFS in the next subsection the programs. Virtual memory with a two-level page
in more detail. The IFS manager calls on le system table paging scheme is used where each 32-bit address
drivers FSDs to supp ort di erent le system formats. is split into three elds: page table directory p ointer,
The le system formats currently supp orted by Win- page table p ointer, and page o set. Each page frame
dows95 include FAT-16 File Allo cation Table with 16 is 4K bytes. In the virtual-86 mo de, 20-bit addresses
bit entries , FAT-32 32 bit FATentry version of FAT, yield only 1MB of address space. A segment/o set pair
used in the OSR2 OEM Service Release 2 version of is used to generate the 20-bit memory address.
Windows95 and Windows98 and the CD-ROM le sys-
tem. The FSDs in turn talk to disk drivers whichinter-
A1.3 Windows95 pro cesses and
face with the hardware directly.
threads
AFAT including FAT-16 and FAT-32 format disk
consist of a BOOT sector, a le allo cation table, a ro ot
Each Windows application o ccupies a pro cess that
directory, and a cluster section. BOOT stores the ba-
consists of a dedicated address space and one or more
sic information ab out the disk and for the use of system
threads of execution. Each thread corresp onds to a se-
b o ot. The ro ot directory stores the information describ-
quence of program steps and the evolving state of pro-
ing each le entry in the top level directory. The disk
cessor registers and system ob jects asso ciated with that
cluster section is divided into separated clusters. The
sequence. Windows95 uses a priority-based scheme to
notion of a cluster, which is a contiguous collection of
preemptively multi-task threads.
disk sectors, was intro duced as the allo cation unit. Each
Windows95 supp orts three typ es of applicati ons:
FAT table entry is used to maintain the status of a disk
Windows 32-bit application programs, Windows 16-bit
cluster, and the number of FAT table entries is equal
application programs, and MS-DOS application pro-
to the numb er of the clusters on a disk. A FAT table
grams. Both 32-bit and 16-bit Windows applicatio n
is organized as a linear array containing multiple one-
programs run on the system virtual machine while each
way linked lists. One list corresp onds to a le or sub-
MS-DOS applicatio n programs run on a separate MS-
directory. The FATentry lo cation of the head of each
DOS virtual machine. The system virtual machine has
list is stored in the ro ot directory or a sub-directory.In
one pro cess for each program, and each 32-bit Windows
aFAT le system, sub-directories are stored as regular
program can consist of more than one thread. The addi-
les.
tional virtual machines are for MS-DOS programs, and
FAT-16 uses a xed FAT table size 32KB , 16-bit
each contains exactly one pro cess and one thread.
FAT table entries, and variable cluster sizes. FAT-16
The 32-bit Windows programs adopt the at mem-
supp orts up to 2GB p er logical hard drive. A hard
ory mo del, wherein all co de and data can b e addressed
drive larger than 2GB needs to b e partitioned into a
in a single segmentcovering all of the virtual memory.
few logical hard drives for a FAT-16 format le system.
The 16-bit Windows programs use the Windows3.1 seg-
For example, FAT-16 uses 32KB cluster for a 2GB hard
mented memory mo del, in whichavailable virtual mem-
drive, 16KB cluster for a 1GB hard drive, ... , 4KB clus-
ory is sub divid ed into segments of up to 64 KB each.
ter for a 128MB hard drive, etc. Di erent from FAT-16,
The 16-bit Windows programs load segment selectors 14
FS FAT-32 uses a variable FAT table size, 32-bit FAT table ReadFile transfers data from the le to a mem-
entries, and a xed cluster size 4KB . It supp orts up ory bu er. The memory bu er can b e lled
to a 2TB hard drive. Our target systems all use the asynchronously using one or more I/O requests.
FAT-16 format le system for their hard drives. In a regular FSD implementation, Windows95
The FAT le system used in Windows95 le system VCACHE facilities should b e used to maintain
is called VFAT, virtual FAT { an improved version of the a cache of disk records to minimize the physical
old MS-DOS FAT format le system plus long lename I/O.
supp ort. Similar to FAT, VFAT also can b e classi ed
FS WriteFile transfers data from a memory bu er
as VFAT-16 and VFAT-32. The VFAT le system has
to the le. A cache of disk-sector-sized bu ers
two le names for each le, a DOS-8.3 format lename
containing the data should b e maintained and
maximum 8 bytes for the le name and maximum 3
the physical write op erations should b e p erformed
bytes for the le name extension and Windows95 sp e-
asynchronously.
ci c long lenames which can b e as long as 256 bytes.
FS FileSeek is an advisory service that allows an
FSD to optimize its prefetches of a le. This func-
tion is advisory b ecause the read and write func-
A1.5 Windows95 Installable File Sys-
tions b oth supply a le p osition that overrides
tem and IFS Calls
anything recorded by the FSD.
The le systems of b oth Windows3.1 and MS-DOS
FS OpenFile takes indicated actions to op en a le
dep end on MS-DOS's INT21 co de to manage les on
which matches the parsed pathname.
disk. Since MS-DOS INT21 is not reentrant, multi-
CloseFile ushes any output bu ers to disk, FS
ple pro cesses cannot simultaneousl y p erform le sys-
deletes internal structures related to the le, and
tem calls without pro ceeding one at a time through
generally cleans up after a series of op erations on
this critical section. Windows95 relies on the Installable
an op en le.
File System Manager to solve this problem and supp ort
FS CommitFile ushes bu ered data of a le han-
asynchronous I/Os. All le system calls of Windows 32-
dle to disk.
bit applications , Windows 16-bit application s and MS-
EnumerateHand le enumerates le handle in- FS
DOS applicatio ns go to the IFS manager. These le
formation.
system calls include the accesses to the memory swap
FS Hand leInfo gets and sets information for a le
le as well. IFS manager calls on FSDs to implement
by the le handle.
diverse le systems likeFAT and the CD-ROM le sys-
LockFile lo cks or unlo cks a byte range in a le FS
tem. The FSDs talk to disk drivers whichinterface with
by the le handle.
the hardware comp onents such as hard drive and op-
FS FileDateTime sets or retrieves the timestamps
pies directly.
which asso ciate with an op en le. There are three
The IFS manager exp orts a numb er of virtual
Windows95 le timestamps: creation time, last-
device driver level services for use by other parts
mo di ed time, and last-accessed time.
of the system. These IFS services and Windows95
FS DeleteFile deletes the les whose parsed path-
virtual device driver's dynamic loading, whichwas
name app ears in the request pathname.
designed for plug-and-play, allows third party soft-
FS Dir p erforms a function on a directory. Direc-
ware and hardware vendors to write their own de-
tory functions include creating, deleting, checking
vice drivers as part of Windows95 le system. One
for the existence of a directory,orconverting a di-
of the most imp ortant services provided by IFS man-
rectory name b etween its long-name form and its
ager is the IFS Mgr InstallFil eSystemAp iHo ok service.
8.3 form.
IFS Mgr InstallFil eSystemApi Ho ok takes the address of
FS DirectDiskIO is called by IFS manager to han-
the user VxD ho ok pro cedure as an argument, and
dle MS-DOS INT 25h and INT 26h absolute disk
it returns the address of another ho ok pro cedure. A
read and write requests.
VxD ho ok pro cedure is a VxD pro cedure which will b e
FS DirectVolumeAccess p erforms direct volume
trigged when the ho ok-targeting system service is in-
le system storage resource logical unit accesses.
voked. All the VxD ho ok pro cedures should chain the
call instead of just pro cessing it to give other p oten-
FS ConnectNetResource connects or mounts a
tial ho oks their chance to examine each request to the
network resource.
targeted system services. Internally, the IFS manager
FS DisconnectResource is the function to take the
maintains its own list of API ho oks so that the users
actions required when one of the FSD volumes is
can add and remove the ho oks in any order.
unloaded or deleted.
There are 31 most commonly used Windows95 in-
FS FileAttributes gets or sets the attributes of a
stallable le system calls generated by IFS manager.
le.
These calls are our le system tracing targets. Next we
FindChangeNotifyClose and FS
give the names and explanation of these installab le le
FS FindNextChangeNotify search for le change
system calls.
noti es on a certain disk drive. 15
FS FindFirstFile, FS FindNextFile Time Type Funct Details
130 3 OPEN C: [223] \DAT\WMONITOR.INI
and FS FindClose go together to implementa
0 3 WRITE C: [223] 93
FindFirstFile initiates a normal le search. FS
0 3 CLOSE C: [223]
le search that can include wildcards, and cre-
0 3 SEEK C: [2A8] 4B400:B
ates a context handle. FS FindNextFile contin-
0 3 READ C: [2A8] 200
ues the search with the context handle until no
A 2 [e54] C:\WMONITOR\BIN\WMONITOR.EXE
more matches are p ossible. FS FindClose closes
0 3 READ C: [271] 1000 MM
0 3 FATTR C: \WINDOWS\SYSTEM\MFC40LOC.DLL
the context handle.
0 3 FDOPN C: \WMONITOR\BIN\*.*
FS FlushVolume ushes any p ending output data
DB 0 K_DN 11
to the device.
96 0 K_UP 91
FS GetDiskInfo retrieves information ab out the 0 3 FLCKS C: [26B]
0 3 RENAM C: \DAT\DATA.ZIP \RECYCLED\DC0.ZIP
free space on a disk drive.
0 3 DIR C: QLGD \WMONITOR\BIN\MSGHK.DLL
FS GetDiskParms returns the real-mo de address
0 3 DELET C: \RECYCLED\DESKTOP.INI
of the MS-DOS disk parameter blo ck.
0 1 START_MV
9E 1 STOP_MV
FS Ioctl16Drive p erforms an I/O control op era-
......
tion on the volume.
Stop_Time: 1D41D3C
FS QueryResourceInfo provides basic information
ab out the le system to the IFS manager.
With detailed information and time stamps for ev-
ery trace eventavailable , WMonitor trace record data
RenameFile renames one or more les. Wild- FS
les can b e used in comprehensiveworkload analysis
cards in the source name can b e sp eci ed by the
and tracing driven simulations . Except for the calendar
user.
date and time information, WMonitor system activity
FS SearchFile is the MS-DOS equivalent of the
pro ling information log les can b e repro duced from
FS FindFirstFile family of functions.
the trace record data les.
TransactNamedPipe p erforms named pip e op- FS
erations.
A2.1 WMonitor trace record structure
FS UNCPipeRequest p erforms UNC path based
named pip e op erations.
Each trace record in a WMonitor trace record data
le includes up to four data elds: time stamp, trace
typ e, function name, and detail information. The trace
App endix II: WMonitor trace
record data elds are separated by the character of
ASCI I co de 09. Each trace record contains up to 539
record data les
bytes. When a trace record reaches its maximum length,
two full Windows95 long le pathnames, eachof256
Trace record data les record the following data:
bytes, are included.
ID, StartTime, StopTime, and the trace records. USER
The time stamp records the time when a traced
The StartTime and StopTime read the Windows95 in-
event triggers a WMonitor pro cedure. The incremen-
ternal millisecond counter when the WMonitor starts
tal time stamp is used to reduce the record size. The
and stops instrumenting the system activities. The
absolute time stamp can b e derived by accumulating
Windows95 internal millisecon d counter is the elapsed
the incremental time stamps and then adding the Start-
integer time in millisecond s since the Windows95 sys-
Time. The granularity of time stamp is one millisecond.
tem's most recent start. Each trace record includes four
The upp er limit of this time stamp is 0xFFFFFFFF.
data elds: time stamp, trace typ e, function name, and
Trace typ e can have one of the following four values:
information detail. We further discuss the trace record
structure in next subsection. All numb ers are hexadec-
0{keyb oard input event
imal numb ers except the numb er in USER ID record
1 { mouse or other p ointing device input event
in a trace record data le. One trace record spans ex-
2 { user-input-fo cused window switchevent
actly one text line with the return and line-feed charac-
3 { le system call event
ters, 0D and 0A in ASCI I co de, as the line separator.
Table 9 also lists all trace record typ es in a WMoni-
We can determine the calendar date and time for Start-
tor trace record data le. Di erenttyp es of trace records
Time, StopTime and each trace record based on the
interpret the function name eld and detail information
time-stamp and the readings of the StartTime record
eld di erently, whichwe will discuss in the following
and the StartDate record in the corresp onding WMon-
two sub-sections.
itor system pro le log le.
The following le is a WMonitor trace record data
le example:
A2.2 User activity trace record
There are three typ es of user activity trace records:
USER_ID: 761
keyb oard input record, mouse input record and user- StartTime: 9E9C4F 16
Trace typ e Explaination Data eld
USER ID user id user-identi cation
StartTime start time trace-starting-time
Stop Time stop time trace-stopping-time
0 keyb oard input keyb oard-eventkey-scanco de
1 mouse input mouse-event
2 window switch [window-handle] application-name
3 le system call see Table 10
Table 9: WMonitorTrace Records is the Windows internal milisecond counter readings when tracing starts/stops.
function name detail information eld IFS call name
1 2
READ diskdrive fhandle bytes vm opt FS ReadFile
WRITE diskdrive fhandle bytes vm opt FS WriteFile
3
FDNXT diskdrive handle FS FindNextFile
FCNNT diskdrive FS FindNextChangeNotify
4
SEEK diskdrive fhandle bytes p osition FS FileSeek
CLOSE diskdrive fhandle FS CloseFile
COMMT diskdrive fhandle FS CommitFile
FLCKS diskdrive fhandle FS LockFile
FTMES diskdrive fhandle FS FileDateTime
PIPRQ diskdrive FS TransactNamedPipe
HDINF diskdrive fhandle FS Hand leInfo
ENMHD diskdrive FS EnumerateHand le
3
FNDCL diskdrive handle FS FindClose
FCNCL diskdrive FS FindChangeNotifyClose
CNNCT diskdrive FS ConnectNetResource
DELET diskdrive lename FS DeleteFile
5
DIR diskdrive metho d lename FS Dir
FATTR diskdrive lename FS FileAttributes
FLUSH diskdrive FS FlushVolume
GDSKI diskdrive FS GetDiskInfo
OPEN diskdrive fhandle lename FS OpenFile
RENAM diskdrive lename1 lename2 FS RenameFile
SEARC diskdrive lename FS SearchFile
QUERY diskdrive FS QueryResourceInfo
DISCN diskdrive FS DisconnectResource
UNCPR diskdrive FS UNCPipeRequest
IOC16 diskdrive FS Ioctl16Drive
GDSPR diskdrive FS GetDiskParms
FDOPN diskdrive lename FS FindFirstFile
DSDIO diskdrive FS DirectVolumeAccess
1 2
Table 10: File System Call Records fhandle is the le handle in the format of \[hex-numb er]". vm opt is the virtual
3
memory op eration indicator which can b e null i.e. \ " , or one of \PG" or \MM". handle of FDNXT and FNDCL is
4 5
the le searching context handle. p osition can b e one of \b egin", \end", or \current". metho d can b e one of \mkdir",
\rmdir", \chechdir", \query8.3dir", or \querylongdir". 17
input-fo cused window switch record.
keyb oard input record: Forakeyb oard input
event, the function name is either \K DN" press-
ing a key or \K UP" releasing a key . The 1
byte 7 valid bits key scan co de is stored in the
detail information eld. The 8th bit of this byte
indicates the status of the key b eing accessed: 1
{upand0{down.
For example, if the input is a capital ASCI I
\K ", four keyb oard trace events are recorded:
0x2A scan co de of \left shift" K DN, 0x25 scan
co de of \k " K DN, 0xA5 scan co de of \k "+
0x80 K UP, and 0xAA scan co de of \left shift"
+ 0x80 K UP, where \left shift" K DN and
shift" K UP are not generated if Caps Lo ck \left
is in function.
mouse input record: For a mouse input event,
the function name can b e one of the follow-
ing mouse events: L DWN pressing the left
UP releasing left mouse but- mouse button , L
ton , L CLK double clicking the left mouse but-
ton , M DWN pressing middle mouse button ,
M UP releasing middle mouse button , M CLK
DWN double clicking middle mouse button , R
pressing right mouse button , R UP releas-
ing right mouse button , R CLK double clicking
MV starting mov- right mouse button , START
ing the mouse , and STOP MV stopping moving
the mouse . The detail information eld is empty
for the mouse input event case.
user-input-fo cused window switch record: For a
window switchevent, the window handle and the
application software full pathname are stored in
the function name eld and detail information
eld, resp ectively.
A2.3 File system call trace record
Table 10 gives a list of le system function call
names, the corresp onding detail information elds, and
installabl e le system call names. We discussed the in-
stallable le system calls previously.
File system call trace records include b oth regu-
lar le access call records and memory swap le access
call records. Memory swap le access call records are
mapp ed memory reads, mapp ed memory writes, mem-
ory paging reads, or memory paging writes. Memory
swap le access records distinguis h themselves from reg-
ular le access records by the last twobytes in the detail
information eld: either \MM" Mapp ed Memory or
\PG" memory PaGing . 18