HDTenEightyP/NetNews huggingface dataset:
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: No 64-bit OpenVMS soon?
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Sat, 23 Jan 1993 22:13:35 GMT

In article <1993Jan22.172623.15644@oracle.pnl.gov>, jordan@warped.pnl.gov (Randy
Jordan) writes:
|>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:
|>|>
|>|>
|>|>Each of our events is approx 100Kb
|>|>
|>|>We take 10 million of them per second.
|>|>
|>	1MB per second?

No, !00Kb times 10 MHz equals 1 Terabyte /sec

|>|>Even with filtering we take Terabytes of data per month.
|>|>
|>	Wrong...you take in 3.6TB per hour at the rate stated!

No, with filtering, we reject down to a rate of 5 Hz. Also thats 3.6 Eta-bytes
per hour, not Terrabytes.

If you are interested I can email one of our papers. But basicaly its a three
stage trigger running at 1KHz, 100Hz and 5Hz triggers, data transport volume is
minimized by data locality, geometric and pipelined parallelism are employed and
the whole shooting match cost over $50 Million just for the electronics.

This is why we need VMS and can't use UNIX!

|>|>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.
|>|>
|>	2GB is image size NOT dbms size.

Would it give the game away unduly if I said that I fail to make the
distinction? We already have code systems in excess of 1 million lines of
FORTRAN - and those were written by hand. The next generation of systems will be
much much larger and involve much larger amounts of code.

We already have one system that uses a five level compiler scheme, ten pages of
source code balloon to tens of thousands of lines of compiler code. The data is
the specification and the specification is the program.


--

Phill Hallam-Baker
Newsgroups: vmsnet.alpha
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Subject: Re: Convincing the management
Originator: news@kittyhawk.ecn.uoknor.edu
Date: Mon, 25 Jan 1993 16:58:16 GMT
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma

In article <1993Jan22.233827.11919@convex.com>, rosenkra@convex.com (William Rosenkranz) writes:
|>while SUNs might not be the way to go (SPARC is way behind the RISC curve),
|>i would put HP up against DEC any day. the PA-7100 chip can easily outperform
|>the alpha running at a much higher clock speed. considering that an under $50k
|>HP 735 turns in SPECfp92 of 150 while the $316k DEC 10000 (at 200 MHz) does
|>only 200 seems like the 21064 is a weak implementation of the basic Alpha
|>architecture (which does have some interesting aspects). HP is even better
|>with DP Linpack (40.8 MFLOPS vs the 10000's 42.5 or so). also the 1000x1000
|>Linpack for alpha is actually lower than HP's (based on DEC's numbers in
|>the november announcement). this tends to tell me that the tiny on-chip
|>alpha caches and high latency off-chip cache is weak. also the fact that
|>I/O busses off the chip run at most half the system clock speed does not
|>help much either. i would expect a 200 MHz chip to get at least 180 MFLOPS
|>on 1000x1000 linpack, if it were designed with technical (floating point)
|>computing in mind. i also think HP has a better graphics story than DEC,
|>though i am far from an "expert" in graphics.

Ooops, you bit off on the HP marketing hype. Yes the initial benchmarks
I have seen indicate that the HP outperforms the Alpha (but just edges
out the $35K DEC 3000/500). As DEC RISC compiler techinology for
the Alpha is still young. As the benchmarks using the KAP preprocessor
have pointed out, you can squeeze as much as a %40 speed increase out
of the Alpha. I predict you will seem some improvements on the 
benchmarks as DEC learns more about optimizing their code. HP has done
a great job, though, of getting more bang out of their architecture.

|>-bill
|>rosenkra@convex.com

How is Morgenstern? (and Hamlet?)
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
Newsgroups: vmsnet.alpha,comp.sys.dec
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Subject: Re: No 64-bit OpenVMS soon?
Organization: Boeing Computer Services
Date: Fri, 22 Jan 1993 06:27:30 GMT

Actually, I was disappointed to read that the Alpha is never going to support
true 64 bit addressing.  Depending on the page size the most you can expect
is 55 bits.
Why does this make a difference?  I for one, was excited about the possibility
of building an in-RAM relational database.  I had been doing some calculations
on the subject and some design studies for a sharable multiport RAM which 
would hold the database.  Like a solid state disk, it would be fast, with 
average access times of on the order of microseconds.  Unlike a solid state
disk, which looks like a disk drive, this gizmo could be accessed without
intervention (or with minimal intervention) from the OS.
For another, I was intrigued with the idea of building a minimal microprocessor
system using the address lines in lieu of address decoding for chip select logic.
Several people have pointed out that anybody interested in building something
around an Alpha obviously isn't building a minimal microprocessor.

Jeff Silverman, Boeing Commercial Airplanes.

Xref: sparky vmsnet.alpha:136 comp.sys.dec:7089
From: jeh@cmkrnl.com
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: Re: No 64-bit OpenVMS soon?
Date: 22 Jan 93 21:25:33 PST
Organization: Kernel Mode Systems, San Diego, CA

In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de 
(Phill Hallam-Baker) writes:
> |>"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.

Where are you looking, and in what "device driver manual"?  

The code in places like EXE$WRITE (often used as an FDT routine for handling
"generic" direct I/O requests) handles the P2 argument (transfer length in
bytes) as a longword.  It's saved in IRP$L_BCNT as a longword.  Many device
drivers return the transfer length in the second and third words of the IOSB,
as a longword.  

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, or hanrahan@eisner.decus.org  Uucp: uunet!cmkrnl!jeh
Xref: sparky vmsnet.alpha:133 comp.sys.dec:7080
From: jordan@warped.pnl.gov (Randy Jordan)
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: Re: No 64-bit OpenVMS soon?
Date: 22 Jan 93 17:26:23 GMT
Article-I.D.: oracle.1993Jan22.172623.15644
Reply-To: jordan@warped.pnl.gov (Randy Jordan)
Organization: Battelle, Pacific Northwest Laboratory


In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
|>Xref: pnl-oracle vmsnet.alpha:126 comp.sys.dec:6578
|>Newsgroups: vmsnet.alpha,comp.sys.dec
|>Path: pnl-oracle!news.u.washington.edu!usenet.coe.montana.edu!saimiri.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!uunet!mcsun!dxcern!dscomsa!zeus02.desy.de!hallam
|>From: hallam@zeus02.desy.de (Phill Hallam-Baker)
|>Subject: Re: No 64-bit OpenVMS soon?
|>Message-ID: <C19M1B.KHM@dscomsa.desy.de>
|>Sender: usenet@dscomsa.desy.de (usenet)
|>Reply-To: Hallam@zeus02.desy.de
|>Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
|>References: <1993Jan15.194312.3438@sol.UVic.CA> <1993Jan18.172458.24506@eco.twg.com> <1993Jan18.211506.27601@oracle.pnl.gov> <1jg5msINN1mk@manuel.anu.edu.au> <C13yJK.CMJ@dscomsa.desy.de> <1993Jan20.001847.1807@eco.twg.com>
|>Date: Fri, 22 Jan 93 09:03:10 PST
|>Lines: 53
|>
|>In article <1993Jan20.001847.1807@eco.twg.com>, reece@eco.twg.com (Reece R.
|>Pollack) writes:
|>
|>
|>Each of our events is approx 100Kb
|>
|>We take 10 million of them per second.
|>
	1MB per second?
|>
|>Even with filtering we take Terabytes of data per month.
|>
	Wrong...you take in 3.6TB per hour at the rate stated!
|>
|>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.
|>
	2GB is image size NOT dbms size.
|>
--

	55 bit addressing gives     36,029 TB of space,
	64 bit                  18,446,744 TB of space.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	To Thyne Own Self be true...
	                             myne opinions are.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: vchow@helios.UUCP (Victor Chow)
Newsgroups: vmsnet.alpha
Subject: Re: cpu time measurement on VMS
Date: 21 Jan 93 23:02:45 GMT
Organization: Consilium Inc, Mountain View, CA

In article <C164Hn.223@dscomsa.desy.de> you write:
|> In article <1993Jan20.164619.8700@eecs.nwu.edu>, shil@eecs.nwu.edu 
|>   (Lei Shi) writes:
|> 
|> |>
|> |>Hi: 
|> |>  ... My question is how I can measure the total CPU used by the 
|> |> execution of the program ... in VMS ...
|> |>					Your Sincerely,
|> |>
|> |>					Lei Shi
|> 
|> The are various alternatives. The simplest way is to run your program as 
|> a batch job.   ...   Otherwise, you can use
|> the $ SHOW PROC /ACC for an interactive session but that cannot (as far as
|> I am aware) be zeroed before execution of a program. Finally, if this is not
|> sufficient you should investigate the run time library timer routine
|> LIB$SHOW_TIMER, LIB$STAT_TIMER ... (try $ HELP RTL LIB$ *TIMER*.
|> 

Lei Shi,

Using LIB$ or SYS$ calls allow you to get accurate accounting information about
a process the way you want.  The disadvantage is that you have to modify your
source code to do so (and provided that you still have the source code).

Submitting an image to a batch job and get the accounting information from the 
log file should get what you need.  However your LOGIN.COM and the system
SYLOGIN.COM should be relatively short and do not run resource hogging command
s or images (relative to your actual image).  Otherwise the accouting info of
the batch job does not accurately reflect the resources used by your image
only. Remember that a VMS batch job includes not only the images/commands you
want run, but also other commands or images (such as LOGIN.COM and SYLOGIN.COM,
etc) that are executed as part of the batch job.

Another simple alternative that requires no modification to your code and LOGIN/SYLOGIN.COM is to do the following steps:

1. create a file, say, your_image.COM like this:
    $ run your_image.EXE        or (@ your_dcl.COM)
    $ logout/full

2. then at the DCL prompt, enter
    SPAWN @your_image.COM

The SPAWN starts a child process which starts with "zeroed" accounting info to 
run your image and the "logout/full" command.  The "Accounting information" 
that logout/full prints should be very close to what "your_image" needs (plus 
the overhead needed by the SPAWN(?), @your_image.COM, and "logout/full",etc).  
(I assume your program takes a lot more resources to run than a simple SPAWN
command.) 

As long as you are not trying to precisely measure a tiny image that uses very 
little resource and that you don't need to get the process' accounting info at 
different parts of your image, this simple method should be adequate. 

Good luck!  8-)

Victor



Xref: sparky vmsnet.alpha:151 comp.sys.dec:7114
From: muswick@vs2.uh.cwru.edu (Gary James Muswick)
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: VMS on ALPHA PC's
Date: 25 Jan 1993 20:35:06 GMT
Organization: Image Analysis Center, Univ. Hospitals of Cleveland
Distribution: world
Reply-To: muswick@vs2.uh.cwru.edu
NNTP-Posting-Host: max.uh.cwru.edu
Keywords: Alpha PC, VMS


I just talked with my sales rep. and was informed that two new Alpha PCs will
not have VMS on them at anytime.  I had read about 6-9 months ago in DR that 
VMS would be available shortly after the introduction of the PC's when VMS was 
ported to the EISA bus.  Now the report is for no plans to write EISA drivers 
for VMS or a x-window server for the video.  On top of this, microsoft has 
again slipped the into date for NT till at least March and from some inside 
info, NT won't be ready till June!  My DEC rep says the pc boxes are waiting 
to ship, they just need NT.  --- All of this has me bummed.

I currently own a lowly XT converted to a 286, cga etc.  The reason I have
never bought a better pc is that I have a cluster of 12 vaxes, one of which
is a 4000-90.  I do a lot of VMS/X-Windows work.  It has seemed stupid to
spend alot of money on a home system when I have so power at work.  But now
an Alpha PC when first announced 9 months ago, that I could do some 
development work at home and on weekends would be an answer to my problems.
I could use EVE, VMS-C, Motif, and DECWrite just as I do at work. same files
etc.  And SoftPC would give me DOS if I needed it.  (NT on the Alpha-PC also
has to Soft-PC or something like it to run DOS aps.)

I think DEC is missing market share waiting for NT.  Get the boxes out running
VMS and SoftPC now.  I know I want one, my desk at home has an open spot that
would fit one real nicely.  

I know that DEC may come out with a low cost workstation that I could use,
but I want to have a powerful PC platform too.

I hope this makes it to some decision makers at DEC to rethink the PC policy
and VMS.  If I, being a research engineer in a University that's wants to do 
VMS development at home and willing to cough up 4-5k for the box and 2k for
misc licenses, then there are probaly lots of other developers, 3rd party
software, etc. that would want to do the same.  They'd either cough up the
money or their employers/clients would.  Real VMS at home is a time that has
come.

Gary Muswick
Image Processing Engineer/Supr.
muswick@vs2.uh.cwru.edu 
(216) 844-7793
From: vchow@helios.UUCP (Victor Chow)
Newsgroups: vmsnet.alpha
Subject: Re: cpu time measurement on VMS
Date: 21 Jan 93 22:57:01 GMT
Organization: Consilium Inc, Mountain View, CA

In article <C164Hn.223@dscomsa.desy.de> you write:
|> In article <1993Jan20.164619.8700@eecs.nwu.edu>, shil@eecs.nwu.edu 
|>   (Lei Shi) writes:
|> 
|> |>
|> |>Hi: 
|> |>  ... My question is how I can measure the total CPU used by the 
|> |> execution of the program ... in VMS ...
|> |>					Your Sincerely,
|> |>
|> |>					Lei Shi
|> 
|> The are various alternatives. The simplest way is to run your program as 
|> a batch job.   ...   Otherwise, you can use
|> the $ SHOW PROC /ACC for an interactive session but that cannot (as far as
|> I am aware) be zeroed before execution of a program. Finally, if this is not
|> sufficient you should investigate the run time library timer routine
|> LIB$SHOW_TIMER, LIB$STAT_TIMER ... (try $ HELP RTL LIB$ *TIMER*.
|> 

Lei Shi,

Using LIB$ or SYS$ calls allow you to get accurate accounting information about
a process the way you want.  The disadvantage is that you have to modify your
source code to do so (and provided that you still have the source code).

Submitting an image to a batch job and get the accounting information from the 
log file should get what you need.  However your LOGIN.COM and the system
SYLOGIN.COM should be relatively short and do not run resource hogging command
s or images (relative to your actual image).  Otherwise the accouting info of
the batch job does not accurately reflect the resources used by your image
only. Remember that a VMS batch job includes not only the images/commands you
want run, but also other commands or images (such as LOGIN.COM and SYLOGIN.COM,
etc) that are executed as part of the batch job.

Another simple alternative that requires no modification to your code and LOGIN/SYLOGIN.COM is to do the following steps:

1. create a file, say, your_image.COM like this:
    $ run your_image.EXE        or (@ your_dcl.COM)
    $ logout/full

2. then at the DCL prompt, enter
    SPAWN @your_image.COM

The SPAWN starts a child process which starts with "zeroed" accounting info to 
run your image and the "logout/full" command.  The "Accounting information" 
that logout/full prints should be very close to what "your_image" needs (plus 
the overhead needed by the SPAWN(?), @your_image.COM, and "logout/full",etc).  
(I assume your program takes a lot more resources to run than a simple SPAWN
command.) 

As long as you are not trying to precisely measure a tiny image that uses very 
little resource and that you don't need to get the process' accounting info at 
different parts of your image, this simple method should be adequate. 

Good luck!  8-)

Victor

Newsgroups: vmsnet.alpha
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: User-written device drivers on Alpha/VMS
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Wed, 27 Jan 93 17:37:13 GMT


In article <1993Jan26.125545.1@ssrl01.slac.stanford.edu>, tcox@ssrl01.slac.stanford.edu (Tony Cox - (415)926-3105) writes:
|>
|>Does anyone have any experience with user-written drivers on the Alpha?
|>
|>I am hearing conflicting information on the availability of documentation
|>for user written drivers, and hope that someone in this news group can clarify
|>the situation.
|>
|>A specific concern for me is porting my home grown pseudodriver. On VAX/VMS,
|>this driver processes a series of QIO's from application programs,
|>originally written to control a CAMAC serial highway driver. For compatibility
|>with existing systems, these applications cannot be rewritten. The QIO's
|>come down from the application specifying (in p1-p6) three buffers in 
|>user space. The driver locks these pages in memory, using the usual
|>exe$write/read/modify routines, and then passes the request off to a
|>user-written ACP using EXE$QIOACPPKT.
|>The ACP interprets the information (in this case, generating network requests
|>to uVAXIII systems running VAX/ELN), returns information and status into the
|>buffers in the requesting user process, and then completes the request
|>using COM$POST.
|>
|>So this driver/ACP combination is relatively simple (no hardware access, except
|>via supported network drivers), but it _does_ do some things which I would have
|>thought would require some (possibly extensive) code changes when running on
|>the Alpha.
|>
|>For example, the ACP uses system page table entries to map the original
|>user request.
|>
|>Anyone done such a thing, or know about available documentation?
|>
|>Thanks
|>
|>Tony Cox, Stanford,CA
|>TCOX@SSRL01.SLAC.STANFORD.EDU(INet)	SSRL01::TCOX (HEPNet)
|>TCOX@SSRL750 (BitNet)
|>

Tony,
	From what I understand at the beginning DEC's official position 
was "no user written device drivers in V1.0"... however, recently I have seen 
courses that are being taught by DEC on this subject... so I 
guess they have backed off from that position. Realistically, it is not 
very hard to port a pseudo driver to AXP, I have ported a number of 
them in the last year... If this issue is really important to your operation
I would push on the local porting center for more concrete information, you
know it must be available since DEC ported a number of drivers themselves...

-Larry.
Newsgroups: vmsnet.alpha,comp.sys.dec
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: No 64-bit OpenVMS soon?
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Fri, 22 Jan 1993 17:03:10 GMT

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
Xref: sparky vmsnet.alpha:143 comp.sys.dec:7101
From: gezelter@rlgsc.com
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: Re: No 64-bit OpenVMS soon?
Date: 23 Jan 93 12:36:35 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
> ...
> 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
-- 
Phill,
 
I understand your problem. Several years ago I had almost exactly 
the same problem with an image scanning system on an RSX-11M 
platform. My solution then, which should still be valid today, is 
to have the DRIVER to the additional validation. While it is not 
pretty, it is feasible.
 
This solution is truly only feasible for the realtime IO, but 
that is where it matters the most.
 
I hope that the above is helpful. If I have been unclear, or if I 
can be of further assistance, please feel free to contact me via 
Email or phone.
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
Xref: sparky vmsnet.alpha:131 comp.sys.dec:7079