SYSRUTH@utorphys.BITNET (01/19/88)
In terms of CPU and other resource usage, I would like to know which of these
is more expensive and precisely why. We are considering changing our charging
algorithm to reflect the fact that things other than CPU are our main costs
these days, and I/O operations are among the things we might charge for. I
would assume that buffered I/O is generally to/from things like terminals
and tape drives (if using RMS and not direct QIO's), while direct would be
for devices such as array processors, image processors (and display screens),
etc. Where exactly do the disks come in? I guess most system devices must be
buffered somewhat, but to be honest, this is an area where my understanding
has always been a bit fuzzy. So is it more expensive to do number of single
direct I/O's to a device, or to fill something up and flush it out a bunch
at a time?
If I had to make a guess, I'd say there probably isn't that much difference,
since direct I/O's may be smaller but more of them are needed, while buffered
I/O has to collect somewhere before the operation that writes/reads it.
Can someone explain this to me clearly and cleanly?
Many thanks to all who respond - this may be a question that puzzles others
as well.
Ruth Milner
Systems Manager
University of Toronto Physics
SYSRUTH@UTORPHYS (BITNET)dp@JASPER.Palladian.COM (Jeffrey Del Papa) (01/19/88)
Date: Mon, 18 Jan 88 12:06 EST
From: SYSRUTH%utorphys.bitnet@RELAY.CS.NET
In terms of CPU and other resource usage, I would like to know which of these
is more expensive and precisely why. We are considering changing our charging
algorithm to reflect the fact that things other than CPU are our main costs
these days, and I/O operations are among the things we might charge for. I
would assume that buffered I/O is generally to/from things like terminals
and tape drives (if using RMS and not direct QIO's), while direct would be
for devices such as array processors, image processors (and display screens),
etc. Where exactly do the disks come in? I guess most system devices must be
buffered somewhat, but to be honest, this is an area where my understanding
has always been a bit fuzzy. So is it more expensive to do number of single
direct I/O's to a device, or to fill something up and flush it out a bunch
at a time?
If I had to make a guess, I'd say there probably isn't that much difference,
since direct I/O's may be smaller but more of them are needed, while buffered
I/O has to collect somewhere before the operation that writes/reads it.
Can someone explain this to me clearly and cleanly?
Many thanks to all who respond - this may be a question that puzzles others
as well.
Ruth Milner
Systems Manager
University of Toronto Physics
SYSRUTH@UTORPHYS (BITNET)
the difference is hardwre and device driver dependent. It is not something under
users control. Disks, tapes, and much network hardware are DMA devices and do
direct I/O. the operation is queued, the users buffer is validated and wired
down, and the hardware is started. transfers occur directly to memory without
CPU intervention.
When a buffered I/O is queued, the users buffer is validated, a block of
non-paged memory is allocated, and depending on direction, the buffer is copied
to it. the driver either sends chars from the in pool buffer, or recieves chars
and stuffs them into the buffer. note: the driver software may use DMA to
actually effect the transfer with the outside world (eg: most modern terminal
controllers are DMA, but the i/o is buffered because it does examine each char
at length) At the end of a read, the pool buffer is copied into the users. since
data is transferred (at interrupt level) to/from already wired memory (non-paged
pool), the users buffer does not have to be wired down, as the copy operation
can fault.
what kind of I/O to perform is chosen by the driver writer in advance, based on
the nature of the hardware and driver philosophy (it is a bit in the driver
tables that you control) The large vs. small I/O you are mentioning in your
message is a function of RMS record blocking. RMS always uses a "natural" block
for the device (for disks this is some multiple of a disk sector, for a tape it
is the block size, which is usually much larger than a single record to avoid
tape waste) and (un)packs it for the user. No $qio is involved when the user
asks/gives RMS (for) a record, it is just a subroutine call (that transfers into
EXEC mode), and all the resources involved in the (un)pack are charged by the
normal CPU time mechanisim. RMS will do read-ahead (issuing $qios for several
large blocks) but it tries hard to always write the data as soon as possible.
In general the the only reasonable things to account for on a VMS system are CPU
time (and the VMS mechanisim is not absolutely accurate - it isn't consistent
about who it charges for some system operations, and it charges a fixed amount
for some other system operations no matter how much less time they take) connect
time, disk space, and trees destroyed. The I/O counts for a given job vary too
much with system load and tuning, and a page fault may or may not involve disk
access, so no equitable charging is possible (and with modern page printers,
accounting for tree consumption is difficult)
this may seem restrictive, but you will catch much user flack if running the
same program over the same data (something physics types tend to do) results in
greatly varying prices, and you will have enough gripes without that one.
<dp>nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (01/19/88)
First, the difference between buffered and direct I/Os is determined
by the device driver. Devices which can do direct I/O (disks, array
processors, image processors, tapes, etc.) do their DMA directly
to or from buffers in the user's virtual memory space. Buffered
devices (terminals, some network operations, etc.) use buffers
allocated in system space in nonpaged pool. In earlier versions
of VMS the difference reflected that between DMA devices and programmed
I/O devices (usually the DZ11 terminal controllers). So to summarize
the differences are concerned with data transfers to/from the buffers
in the user process's virtual address space:
direct I/O devices transfer data directly to/from the user
buffers by locking those buffers into memory, double-mapping
them into system address space (to allow non-process context
reference by the device driver) and initiating DMA operations
between these buffers and the device.
buffered I/O devices transfer data between the user buffers and
system buffers in nonpaged pool. The device driver then uses
either DMA (new terminal controllers, network interfaces) or
programmed I/O to move data between the system buffers and the
device.
> In terms of CPU and other resource usage, I would like to know which of these
> is more expensive and precisely why.
Buffered I/O can be more expensive in CPU time (extra memory move) but
the amount of data transferred in each operation is usually fairly small
for buffered I/O. Depending upon the device (such as DZ11s), programmed
I/O between the system buffers and the device can use *lots* of CPU time
(i.e. DZ11 causes lots of interrupt processing). Buffered I/O uses
system memory resources (nonpaged pool).
Direct I/O requires CPU overhead to setup (map the user buffers into
system space, lock buffers into memory, setup bus adapter maps for the
Unibus or QBus) but then the DMA operation does not require the CPU.
Typically direct I/O is used for DMA devices and large operations
(disks and tapes).
Note that disk I/O still uses direct I/O even with RMS. The RMS buffers
the direct I/O is to/from are in the process's virtual address space.
So, RMS buffering does not count as buffered I/O per se. RMS buffering
allows lots of record operations to be done to/from the RMS buffers and
then direct I/O to/from the disks in large chunks as set by the RMS
buffer size and multibuffer count parameters.
= Frank J. Nagy "VAX Guru & Wizard"
= Fermilab Research Division EED/Controls
= HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY)
= BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/220 Batavia, IL 60510