Dec 112017
 
PC Week Lan Performance benchmark program.
File LANPERF.ZIP from The Programmer’s Corner in
Category System Diagnostics
PC Week Lan Performance benchmark program.
File Name File Size Zip Size Zip Type
1024PC7.BAT 780 123 deflated
2048PC7.BAT 780 123 deflated
4096PC7.BAT 780 123 deflated
LANPERF.DOC 10543 4091 deflated
LANPERF.EXE 25342 16549 deflated

Download File LANPERF.ZIP Here

Contents of the LANPERF.DOC file



PC Week
LAN Performance Test (LANPERF)
Version 1.1

LANPERF is designed to provide a load-generation and load-
measurement tool for LANs. Two tests are provided: READ and
WRITE. The READ test performs DOS file reads from a disk file
for a fixed period of time. The file is read sequentially from
beginning to end. Once the end-of-file has been reached, reading
restarts from the beginning of the file. In a similar way, the
WRITE test performs DOS file writes to a file.

The READ and WRITE tests are parameterized to allow flexibility
in how the tests are performed. Options can be used to vary the
length of the test, the number of bytes in each block read or
written, the size of the file used in the test, and the DOS file
sharing mode.

Many LANs use local or remote disk caching to increase
performance, and the setting of the block size, file size, and
file sharing mode can make significant differences in the ability
of the LAN operating system to cache disk blocks.


RUNNING LANPERF

If you run LANPERF without any parameters, it will print a short
help message that describes the available options:

t# - test length (seconds) (10-65535)
b# - block size (in bytes) (1-65535)
f# - file size (in blocks) (1-65535)
w - do sequential write test
r - do sequential read test
dM - file sharing mode
^ modes to deny (r w rw n c)
x - use defaults: t60 b512 f64 r w dc


A default scenario can be selected by invoking LANPERF with the
"x" option. This selects a 60-second test time, 512-byte block
size, 64-block file size, and the compatibility file-sharing
mode. Both the READ and WRITE tests will be performed. A single
default option can be individually overridden. If an option is
not specified on the command line, it will be set at its default.

When selecting options, remember that a large file may be created
by LANPERF if large numbers are chosen for the block size and
file size. For example, specifying "b1024 f16384" will create a
16MB file. Ten stations running LANPERF concurrently with these
options would require 320MB of disk space on the server.

Since most non-LAN programs use the file-sharing compatibility
mode, that mode is used as the default for LANPERF. The other
modes (deny read, deny write, deny read/write, and deny none)
specify the access allowed subsequent users. On Novell Netware,
the file-sharing function is provided by Netware itself; other
networks may have to load the SHARE.EXE program provided with
DOS.


UNATTENDED OPERATION

Since LANPERF causes heavy load on a network, users of a
production network may not appreciate it being used while they
are trying to work. Load caused by users will also affect
LANPERF results, making them hard to reproduce. An alternative
is to run LANPERF after normal working hours, using unattended
operation. To do this, create a batch file that contains
multiple LANPERF commands, using whatever options are desired.
Output from LANPERF can also be redirected to a file. Redirect
the input of LANPERF to NUL, the null device. This will cause
LANPERF to start immediately, rather than waiting for a key to be
pressed. A sample batch file is shown below:

rem Batch file for LANPERF runs
echo LANPERF Test Results >RESULTS.OUT
LANPERF t30 b64 f10 r w drw >RESULTS.OUT
LANPERF t30 b256 f10 r w drw >RESULTS.OUT
LANPERF t30 b512 f10 r w drw >RESULTS.OUT


INTERPRETING LANPERF RESULTS

The output from a run of LANPERF will look similar to the
following:

LANPERF Version 1.1
PC Week LAN Performance Test
Copyright (c) 1989, Ziff-Davis Publishing Company

Test time : 10 seconds
Block size : 512 bytes
File size : 64 blocks (32768 bytes)
Sharing : Compatibility

===> PRESS A KEY ON ANY STATION TO START <===

Total Mean Response Throughput
Test Operations Time (ms) (KB/s)
---- ---------- ------------- ----------
WRITE : 1153 8.673 57.65
READ : 1725 5.797 86.25

For both the READ and WRITE tests, total throughput for the
workstation is calculated as a function of the number of
operations, block size in each operation, and the test time:

Operations * Block_Size
Station Throughput = -----------------------
Test Duration

Results are reported in kilobytes per second (KB/s).

Mean response time is the average time required to complete one
read or write operation, and is reported in milliseconds (ms).
It is calculated as:

Test Duration
Mean Response Time = -------------
Operations


APPLYING LANPERF

Throughput and response time are affected by the many software
and hardware components that intervene between the workstation
and server. Only a few of those components will be pivotal in
determining LAN performance.

Although LANPERF is primarily designed for testing LAN
performance, it has no LAN-specific code that prevents it from
running on a non-LAN PC. A useful starting point when using
LANPERF is to measure the performance of a PC, not connected to
the network, when doing I/O to a RAM disk. Tests on a hard disk,
with and without disk caching, can also be valuable as baseline
measurements to determine the overhead added by the network.
Suggestions for possible tests are described below.

Redirector overhead

The redirector (network shell) increases the overhead even for
local disk operations, since each I/O request must be examined to
determine if it should be sent to the network. The additional
load can be measured by running an identical LANPERF test on a
local disk with and without the redirector loaded.

Approximating load times

The results from the READ test can be used to estimate the time
it will take to load a program or read a data file. For example,
if the station throughput is 200KB/s, a 300KB file will take
approximately 1.5 seconds to load.

Maximum server throughput

A single LANPERF run on one workstation with an otherwise-idle
network will give the station throughput. However, a single
station is usually not able to maintain a full load on the
server. If successive tests are run with additional stations, a
point will be reached where the sum of the station throughput
results does not increase; it may even decrease. This point is
the maximum server throughput, and can be used as an upper bound
on single-server data delivery.

Maximum LAN throughput

In a multiple-server environment, LANPERF tests can be run on
both servers simultaneously. The sum of the station throughput
results gives the maximum LAN throughput. If single-server and
multiple-server results are very close, the media may be
saturated already.

Tuning the LAN

Server parameters such as cache size are often difficult to set.
LANPERF can be used to measure performance differences in
parameter settings. Remember, however, that LANPERF does only
sequential reads and writes; applications that perform random
I/O may have very different effects on cache performance.

Stress testing

Many LANs are lightly loaded, especially during their early life.
Problems in performance, or outright crashes, might occur only
sporadically, or might not show up until the LAN is expanded to a
production size and is handling critical applications. LANPERF
can generate a load on the LAN to simulate heavy use by multiple
users.


LANPERF INTERNALS

LANPERF's main program is written in C; it does parameter
decoding, verification, and results display. To obtain best
performance and avoid variations that might be introduced by
different C compiler run-time libraries, the READ and WRITE test
code is written in assembly language. None of the time-critical
test code is contained in the main program.

When a copy of LANPERF is started on a workstation, it waits for
one of two things to happen. First, it looks for a key being
pressed on the local workstation. If a key has been pressed,
LANPERF will create the file LANPERF.GO in the current directory
and start the test. If a key has not been pressed locally,
LANPERF will look for the file LANPERF.GO in the current
directory. If the file is present, LANPERF will start the test.
Thus, the LANPERF.GO file acts as a starting gun for all copies
of LANPERF started in the same directory.

Once the test has completed, the workstation that created the
LANPERF.GO file will delete it. If LANPERF is terminated
abnormally from a system boot or crash, the LANPERF.GO file will
remain, and MUST be deleted manually. If the file is not
deleted, subsequent runs of LANPERF will start immediately
without waiting for a key.

Regardless of the setting of the file-sharing option, each
LANPERF running on a separate station creates and uses its own
private file for performing the READ and WRITE test. This file
usually has a name something like $T000019, and might also be
left behind if LANPERF is terminated abnormally. It should be
deleted.

The WRITE test first creates a temporary file using DOS function
5Ah, then closes it. The newly-created temporary file is then
reopened for read/write access using DOS function 3Dh. This
roundabout method is used because function 5Ah always opens the
file in compatibility mode; it does not provide a way to specify
the newer DOS 3.1 sharing modes.

Blocks of data are sequentially written to the file, and a
counter is incremented at each operation. When the specified
file size has been reached, the file pointer is reset to the
beginning of the file, and write operations are resumed. After
each block has been written, the BIOS clock is checked to see if
the test time is up. Upon completion, the temporary file is
deleted.

The READ test also creates a temporary file using DOS function
5Ah, and fills it with data to be read by the test. In all other
respects, the READ test proceeds in the same way as the WRITE
test.

Both the READ and WRITE tests change the data in the blocks
written to the file so that no two successive blocks of data are
the same. This defeats caching schemes in some LAN operating
systems that recognize and avoid writing data that has not
changed.



 December 11, 2017  Add comments

Leave a Reply