tencati@JPL-VLSI.ARPA (01/14/87)
A system manager on another system here at JPL asked me to forward the following question to the list: Can the VIRTUALPAGECNT parameter in SYSGEN be set to something larger than the 300,000 page limit specified as the "Maximum", and if so, what are the possible ramifications of such a move? He says he is using the page file as a buffer for loading in a data stream from an AMPEX tape drive into an array in an application program. He says there are no bus-contention problems, but it appears the application program aborts due to the vax not being able to read the data in fast enough. The application is written in fortran, but the tape I/O routine is in Macro. The vax is being used by a single user with a 400,000 page file quota and a 400,000 block page file. The data is read into a 280,000 byte buffer using 3 QIOs. The process runs with a wsextent of 5100 pages, and as soon as the process exceeds (hits) this limit, the process bombs. Aside from programming style, is there anything in VMS that could be modified to help these folks with their problem? Thanks, Ron Tencati System Mgr, JPL-VLSI.ARPA
LEICHTER-JERRY@YALE.ARPA.UUCP (01/16/87)
A system manager on another system here at JPL asked me to forward the
following question to the list:
Can the VIRTUALPAGECNT parameter in SYSGEN be set to something larger
than the 300,000 page limit specified as the "Maximum",
Enter the DISABLE CHECKS command to INSTALL, and it will let you set the
parameter to anything you like. (However, as I discuss below, this appears
to have nothing to do with the problem you actually want to solve.)
and if so,
what are the possible ramifications of such a move?
Once you exceed the maximum, you are into "unsupported" territory. That
doesn't mean that it won't work - it mainly means that it hasn't been tested
by the VMS group, so they aren't willing to GUARANTEE that it will work. Most
likely, it will work just fine.
He says he is using the page file as a buffer for loading in a data stream
from an AMPEX tape drive into an array in an application program. He says
there are no bus-contention problems, but it appears the application
program aborts due to the vax not being able to read the data in fast
enough. The application is written in fortran, but the tape I/O routine
is in Macro. The vax is being used by a single user with a 400,000 page
file quota and a 400,000 block page file. The data is read into a 280,000
byte buffer using 3 QIOs.
The process runs with a wsextent of 5100 pages, and as soon as the process
exceeds (hits) this limit, the process bombs.
The VIRTUALPAGECNT parameter controls the maximum VIRTUAL size of the process.
The process WSEXTENT places an absolute limit of 5100 limits the total number
of pages the process can actually have in memory at once. When the process
exceeds that limit, it must lose a page from its working set. Since the
process bombs at that point, it looks as if the overall system is simply not
fast enough to keep up with the tape while trying to page stuff out. If this
is indeed the case, the only way the user will EVER succeed is to allocate
enough real memory to hold EVERYTHING coming off the tape in one burst.
Assuming the 280,000 byte buffer represents the total size of one of these
data bursts, that should require only some 547 pages; so I must assume he is
trying to read many of these, one after another. Find out just how much data
is involved, and get and allocate enough physical memory, if possible.
Your user appears to be running right at the edge of what his VAX can do.
What pushes him over the edge is impossible to tell from your description.
For example, the user "says there are no bus-contention problems" - what leads
him to say that? I suspect, in fact, that it's exactly contention between
the tape drive and the paging disk that may be to blame. If so, and those
devices are on a common controller or Unibus adaptor or whatever, getting
some more hardware and moving stuff around may solve the problem. If not,
he may just need a bigger CPU, or perhaps some sort of specialized high-speed
I/O controller. (Aptec, for example, makes devices that should be able to
copy such a tape to a disk file for him.)
Aside from programming style, is there anything in VMS that could be
modified to help these folks with their problem?
Again, there's really not enough information here to tell. When you are right
on the hairy edge, small changes can have large effects. It sounds as if it
should be possible to shade things over by enough to let the application run,
but unless just increasing WSEXTENT (and WSMAX, which provides a system-wide
upper bound on any working set) works, your user is almost certainly looking
at buying some more hardware. (Note that any SYSGEN configuration you come
up with is likely to be very highly specialized for this one application, and
should not be used for anything else.)
In terms of programming style, one other possibility - if the tape drive is
controllable enough - is to write a separate program that reads the file,
perhaps in small chunks - with pauses to backspace in case of overshoot, as
required - and dumps the data into a file backing up a section. Then, rather
then using the stuff in the page file, just map a section to the file. This
approach would be appropriate if multiple analyses are made of one tape, so
that the overhead in reading the tape was amortized over multiple uses of the
data.
-- Jerry
-------