🚀 go-pugleaf

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