HDTenEightyP/NetNews huggingface dataset:
From: herman@nosc.mil (John W. Herman)
Subject: Re: Alpha fft performance
Organization: Naval Ocean Systems Center, San Diego, CA
Date: Thu, 7 Jan 1993 15:41:14 GMT

jpp@pipo.paris.sgi.com (Jean-Pierre Panziera - SGI PARIS) writes:

>In article <1993Jan4.154245.13258@crl.dec.com>, payne@crl.dec.com
>(Andrew Payne) writes:
*** Stuff deleted ***
>  An array of 1024 complex numbers indeed uses 8 Kbytes. However to compute an 
>  FFT you need an extra array of Sines and Cosines of same size (8 kBytes).
>  The total space required for this FFT is then at least 8+8 = 16 kBytes.
>  So the assumption "just fits in the on-chip 8K D cache" seems abusive. ???
Not quite true.  If I recall correctly, you need a table of 256 sine or
cosine values.  The rest are computed through index arithmetic and sign
conversion.  But the basic point is true.  It all doesn't fit in a 8K
cache.  I assume that there is some effort to optimize memory accesses
so that main memory access time is not a problem.  As an aside, a DSP
computer salesman once told me that the time to compute a 1024 point
complex FFT is an important selling point and his company ( and others)
expended great amounts of time to make this number as small as possible.
Even to the detriment of other parts of the software library.
From: andyb@twisty.eslvcr.wimsey.bc.ca (Andy Babinszki)
Newsgroups: comp.sys.dec
Subject: Connecting Hard Disks >RD54 to MicroVAX 2000?
Date: Mon, 11 Jan 93 08:19:06 PDT
Organization: A Maze of Twisty Little Passages, All Alike
Reply-To: andyb@twisty.eslvcr.wimsey.bc.ca (Andy Babinszki)
X-Mailer: uAccess - Macintosh Release: 1.6v1

I have a uVAX 2000 with a pair of RD54s ( 150 MB ea. ).  It is implied
in the manual that only those disks which can be recognized and formatted
by the uVAX 2000 can be used (ie. the RD54 IS the biggest that can
be recognized).  Is there a way to connect anything bigger?

Andy.

---
Andy Babinszki          andyb@twisty.eslvcr.wimsey.bc.ca
                        "Hello?  Hello?"  (604) 664.4545
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.sys.dec
Subject: Unix Review review of Alpha/OSF
Date: 13 Jan 1993 02:55:56 GMT
Organization: Widener News/Mail Gateway
Distribution: world
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20


Anyone catch the review of Alpha/OSF by the editor of Unix Review in the
February issue?  Basically, (and I am writing this from memory) he states that
he talked to a number of ISV's at Comdex and said that there are only 50-100
applications available for OSF/1.  His reasoning for so few applications (much
less than the stated numbers published by DEC) was that the machines were in
"kernel debug" and DEC was scrambling sending field service people hither and
tither.  I read nothing like that in several newsgroups here.  That bothers me. 
Then of course he goes on to give a glowing review of Sun's rollout at the same
Comdex.  

My question, are Alpha/OSF platformas having kernel debug problems OR (more
hideously) is this just a way biased review OR somewhere in between?

					Rob

                                                     young@tattoo.cs.widener.edu
"Drawn like moths we drift into the city, the timeless old attraction. Cruising 
  for the action.  Lit up like a firefly, just to feel the living night."
       -- Neil Peart 
Xref: sparky comp.sys.dec:6727 misc.forsale.computers.other:1429
From: mcgee@csusb
Newsgroups: comp.sys.dec,misc.forsale.computers.other
Subject: MicroVAX II For Sale
Date: 7 Jan 93 18:19:40 GMT
Organization: California State University, San Bernardino
Nntp-Posting-User: mcgee

Greetings!

I am posting this for a friend, so please respond to him by PHONE rather than 
to me (he does not have Internet access).  Thanks.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
For Sale:

	MicroVAX II, BA23 case, including:

		13MB RAM
		Maxtor 8760 670MB disk w/Emulex QD21 controller
		DHV11 8 line terminal multiplexor
		DELQA Ethernet interface
		TK50/TQK50 tape subsystem
		System Industries 8mm tape interface (no 8mm drive)
		RQDX3 disk controller (no drives)
		VT320 terminal

	$2500.00 or best offer

Call Bob at (714)355-7457 (southern California)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From: bolson@carson.u.washington.edu (Edward Bolson)
Newsgroups: comp.sys.dec
Subject: How do you install disk in VS4000/90?
Date: 8 Jan 93 19:07:57 GMT
Organization: University of Washington, Seattle
NNTP-Posting-Host: carson.u.washington.edu

I became the proud new owner of a VAXstation 4000-90 a couple months ago.
I had previously purchased a Fujitsu M2624FA to install in it, having received
a better price than the RZ25L.  Now it seems I am stumped.  The seller, 
r-squared, cannot find the appropriate mounting bracket or equipment to allow
me to install the disk in the "H-bracket" inside the cabinet.

Does anyone out there have any advice or comments?  Besides insisting on gettin
me an RZ25-L to replace it, I have considered just connecting the cables and
leaving the thing unsecured.  Not a very good solution, I suspect.

Thanks to anyone!

Ed


-- 
Ed Bolson
University of Washington  Cardiovascular Research               (206)543-4535
bolson@u.washington.edu (preferred)
bolson@max.bitnet                bolson@milton.u.washington.edu (if you must)
Newsgroups: comp.sys.dec,comp.dsp
From: kirk@tallis.enet.dec.com (Matthew B. Kirk)
Subject: Re: Alpha fft performance
Organization: Digital Equipment Corporation
Date: Fri, 8 Jan 1993 20:49:31 GMT


In article <1993Jan7.121038.4845@odin.corp.sgi.com>, jpp@pipo.paris.sgi.com (Jean-Pierre Panziera - SGI PARIS) writes...
>  I am not familiar with "Alpha's process cycle counter". Is this a simulator ?
>  Does this tool take in account eventual cache misses ?
>  How do real benchmark compare with your simulation ?

It's in the hardware.

From page 4-118, Alpha Architecture Reference Manual (description of 
RPCC - read process cycle counter):  

	The low order 32 bits of theprocess cycle counter is an unsigned
  	32 bit integer that increments once per N CPU cycles, where N is
 	an implementation-specific integer in the range 1-16.  The cycle
 	counter frequency is the number of times the process cycle counter 
	gets incremented per second, rounded to a 64 bit integer.  The
	integer count wraps to 0 from a count of FFFF FFFF.  The counter
	wraps no more frequently than 1.5 times the implementation's 
	interval clock interrupt period (whichi s two thirds of the
	interval clock interrupt frequency).  The high-order 32 bits of the
	process cycle counter are an offset that when added to the low-order 
	32 bits gives the cycle count for this process.

	The process cycle counter is suitable for timing intervals on the 
	order of nanoseconds and may be used for detailed performance
	characterization.  It is required on all implementations.  PCC is
	required for every processor, and each processor in a multiprocessor
	system has its own PCC.  

There is also a 'system cycle counter'.

> 
>|> The algorithm is a radix-4 algorithm, and is basically just a C translation
>|> of the FORTRAN code in "DFT/FFT and Convolution Algorithms" by Burrus and 
>|> Parks (with a few tweaks, of course).
> 
>  Are the results of your transform ordered, or are they "bit reversed" ?
> 
>Thanks you in advance.
> 
>---
>    ___   ___/       ___   /       ___   /	Jean-Pierre Panziera
>         /          /     /       /     /	jpp@paris.sgi.com
>        /          ______/       ______/	
>       /          /             /		
> _____/       ___/          ___/		
=============================================================================
Matthew Kirk				  	     kirk@tallis.enet.dec.com

All opinions expressed here are mine and do not reflect those of Digital
Equipment Corporation.
=============================================================================
Newsgroups: comp.sys.dec
From: sgccgdc@citec.oz.au (Greg Clough)
Subject: ULTRIX v4.3 (Should I do it?)
Organization: CITEC
Date: Fri, 8 Jan 1993 03:42:08 GMT

Just a quick one:  I am running a DECstation 5000/120 on ULTRIX 4.2a.  The
ULTRIX 4.3 CD arrived about a month ago and I was contemplating actually
installing it.

Has anybody had any bad experiences that would sway me away from installing
it?  E-Mail is preferred.

Thanks.  Greg Clough.  (E-Mail:  sgccgdc@citecuc.citec.oz.au)

--------------------------------------------------------------------------------
     CCCCCCCC II TTTTTTTT EEEEEEEE CCCCCCCC
    CC       II    TT    EE       CC              Centre for          _--_|\
   CC       II    TT    EEEEE    CC         Information Technology   /      *
  CC       II    TT    EE       CC            and Communications     \_.--._/
 CCCCCCCC II    TT    EEEEEEEE CCCCCCCC     (Queensland, Australia)        v
--------------------------------------------------------------------------------
From: annen@forsyth.wsnc.org
Newsgroups: comp.sys.dec
Subject: CD ROM for BI bus (VAX 6210)
Date: 7 Jan 93 14:41:56 EST
Organization: Forsyth County, Winston-Salem  NC

Our public library has asked me to look into a CD ROM reader for our VAX 6210. 
I searched through the electronic store and looked through the DEC direct
catalog, but I couldn't find what I was looking for.  I found some SCSI and
Qbus readers, but nothing for BI.  I couldn't find the bus adapters to use the
SCSI or Qbus devices.  (I'm sure there is, or at least used to be, a BI to Qbus
adapter.  I think it was called a KLESI or something like that).  If it comes
down to a choice between a SCSI or Qbus device I would prefer SCSI.  The
library wants to be able to read ISO 9660 format CD ROM disks, so such
capability will be necessary.  I would appreciate any guidence which you can
provide as to what hardware and software will fit their needs.

I would also like to know about any experiences setting up CD ROMs for a
library which any of you might have had.

Please reply directly to me.  I will summarize to the net if the response
warrants it.


John


------------------------------------------------------------------------------
John Annen                                     Voice: (919) 727-2597 x3023
System Support Specialist                      Fax: (919) 727-8045
Forsyth County, NC MIS
Room 603, Hall of Justice
Winston - Salem, NC 27101
Internet: annen@books.forsyth.wsnc.org

My views are not necessarily those of any organization with which I am
affiliated.
Xref: sparky comp.sys.dec:6735 misc.forsale:34827
From: deat@jhunix.hcf.jhu.edu (Arun Thomas)
Newsgroups: comp.sys.dec,misc.forsale
Subject: Pro 350's for sale
Date: 7 Jan 1993 18:29:36 -0500
Organization: Homewood Academic Computing, Johns Hopkins University, Baltimore, Md, USA
Distribution: usa
NNTP-Posting-Host: jhunix.hcf.jhu.edu

The Chemical Engineering department in Johns Hopkins Univ. has a couple of
PRO-350 computer complete with monitor, harddisk, floppy, etc. that they 
would like to get rid of to anyone who is intersted. Name you price, and 
come and pick them up. There is also a la100 dot-matrix printer that will
be thrown in. It is in Baltimore, MD.

Arun Thomas
deat@jhunix.hcf.jhu.edu
Johns Hopkins University

Newsgroups: comp.sys.dec
From: rince@dcs.warwick.ac.uk (James Bonfield)
Subject: X11R5 server and suport for PMAGB-B
Summary: Is there support for DEC graphics cards on X11R5
Keywords: X11R5 PMAG
Organization: Department of Computer Science, Warwick University, England
Date: Wed, 6 Jan 1993 09:53:44 GMT

Hello,

	I've recently compiled up X11R5 for a Decstation 5000/240. The
original Decwindows I used was only release 4 based. However I've noticed a
substantial performance decrease.

	Hunting around has tracked this down to the fact that X11R5 does not
support the DEC graphics cards. The Imakefile in mit/server/ddx/dec/ws has a
comment saying 'Only color frame buffers are currently supported'. Is this
likely to change? There are two (currently unused) files with support for the
PMAG boards - but they only cover PMAG_[CFD]A. Any help here?

	The only solutions I can think of are to either ignore the slowness to
get a release 5 compatible decwindows server.

	Cheers,

		James

-- 
James Bonfield (jkb@mrc-lmba.cam.ac.uk / rince@dcs.warwick.ac.uk)
Medical Research Council Laboratory of Molecular Biology, Hills Road,
Cambridge, CB2 2QH, England. Tel: 0223 402499   Fax: 0223 412282
Newsgroups: comp.sys.dec
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: Play CD on DEC ?
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Distribution: usa
Date: Tue, 5 Jan 1993 13:50:33 GMT


--
xcd.  On gatekeeper, as AJC points out, and also on Digital's CDROM of UNIX
freeware.

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.sys.dec,comp.dsp
From: payne@crl.dec.com (Andrew Payne)
Subject: Re: Alpha fft performance
Organization: DEC Cambridge Research Lab
Date: Sun, 10 Jan 1993 16:05:08 GMT

In article <1993Jan7.121038.4845@odin.corp.sgi.com> jpp@sgi.com writes:
>  An array of 1024 complex numbers indeed uses 8 Kbytes. However to compute an 
>  FFT you need an extra array of Sines and Cosines of same size (8 kBytes).
>  The total space required for this FFT is then at least 8+8 = 16 kBytes.
>  So the assumption "just fits in the on-chip 8K D cache" seems abusive. ???

Not at all.  As has been already pointed out, you can take advantage of 
symmetry to cut the table size down to 2K bytes (512 coefficients).  Also,
you don't use all the coefficients at each stage (except the last), so the 
_effective_ table size is even smaller.

>  I am not familiar with "Alpha's process cycle counter". Is this a simulator ?
>  Does this tool take in account eventual cache misses ?
>  How do real benchmark compare with your simulation ?

No, it isn't a simulator.  The cycle counter is just a high-resolution timer 
that counts CPU cycles, and is available on all Alpha implementations.
Our FFT times were measured on a real system with the cycle counter.  The 
times given are "wall clock times" which take into account all aspects of the 
execution, including time spent in the memory system.

>  Are the results of your transform ordered, or are they "bit reversed" ?

The times given are for ordered results.  In our code, the digit reverse 
stage takes about 10,000 cycles (about 10% of the time).

-- 
Andrew C. Payne
DEC Cambridge Research Lab
Newsgroups: comp.sys.dec
From: young@eg.ecn.purdue.edu (Mike Young)
Subject: RSX11M-Plus Queue Manager Date Bug
Keywords: rsx pdp-11 qmg
Organization: Purdue University Engineering Computer Network
Date: Wed, 6 Jan 1993 15:32:50 GMT

	I managed to dodge the RSX Queue Manager 1993 bug this morning.
Note dodge, not fix. This bug isn't fixable in any practical sense. Here
are some hints that may be helpful for you do-it-yerselfers (your mileage
may vary, no warranty expressed or implied, etc. etc.):

	In modules QMGGTI.MAC and SHOWP.MAC (UIC [25,10]), you will find a
small number of occurances of the constant "77.". It is added to or subtracted
from the year, in an attempt to encode the year as a 4-bit quantity. Since
93 - 77 = 16, this scheme fails. The dodge is to change 77 to a larger number
(I used 87, but anything from 78 to 93 should work), and rebuild QMG and QMGCLI.
Be careful to change only the occurrances of "77." that are related to the year
calculations - don't just do a blind global replace.

	I observe that this scheme might self-destruct on Jan 1, 2000,
as well...

	This fix was for RSX 11M-PLUS V4.00, BL40. If QMG was changed since
then, all bets are off (see disclaimer above). If you break your system, I am
not responsible.

	Good Luck.


--
    |  Mike Young KA9HZE                |       young@ecn.purdue.edu    |
    |  Purdue University EE Dept.       |       ...!pur-ee!young        |
    |  W. Lafayette, IN  47907          |                               |
    _____________________________________________________________________
From: dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci)
Newsgroups: comp.sys.dec
Subject: USENET in MACRO?
Date: 12 Jan 93 12:47:59 GMT
Organization: Naval Medical Research & Development Command

Does anyone know of a USENET server and/or client which runs on 
VAX 6410...  WRITTEN IN MACRO!?!??

We don't have C or FORTRAN, just MACRO.  ANY response would be
greatly appreciated!!!
-- 
===========================================================================
  phil perucci      | "Any opinions expressed are solely my own views and 
  ssb1pzp@digex.com |  do not reflect the position of any organization"
===========================================================================
From: parsons@postmaster@hq.af.mil (Mike Parsons)
Newsgroups: comp.sys.dec
Subject: DECNET and TCP/IP
Date: 12 Jan 93 13:59:53 GMT
Reply-To: parsons@nic.hq.af.mil
Organization: 7TH Communications Group


-- 
I have a requirement to have users access VAXes across a large TCP/IP backbone.
The users need to be using DECNET as a transport because of application
constraints imposed by the software developer.  The question I have is how or
what products can be used to allow either encapsulation or translation of the
DECNET protocol going into the TCP/IP backbone and reemerging on the other end
and being changed back to DECNET.  The backbone has been known to suffer
congestion on ocasion which may also impact timers, etc.

Any help would be appreciated.

Thanks.

--------------------------------------------------------------------
|	Mike Parsons			7CG  HSRP  PROGRAM	   |
|	parsons@nic.hq.af.mil					   |
|	703-614-6121					           |
--------------------------------------------------------------------
Newsgroups: comp.sys.dec
From: gezelter@rlgsc.com
Newsgroups: comp.sys.dec
Subject: Re: USENET in MACRO?
Date: 12 Jan 93 11:55:10 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <C0qrK0.2J5@nmrdc1.nmrdc.nnmc.navy.mil>, dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes:
> Does anyone know of a USENET server and/or client which runs on 
> VAX 6410...  WRITTEN IN MACRO!?!??
> 
> We don't have C or FORTRAN, just MACRO.  ANY response would be
> greatly appreciated!!!
> -- 
> ===========================================================================
>   phil perucci      | "Any opinions expressed are solely my own views and 
>   ssb1pzp@digex.com |  do not reflect the position of any organization"
> ===========================================================================
-- 
Phil,
 
I am not exactly sure what you mean by a USENET server or client. 
If you mean a UUCP implementation, then the DECUS UUCP 
implementation is excellent (I'll put in a plug for the DECUS 
UUCP team, they have done an excellent job!) 
 
While the package does include sources, there should be no need 
to recompile anything. Everything that you should have to modify 
is accesible via ASCII parameter files.
 
The package is available on CDROM and tape (from DECUS) and from 
several archive sites on the Internet.
 
I hope that the above is useful. If I have been unclear, or if I 
can be of further assistance, please feel free to contact me via 
phone or Email.
 
- 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                                                 |
+--------------------------------------------------------------------------+
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.sys.dec
Subject: Re: Are the Alpha-Machines big- or little-endian ?
Summary: Architecture/systems little, chip bi
Keywords: endian, architecture, chip
Date: 9 Jan 93 21:10:06 GMT
Organization: Digital Equipment Corporation


In article <1993Jan8.170148.11988@wavehh.hanse.de>, cracauer@wavehh.hanse.de (Martin Cracauer) writes...
>Could anybody tell me, if the alpha machines are big-or-little-endian ?

The Alpha architecture, and the Alpha systems built by Digital, are
little endian.

The Alpha chip (DECchip 21064) can be used to build either a big endian
or little endian system.  For example, the Cray Research Alpha-based
MPP system is big endian.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
Newsgroups: comp.sys.dec
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: "User firms plagued by LAN money pits"
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Mon, 11 Jan 1993 10:08:16 GMT


--
In article <8JAN199309491490@jhuvms.hcf.jhu.edu>, ecf_stbo@jhuvms.hcf.jhu.edu
writes:

> I think what you
> have here is a case of 'escape from MIS' eventually turning into 'running
>back
> to MIS screaming HELLLLLLP!', in other words: 'we got PCs on our desk so
>we
> wouldn't have to pay MIS for services and to feel we were managing our
>own
> systems but we didn't plan it properly and don't know how to run our
>systems
> and a salesperson told us this would solve all our problems and we
>listened to
> the salesperson instead of our own people ....

Not to be too kind to salespersons, but in my experience it's often been the
MIS staff that didn't consider problems of scale, planning, etc.  This can
happen easily to a company (in a PC-obsessed society) where PCs have a strong
champion.  And then it turns out the champion has little or no experience with
more than 3 systems at a time ... or connecting them to the UNIX servers ...
or network printers ... or ....

Good friend of mine is a senior software manager at a US-wide company that
produces (and sells, very profitably) PC-based software for CASE.  Each of
their sites has a LAN, and all sites are connected over T1 lines.  And my
friend wanted to print from her desktop PC to a networked printer in the same
building.  Couldn't just do it.  System manager couldn't make it work.  After
repeated tries, the problem was solved by attaching a private printer to the
PC's local port.  Thing is, if this company has such difficulties, what are
the world's MIS departments in general able to do?

At Digital we have no such problems, of course. :-)

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.sys.dec
From: beyer@utrtsc.dec.com (Peter Beyer)
Subject: Re: X11R5 server and suport for PMAGB-B
Organization: Digital Equipment Corporation
Date: Thu, 7 Jan 1993 14:49:04 GMT


In article <1993Jan6.095344.10635@dcs.warwick.ac.uk>, rince@dcs.warwick.ac.uk (James Bonfield) writes...
>Hello,
> 
>	I've recently compiled up X11R5 for a Decstation 5000/240. The
>original Decwindows I used was only release 4 based. However I've noticed a
>substantial performance decrease.
> 
>	Hunting around has tracked this down to the fact that X11R5 does not
>support the DEC graphics cards. The Imakefile in mit/server/ddx/dec/ws has a
>comment saying 'Only color frame buffers are currently supported'. Is this
>likely to change? There are two (currently unused) files with support for the
>PMAG boards - but they only cover PMAG_[CFD]A. Any help here?

The PMAGB-Bx also known as the HX smart framebuffer, needs special ddx code to 
get the smart part running. This code is not in the X11R5 release. In your case
it's just running as a dumb framebuffer ala CX, hence slow...

>	The only solutions I can think of are to either ignore the slowness to
>get a release 5 compatible decwindows server.

You'll have to wait until DECwindows becomes R5...

Peter Beyer 
Windows, Graphics & Multimedia
Digital Equipment b.v.
beyer@utrtsc.enet.dec.com
beyer@athena.uto.dec.com