HDTenEightyP/NetNews huggingface dataset:
From: uzun@crash.cts.com (Roger Uzun)
Subject: Nsieve results
Organization: Crash TimeSharing, El Cajon, CA
Date: Fri, 17 Apr 1992 08:14:46 GMT


Here are the results I get for the nsieve benchmark on an
Amiga A3000/25, using SAS/C 5.10a lc -v -cf -l -m3 -f8d -Lmt -O nsieve

   Sieve of Eratosthenes (Scaled to 10 Iterations)
   Version 1.2, 03 April 1992

   Array Size   Number   Last Prime    Linear     RunTime    MIPS
    (Bytes)   of Primes               Time(sec)    (Sec)
       8191       1899        16381      0.320      0.320     5.2
      10000       2261        19997      0.391      0.393     5.2
      20000       4202        39989      0.782      0.795     5.2
      40000       7836        79999      1.564      1.609     5.2
      80000      14683       160001      3.128      3.256     5.2
     160000      27607       319993      6.257      6.587     5.2
     320000      52073       639997     12.514     13.325     5.2
     640000      98609      1279997     25.027     26.900     5.2
    1280000     187133      2559989     50.055     58.100     4.8
    2560000     356243      5119997    100.110    120.000     4.7

   Relative to 10 Iterations and the 8191 Array Size:
   Average RunTime =    0.341 (sec)
   High  MIPS      =      5.2
   Low   MIPS      =      4.7

--------------------------------------------------------------
bix: ruzun
NET: uzun@crash.cts.com
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Newsgroups: comp.benchmarks
Subject: Re: RS6000 profiling tools
Summary: Object Code Listing
Keywords: RS6000 profile
Date: 13 Apr 92 11:05:04 GMT
Organization: Bergen Scientific Centre, Bergen, NORWAY

In article <1992Apr6.205709.9000@athena.mit.edu> mmht@athena.mit.edu (Michael Man-Hak Tso) writes:
>Hi, does any one know of any profiling tools for C programs on the RS6000?  I'm
>looking for something which is a level lower than the UNIX "prof".  I wish to
>get a profile of actual machine instructions executed, such as the number of
>multiplies, jumps, load/stores, etc.
>
>Thanks,
>
>-- MIKE TSO
>tso@abp.lcs.mit.edu

There is also gprof and tprof. Gprof is bundled with the RS/6000s and creates
a tree of routine calls with dynamic execution times per function per routine.
Tprof is IBM Confidential and is an instruction level profiler which gives
"hot" instructions in your code.

Finally you can also generate an object code listing by doing the following
(reprinted from IBM's NIC Tuning Guide for FORTRAN and C):

XLF V1: xlf -O -qsource -qlist -qdebug=cycles fname.f
XLF V2: xlf -O -qsource -qlist fname.f

The source code listing will be in fname.lst

THe object file contains your source numbered per line and also multiple
assembly instructions to which each line of your code is translated.

Have fun.

-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	IBM Bergen Environmental Sciences and Solutions Centre
izahi@bsc.no	        Izahi Engineering is here !!!	
Newsgroups: comp.benchmarks
From: moulton@cs.utk.edu (Steve Moulton)
Newsgroups: comp.benchmarks
Subject: Re: Linpack library routines
Keywords: Linpack, netlib, xnetlib, lapack
Date: 15 Apr 92 22:51:04 GMT
Organization: University of Tennessee, Knoxville - CS Department
NNTP-Posting-Host: blitzen.cs.utk.edu
cc: sljn6@cc.usu.edu

In article <1992Apr15.153423.54513@cc.usu.edu> sljn6@cc.usu.edu writes:
>I was looking for two standard routines of LINPACK QR
>1. dqrdc()
>2. dqrsl()
>Can anybody tell me how I can get hold of the library containing
>these routines
>
>Thanks
>
>I am 
>Rajiv Goyal
>E-mail   SLJN6@cc.usu.edu
>ph*   801-753-2761
>

Sure enough.

Easiest way (least time investment) would be to mail the following
message to netlib@ornl.gov

send dqrdc from linpack
send dqrsl from linpack

This will send all necessary support subroutines, too.
If you want to know what all is available from LINPACK, send to 
the above address

send index from linpack

If you want to know more about netlib, 

send index

If you want to know about LAPACK (the successor to LINPACK),

send index from LAPACK

Be aware that the underlying BLAS routines are NOT bound into LAPACK
(it is assumed that many sites have optimized BLAS on hand).  If you
need these for LAPACK (what BLAS are necessary are bound into the
LINPACK distribution process), 

send index from cor

Finally, for a good time, try xnetlib.  This gives an X interface to
netlib for anyone who has access fo tcp/ip internet.  For more
information, 

send index from xnetlib

Due to the recent release of LAPACK, the netlib server has been fairly
heavily loaded.  Thus, it may take a couple of hours for messages to
netlib@ornl.gov to get back to you.  Xnetlib, which maintains the
index files locally (i.e., on your machine) for quick access, may take
quite some time to download those files, due to the load on the
server.  Please be patient with it.  Also, you can get the entire
LAPACK distribution from Xnetlib (but you probably want to do it late
at night).   Otherwise, the only way to get the entire LINPACK or
LAPACK libraries is via tape from a distribution service documented in
the appropriate index files.

More than you ever wanted to know ...


-- 
Steve Moulton (moulton@cs.utk.edu) | I've always been more comfortable sinking 
University of Tennessee, Knoxville | while clutching a good theory than swim-
Department of Computer Science     | ming with an ugly fact.  - David Mamet
From: boucher@ncs.dnd.ca (R. Boucher)
Newsgroups: comp.benchmarks
Subject: nsieve results
Summary: 40MHz AMD386 64K cache
Keywords: bench nsieve 386
Date: 17 Apr 92 13:51:25 GMT
Organization: DND, Ottawa, CANADA

The following are the results for a 40Mhz AMD386 motherboard with 64K
cache, no 80387 or weitek.

Compiled with gcc (v2.1) with the following options: -O -O2.
I ran nsieve in RealTime on Unix SVR4, to ensure that it had the cpu's
full attention:

   Sieve of Eratosthenes (Scaled to 10 Iterations)
   Version 1.2, 03 April 1992

   Array Size   Number   Last Prime    Linear     RunTime    MIPS
    (Bytes)   of Primes               Time(sec)    (Sec)
       8191       1899        16381      0.248      0.248     6.7
      10000       2261        19997      0.302      0.306     6.6
      20000       4202        39989      0.605      0.627     6.6
      40000       7836        79999      1.209      1.306     6.4
->    80000      14683       160001      2.419      2.769     6.1
     160000      27607       319993      4.838      5.731     5.9
     320000      52073       639997      9.675     11.875     5.8
     640000      98609      1279997     19.351     24.500     5.7
    1280000     187133      2559989     38.701     49.850     5.6
    2560000     356243      5119997     77.402    102.800     5.5

   Relative to 10 Iterations and the 8191 Array Size:
   Average RunTime =    0.286 (sec)
   High  MIPS      =      6.7
   Low   MIPS      =      5.5


Robert Boucher

(HOME/WORK) boucher@ncs.dnd.ca
(WORK) ...!uunet!revcan!DCSEM!252
(HOME) ...!uunet!revcan!flatout!asimov!rob
Newsgroups: comp.benchmarks
From: Patrick F. McGehearty <patrick@convex.COM>
Subject: Re: Tooling up for the Great 1992 UNIX Dream Machines Bake-Off
Originator: patrick@mozart.convex.com
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Thu, 9 Apr 1992 20:39:01 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1g3s7q#4kr6Zw244bBz8Hbhw1364cP5=eric@snark.thyrsus.com> eric@snark.thyrsus.com (Eric S. Raymond) writes:
... lots of stuff about a new proposed benchmark set
...
>
>Just for giggles, I may add BCmark and that DPS thing (I'm amazed nobody has
>advanced the obviously correct name for it --- Datestones!).
>

Please, no, a thousand times no.  The bc/date class of benchmarks is harmful
to serious optimization efforts.  It encourages engineering resources to be
spent on the wrong things.  Dhrystones for all it's faults of being
synthetic and subject to special purpose optimization hacks is still a
positive benefit to the user community in that it encourages better compiler
optimizations with respect to register allocation, etc.  I consider the
"quick, easy and very misleading" 'rarely used Unix utility' benchmark tests
to have only potential for harm, not good.
[When I say rarely used, I mean as a percentage of the total execution
 time of a typical user's system.  I would bet that bc and date are less
 than 0.1% of the total execution time for most workstations.]

>Here's an iozone auto report for my system (AT&T 6386WGS with ESDI controller
>and a Micropolis 300MB drive).  
>
>	MB      reclen  bytes/sec written   bytes/sec read      
>	1       512     75983               42298               
... intermediate data deleted...
>	8       8192    84562               70528               
>Error writing block 29420
...

On systems that are concerned with very high I/O throughput, 512 bytes
to 8192 bytes is considered very small record lengths, and a 1 Megabyte file
to be relatively small.  I will even go so far as to predict that a 1Gbyte
disk will be considered standard for a mid-range workstation within three
years, and fileservers to have 10's to 100's of Gbytes in standard
configurations.  Of course, high end systems are already much larger.

I like to use 65536 byte records or larger for measuring disk throughput,
and 4096 byte records for measuring disk transactions per second.
Newsgroups: comp.benchmarks
From: bourne-linda@CS.YALE.EDU (Linda Bourne)
Subject: Alan J. Perlis Symposium
Organization: Yale CS Mail/News Gateway
Date: Wed, 8 Apr 1992 20:06:29 GMT

ALAN J. PERLIS SYMPOSIUM:  Parallel Computers of the Future

Sponsored by the Department of Computer Science, Yale University

April 23, 1992

Sheffield-Sterling-Strathcona Hall
Room 114
Corner Grove and Prospect Streets
New Haven, Connecticut


Morning Session (9:30-11:00)

	Opening Remarks
		Drew McDermott
		Chairman, Yale CS

	"Dataflow Architectures:  From Monsoon to *T"
		Arvind
		Massachusetts Institute of Technology


Afternoon Session (1:30-4:30)

	"PRAMs:  Theory, Physical Design, and Application"
		Wolfgang Paul
		University of Saarbrucken

	"Will Parallel Architectures Converge?"
		H.T. Kung
		Carnegie-Mellon University



Following the last talk a public reception will be held at the
Department of Computer Science, Arthur K. Watson Hall.

All talks are free and open to the public.

For further information please call (203) 432-1246.
-------
From: sow@cad.luth.se (Sven-Ove Westberg)
Newsgroups: comp.benchmarks
Subject: Re: SPEC Results for Workstations
Date: 9 Apr 92 21:10:32 GMT
Organization: University of Lulea, Sweden

In article <1992Apr2.234929.19182@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) writes:
|
|
|SPECfp Ratings for Various Workstations
|----------------------------------------
|SGI Indigo	 28.4
|Sun SS2		 27.4
|

This is two very interesting figures that proves that the SPECS is as
good as whetstone linpack or some other toy benchmark. Why you ask?

I had borrowed an SGI Indigo from SGI Sweden and ported DYNA3D (a FEA 
program) the the INDIGO. I was very surpriced that the Indigo runs
twice as fast as the SS2 on real problems. Both machines had 32Mb
memory.

Unfortunately I dont have acces to an Indigo any more so I can not run
any other test to verify if it is the same relations with other programs.

Have anyone else noticed this?

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
From: mdlawler@bsu-cs.bsu.edu (Michael D. Lawler)
Newsgroups: comp.benchmarks
Subject: rubik benchmark
Keywords: where can I get it
Date: 10 Apr 92 17:03:34 GMT
Organization: CS Dept, Ball St U, Muncie, Indiana


Could someone please tell me where I can get this or send it to
me?  Thanks!
mdlawler@bsu-cs.bsu.edu
00mdlawler@bsuvax1.bitnet
00mdlawler@bsu-ucs.bsu.edu
00mdlawler@bsuvc.bsu.edu
Newsgroups: comp.benchmarks
From: clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman)
Subject: Re: SPEC Results for Workstations
Organization: University of Virginia Computer Science Department
Date: Tue, 14 Apr 1992 22:24:47 GMT

In article <1944@eru.mt.luth.se> sow@cad.luth.se (Sven-Ove Westberg) writes:
>In article <1992Apr2.234929.19182@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) writes:
>|
>|
>|SPECfp Ratings for Various Workstations
>|----------------------------------------
>|SGI Indigo	 28.4
>|Sun SS2		 27.4
>|
>
>This is two very interesting figures that proves that the SPECS is as
>good as whetstone linpack or some other toy benchmark. Why you ask?
>
>I had borrowed an SGI Indigo from SGI Sweden and ported DYNA3D (a FEA 
>program) the the INDIGO. I was very surpriced that the Indigo runs
>twice as fast as the SS2 on real problems. Both machines had 32Mb
>memory.

At least 8 of the SPECmark numbers come from "real problems". Certainly
I would consider "gcc" to be a real world code, for example.  Does the
Indigo run twice as fast on gcc as the Sun SS2?

The HP 9000/710 is 29 times as fast as the VAX 11/780, according to gcc
results in SPEC.  Or is it 64.1 times as fast (tomcatv results) or 33.2
times as fast (spice2g6)?  The answer: It is all of the above.

The matrix300 and nasa7 codes have been criticized for being kernel and
not entire applications, violating the spirit of the SPEC suite, which
was declared to be benchmarking systems with entire real world applications.
Matrix300 was dropped for this and other reasons. I don't remember the
status of nasa7 in the SPEC92 suite.

I am sure that I can find "real problems" on which the Indigo and the SS2
are very comparable in performance, as their SPEC results would indicate.
And I can find others that show a big difference. I don't see how that
makes SPECfp (a geometric mean of 6 benchmarks) as worthless as toy
benchmarks.

Does anyone have current numbers for all 10 SPEC codes for both machines?



-- 
-----------------------------------------------------------------------------
"It is seldom that any liberty is lost all at once." David Hume
|||  clc5q@virginia.edu (Clark L. Coleman)
From: corpron@.hri.com (Dan Corpron)
Newsgroups: comp.benchmarks
Subject: Benchmarking spreadsheets (Lotus 1-2-3).
Date: 13 Apr 92 14:51:03 GMT
Article-I.D.: bigbird.6269
Reply-To: corpron@hri.com
Organization: Horizon Research, Inc.

I have the honor of testing the compatibility and performance
of Lotus 1-2-3 on different platforms (i.e. DOS and UNIX).  Are 
there any benchmarking and/or compatibility validation spreadsheet
applications out there?
 
Thanks one and all!

Dan R. Corpron			    UUCP: ...bbn!hri.com!corpron
Horizon Research, Inc.		    INET: corpron@hri.com
1432 Main Street
Waltham, MA 02154
Newsgroups: comp.benchmarks
From: CONNOLLY@UKCC.UKY.EDU (John Connolly)
Subject: Re: Computational Power Increases
Organization: UNIVERSITY OF KENTUCKY
Date: Thu, 16 Apr 1992 13:43:44 GMT
X-Bytes: 

There is a National Research Council Report called "The Impact of
Supercomputing Capabilities on US Materials Science and Technology"
published in 1988 which has a chart of the long term trend in
top-of-the-line computing power. The chart shows about a six order
of magnitude increase in the last 40 years. This is equivalent to
a factor of 2 every 2 years, or about 1.4 (square root of 2)
every year.
Xref: sparky comp.benchmarks:705 comp.sys.hp:5169
From: bt@irfu.se (Bo Thide')
Newsgroups: comp.benchmarks,comp.sys.hp
Subject: Re: REPOST: Linpack MFLOPS, etc., For Workstations
Date: 12 Apr 92 18:37:05 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <1992Apr8.201314.17836@murdoch.acc.Virginia.EDU> clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman) writes:
>I want to clarify that the Linpack MFLOPS numbers in the table below
>were provided by the various vendors for the 100 by 100 matrix problem
>size.  There are also 300 by 300 and 1000 by 1000 standard sizes for
>reporting this benchmark, as well as unlimited sizes that are reported
>for massively parallel machines, but I only have the 100 by 100 data.
>
>--------------------------------------------------------------------
>The numbers below were taken from the January, 1992, "HP Apollo 9000
>Series 700 Performance Brief".
>--------------------------------------------------------------------
>
>Dhrystone Version	HP710	HP720	HP730	HP750
>-----------------	-----	-----	-----	-----
>1.1			101650	101770	134770	134700
>2.0			 87530	 87910	116280	115860
>
>
>Linpack Double Precision MegaFLOPS, inner loop rolled, 100x100 matrix
>---------------------------------------------------------------------
>IBM550		25.2
>HP750		23.7
>HP730		23.7
>IBM530H		20.0
>HP720		17.9
>HP710		12.2
>IBM320H		11.7
>SGI 4D/35	 5.4
>Sun SS2		 4.2
>Sun IPX		 4.2
>SGI Indigo	 4.1
>Sun ELC		 3.0

I ran the Dhrystone 1.1, Dhrystone 2.1 (I don't have 2.0), and the
Linpack double 100x100 on our 720 and 730 after upgrading to HP-UX 8.07
to see if the new compilers give speed improvement over the 8.05
compilers.  They do and here are the results:

Dhrystone(*) Version	HP720	HP730
-------------------	-----	-----
1.1			102040	134408
2.1			 90744	119617

Linpack Double Precision(**) MegaFLOPS, inner loop rolled, 100x100 matrix
-----------------------------------------------------------------------
HP730		24.524
HP720		18.040

====================================================
(*)  cc +OS +O3 -Wl,-a,archive
(**) f77 +OP4 +OS +O3 -Wl,-a,archive


Two conclusions: 

1.  HP are is a bit conservative on their own speed ratings.  The Snakes
    are in fact mostly somewhat faster than the claims in the latest "HP
    Performance Brief".

2.  In very time-critical applications it may pay off a little bit to
    recompile with the 8.07 compilers on your HP9000/700's.

Bo
-- 
   ^   Bo Thide'--------------------------------------------------------------
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|      Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
From: paul@phoenix.Princeton.EDU (Paul Lansky)
Newsgroups: comp.benchmarks
Subject: Benchmarking disk performance under Unix
Date: 11 Apr 92 16:37:57 GMT
Organization: Princeton University
Originator: news@ernie.Princeton.EDU


I would like some people's wisdom on benchmarking
disk performance on unix systems  (Sun, NeXT etc).
Particularly with respect to cache performance,
looking at the difference between behaviour in 
sequential reads and read/writes involving seeks
etc.  Any software, or recommendations would be
welcome.  I'd be glad to post a summary.

I'm particularly interested in measuring performance
on large disks (fuji, wren, maxtor 1.2 gig etc)

Thanks
Paul Lansky
music
princeton univ
paul@princeton.edu
From: de5@stc06.CTD.ORNL.GOV (Dave Sill)
Newsgroups: comp.benchmarks
Subject: Re: GPC Picture Level Graphics Benchmark Results for Workstations
Date: 14 Apr 92 11:48:19 GMT
Reply-To: Dave Sill <de5@ornl.gov>
Organization: Oak Ridge National Laboratory

In article <10385@inews.intel.com>, jwreilly@mipos2.intel.com (Jeffrey Reilly) writes:
>
>The GPC has since published Volume 1, Number 3 (cover dated 4th quarter
>1991) which contains results from the final official specification for the 
>PLB.

Could somebody post some of these numbers for those of us whose
benchmark result budget precludes buying them directly?  Numbers
aren't copyrightable, so as long as you don't just scan them in
there should be no problem.

--
Dave Sill (de5@ornl.gov)	         "Nobody likes nuclear bombs.
Martin Marietta Energy Systems            We're trying to get rid of them."
Workstation Support                                  -DOE Sec'y James Watkins
Newsgroups: comp.benchmarks
From: mmht@athena.mit.edu (Michael Man-Hak Tso)
Subject: RS6000 profiling tools
Keywords: RS6000 profile 
Organization: Massachusetts Institute of Technology
Date: Mon, 6 Apr 1992 20:57:09 GMT

Hi, does any one know of any profiling tools for C programs on the RS6000?  I'm
looking for something which is a level lower than the UNIX "prof".  I wish to
get a profile of actual machine instructions executed, such as the number of
multiplies, jumps, load/stores, etc.

Thanks,

-- MIKE TSO
tso@abp.lcs.mit.edu
Newsgroups: comp.benchmarks
From: devido-antonio@CS.YALE.EDU (Antonio DeVido)
Subject: Shadow/spix
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Fri, 17 Apr 1992 17:26:05 GMT

 There were reports on these tools published in 7/89 by Sun Technical Memoranda
and I am interested in learning if they are available to the interested com-
munity. If some knowledgable person would update me on this I'd be grateful.
-> Antonio
-- 
Antonio J. De Vido // devido@cs.yale.edu   // league@prep.ai.mit.edu
lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
From: ding@crim.ca (Weiren Ding)
Newsgroups: comp.benchmarks
Subject: Benchmarks for Transputer
Keywords: Benchmark, Transputer
Date: 3 Apr 92 22:35:26 GMT
Organization: C.R.I.M.


Does anybody know if there is any standard benchmarks for transputer 
machine?
Thnaks in advance.

-- 


Best regards,
From: ERDAL@TRMETU.BITNET (Erdal Taner)
Newsgroups: comp.benchmarks
Subject: SPEC SDM results
Date: 12 Apr 92 17:02:20 GMT
Article-I.D.: TRMETU.92103.123848ERDAL
Organization: Middle East Technical University - Computer Center

Hello,
Last week, I asked for SPEC Fax Number, and I got a response informing that
the fax is 703 560 2752. I requested SPEC SDM results, but I havent got
any reply.
  It would be appreciated If someone show me the way to get these results.
Please directly e-mail to me.
-Erdal
Newsgroups: comp.benchmarks
From: rec@aim.com (Bob Cousins)
Subject: Re: Benchmarking disk performance under Unix
Organization: /usr/lib/news/organization
Date: Mon, 13 Apr 1992 20:20:49 GMT

In article <1992Apr11.163757.19305@Princeton.EDU> paul@phoenix.Princeton.EDU (Paul Lansky) writes:
>I would like some people's wisdom on benchmarking
>disk performance on unix systems  (Sun, NeXT etc).
>Particularly with respect to cache performance,
>looking at the difference between behaviour in 
>sequential reads and read/writes involving seeks
>etc.

Our tests have shown some rather interesting results. Specifically,
that there is a big difference between disk I/O on machines when
the buffer cache is used, but that there is typically relatively
little difference between machines when the buffer cache isn't
enabled. For example, most disks are capable of 400K/second +/- 20%
when running a UNIX filesystem. Under any serious multitasking load,
we have found relatively little difference between filesystems (or
at least not enough to cause us to change the above approximation).

A generally applicable (yet dangerous) rule of thumb is that the
cached disk throughput is more a function of CPU and RAM speeds
(along with cache size) than disk today (since disks tend to 
perform similarly to a first approximation). This only applies
since vendors tend to test their machines with the newest/fastest
disks which limits the choices severely at any one point in time.

>I'm particularly interested in measuring performance
>on large disks (fuji, wren, maxtor 1.2 gig etc)

The major improvements are for distributed swap/paging on multiple
spindles and distributed (overlapped) filesystem operations. The newer
disks are also much faster in average access time. This shows up
as higher average throughput since less time is spent seeking. Higher
rotational speeds translate in smaller rotational latencies which has
as large of an effect as the increased transfer speed.

>Thanks
>Paul Lansky
>music
>princeton univ
>paul@princeton.edu


-- 
________________________________________________________________________________
Robert Cousins                    rec@aim.com                  (408)748-8649x212
Consultant to Aim Technology                          Speaking for myself alone.