🚀 go-pugleaf

In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
Hallam-Baker) writes:
|> In article <1993Jan20.001847.1807@eco.twg.com>, reece@eco.twg.com (Reece R.
|> Pollack) writes:
|> 
|> |>In article <C13yJK.CMJ@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
|> |>Hallam-Baker) writes:
|> |>|>What matters a damn sight less than a 64 bit O/S is a 64 bit
database. When
|> |>will
|> |>|>Rdb be 64 bit is the real question.
|> |>
|> |>Not being sarcastic in the least, what part of RDB needs to be 64 bit?
|> |>Expanding the address space from 32 to 64 bits is not in itself going
|> |>to make things better, unless the application is starved for memory.
|> |>Remember that Alpha/VMS doesn't suffer from the Vax/VMS 512Mb physical
|> |>memory limitation, even though any single process is still limited to
|> |>a 2Gb virtual address space.
|> 
|> Each of our events is approx 100Kb
|> 
|> We take 10 million of them per second.
|> 
|> Even with filtering we take Terabytes of data per month.
|> 
|> 2Gb is small beans, we will be getting machines with that sort of
memory within
|> the next few years. The successor machine to ZEUS will be producing 2 GB
|> events.
|> 
|> 
|> |>|>Although it would be handy to do big transfers of data - the VMS
64K limit
|> |>is
|> |>|>far too small, this is not essential yet. It will become essential once
|> |>alphas
|> |>|>start operating with a 64K page size though!
|> |>
|> |>The limitiation of I/Os to 64Kb was lifted quite some time ago. The
VAX/VMS
|> |>I/O User's Reference Manual: Part 1 for VAX/VMS V4.4 states:
|> |>
|> |>"Non-DSA disk devices can read or write up to 65.535 bytes in a single
|> |> request. DSA devices connected to an HSC50 can transfer up to 4 billion
|> |> bytes in a single request. In all cases, the maximum size of the transfer
|> |> is limited by the number of pages which can be faulted into the process's
|> |> working set and then locked into memory."
|> |>
|> |>The relevant fields of the IRP were expanded to 32 bits during the
V3 -> V4
|> |>enhancements.
|> 
|> Read the device driver manual and look at the format of the QIO. The 16 bit
|> length is hard coded in there.
|> 
|> What I would like to do is to read in single events with single reads.
|> 
|> --
|> 
|> Phill Hallam-Baker

Hmmm, it's been awhile since I've looked at this, but I thought the
16-bit QIO field was a transfer count of _things_, not necessarily
bytes. The driver could convert that number to a larger one for the
IRP's 32-bit field.

Chris Day