HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

I/O size

The Question is:

I am the system manager for data archive for the Hubble
Space Telescope.  We are currently porting the system to
a 2100 Alpha server.  Our problem is that the incoming
data rate will go up to at about 7-10 Gigabytes starting
in early 1997.  The outgoing data rate will be about the
same.  We need all the I/O performance we can get.

Are there any plans to raise the maximum I/O size above

The Sony optical drives we are using have a 4Mb buffer.
We think that if we could throw more data at the system
per I/O we could increase our throughput.  At least that
is what the software developers are telling me.

The Answer is:

    The size of I/O depends on your hardware. In the SCSI world, it
    requires that the port AND class driver support larger single
    I/O requests. The basic $QIO system service on Alpha accepts
    transfer sizes of up to 32 bits' worth of bytes (I'd limit it
    to 31 for safety though...).

    There are a number of SCSI port drivers...most of the current
    generation in fact...that for one reason or another can handle at most
    64K at a time. The drivers break this up for you. We are looking at
    supporting longer I/O, but be aware that this may well be handled as
    a site override of some sort, since huge I/O could tie up the bus
    between commands for longer than we like to see it in general
    purpose situations.

    Another point to be made: the measurements of SCSI driver performance
    on several adapters indicate we are driving them at pretty close to
    their maximum I/O rates, and the internal splits into 64K units may
    not be the bottleneck here. We are working also on getting faster SCSI
    controllers and wide support, and in fact wide SCSI drives are working
    in house on several controllers now. Wide drives have twice the data
    rate limits and are appearing on the market.

    Your I/O drain devices (tapes? disks?) may want to be on different
    busses than the I/O source ones.

    Some other performance boost techniques are also in the works in the
    SCSI space.