HDTenEightyP/NetNews huggingface dataset:
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Can't you run unix on a 386?
Organization: Texas Instruments Inc
Date: Thu, 15 Oct 1992 15:10:30 GMT

In <1992Oct14.181002.17295@pencom.com> twriter1@pencom.com writes:

>That's the question.  I bought the book "Build your
>own 386 and save a bundle."  He doesn't list
>unix as one of the possible operating systems.

>I repeat:
>	"Can't you run unix on a 386?"

You can, given enough memory.  If not, there are a whole bunch of
machines out there that have been fooled into running something that
won't run on them.  :-)

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.misc
From: mcdonald@netcom.com (Jim Mc Donald)
Subject: File transfers from Mexico to USA
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 8 Oct 1992 07:59:21 GMT

I have a friend who will be moving back down to Mexico in a few weeks. He
is looking for a way to transfer about 20 megs of documentation a month to
friends in Washington DC. He knows the Net, and needs to know a few things:

1) Is there a public access node to the Internet in the Washington DC area?
   if no, whom do I speak to at Georgetown or American University inquiring
   about access privileges and cost to their system?

2) Is there a public access node to the Internet in Mexico City, or nearby?
   If not, do any of the universities in Mexico City have Internet access?
   The following is a list of universities he knows are nearby: (bear with
   me on the spelling) Autonomous U. de Mexico, Queretaro U. de Mexico). If
   so, whom do I contact?

3) Does the US Government have a node in Mexico City that can be accessed by
   US citizens for mail and transfer purposes?

4) How exactly does he go about setting up the accounts, so that he can 
   transfer a file to his Mexico account, and have his friend ftp it from
   Washington DC?

Please address all answers to mcdonald@netcom.com.

Note: All information that my friends wishes to transfer is not classified
or secretive in any way. He just needs to send the documentation in a lot
less time than the 3 days it has taken in the past.

No replys to comp.misc. All replys to mcdonald@netcom.com.

Much appreciated.

Jim Mc Donald
mcdonald@netcom.com


Newsgroups: comp.misc
From: oliver@earthview.cms.udel.edu (Oliver Weatherbee)
Subject: Portacom Graphics Accelerator 
Reply-To: oliver@earthview.cms.udel.edu
Organization: Marine Studies, University of Delaware
Date: Mon, 12 Oct 1992 16:22:02 GMT

In PC Computing's August(?) issue, they did a run down of their top 200
computer products. Included in the graphics accelerator section was a 
board made by Portacom called the Eclipse II (I think).

Does anyone know anything about this board, I can find no reference to it
in PC Magazine or in the last two issues of Computer Shopper.

Thanks,
	O

Newsgroups: comp.misc
From: cslee@pds.nchu.edu.tw (Lee Chee Siong)
Subject: How to send mail with 8 bits character?
Keywords: 8 bits mail
Organization: NCHU Computer Center
Date: Mon, 12 Oct 1992 11:26:47 GMT

Hi,
     Could anyone tell me how to do with sendmail that it can
send "8 bits mail" to others and receive "8 bits mail" from other
system?
     I know I can uuencode the message before send and uudecode after
receive but what I need is the directly method by changing configuration
in sendmail.
     I try to send a "8 bits mail" to another ultrix machine with
my ultrix machine.
     Thanks for your kindly help.



<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>   CS Lee	(Lee Chee Siong)		<>  If you can give	<>
<>   National Chung Hsing University,		<>	  nothing else, <>
<>   Taichung, Taiwan, Republic of China.	<>  at least give a	<>
<>   Internet Address: cslee@pds.nchu.edu.tw	<>	  cheerful face <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
From: twriter1@pencom.com
Newsgroups: comp.misc
Subject: Building a computer
Date: 12 Oct 92 20:25:18 GMT
Reply-To: twriter1@pencom.com
Organization: Pencom Software

Does anyone have information on how to build,
say, an IBM-compatible PC?  Is this possible?
I see so many ads in magazines for components, I just
wondered if one could construct a whole computer
out of them.  

Has anyone out there undertaken such a project?

twriter1@pencom.com
Newsgroups: comp.benchmarks
From: de5@ORNL.GOV (Dave Sill)
Subject: SPEC (was Re: wanted: benchmark results for DEC alpha)
Organization: Oak Ridge National Lab, Oak Ridge, TN
Date: Mon, 12 Oct 1992 19:43:33 GMT

In article <1992Oct12.175359.18023@odin.corp.sgi.com>, mash@mash.wpd.sgi.com (John R. Mashey) writes:
>
>7) From past experience & simulation, we know that changing R4000 scache
>from 256KB to 1MB makes little (5%?) difference on SPEC; however, we think
>it makes a noticable difference for a lot of real applications, which spend
>more time inside the OS, doing context-switching, I/O, etc.

This challenges SPEC's claim that the SPEC Suites consist of real applications,
or at least implies that the "real applications" in the SPEC Suites aren't real
enough.  Certainly, no matter how many and varied the SPEC applications are,
there will be plenty of applications with widely different performance
characteristics.  I thought the intent of the SPEC suites was to choose real,
large benchmarks that would, on average, represent the average application
pretty closely.  You seem to be saying they haven't succeeded.

>Note that UNIX kernel
>has a much bigger footprint in the cache than do most of the SPEC 
>CPU benchmarks.

Do the SPEC applications not spend as much time in the kernel as the average
"real" application?

>We *think* that many real applications that are FP-intensive
                 ~~~~
>use integer code more than do SPECfps...  (This is not to say *all*,
>and I wouldn't know how to quantify *most*; however, we've seen enough
                                      ~~~~
>cases where SGI Crimsons are about equal (on average, with wild variations)
>against IBM 560s or HP 730s) on FP-intense applications, despite what
>SPECfp92 alone would tell you... hence, the various conjectures above.

"Many" I can believe, but to say that "most" real fp apps differ from the SPEC
apps is a little harder to swallow.  Not impossible, but I'd have to see some
data before I'd believe it.  Especially coming from a hardware vendor trying to
tell me I'll get better performance from his product than SPEC would predict.

>BOTTOM LINE: whenever anyone publishes SPEC numbers, do a careful comparison
>across the board, not just on the mean numbers, to get some diea of what's
>going on.  In particular, always watch out for "peaks", like what happened
>to SPEC89's matrix300 (although perhaps not so extreme).
>However, *expect* that performance ratios on individual benchmarks
>will vary widely among these machines, and that if you pick your benchmarks,
>you'll probably be able to prove superiority of anything you like,
>among machines whose means are similar. 

Good advice.

-- 
Dave Sill (de5@ornl.gov)           For every Bill Joy there is a Kirk McKusick.
Martin Marietta Energy Systems     For every Bill Gates there is a Richard
Workstation Support                Stallman.                     --Paul Graham
Newsgroups: comp.benchmarks
From: karbasia@quartzite.cps.msu.edu (Hamid Karbasiafshar)
Subject: info. about livermore.c
Organization: Michigan State University
Date: Fri, 9 Oct 92 13:42:11 GMT


I appreciate if someone can give me some information or hints
about running livermore.c loops on almost any computer. The
version of the C program that I have, does not have amain program
also I wonder what kind of time system call would be best to 
measure the time for execution inside CPU. and if it is the time
or the MFLOP that is the important issue.

Thanks in advance.
From: albani@cadlab.sublink.org (Lanfranco Albani)
Newsgroups: comp.benchmarks
Subject: Re: wanted: benchmark results for DEC alpha
Keywords: Dec alpha
Date: 14 Oct 92 08:05:23 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

mash@mash.wpd.sgi.com (John R. Mashey) writes:

:7) From past experience & simulation, we know that changing R4000 scache
:from 256KB to 1MB makes little (5%?) difference on SPEC; however, we think
:it makes a noticable difference for a lot of real applications, which spend
:more time inside the OS, doing context-switching, I/O, etc.  Note that UNIX kernel has a much bigger footprint in the cache than do most of the SPEC
:CPU benchmarks.  We *think* that many real applications that are FP-intensive
:use integer code more than do SPECfps...  (This is not to say *all*,
:and I wouldn't know how to quantify *most*; however, we've seen enough
:cases where SGI Crimsons are about equal (on average, with wild variations)
:against IBM 560s or HP 730s) on FP-intense applications, despite what
:SPECfp92 alone would tell you... hence, the various conjectures above.

Ok, run the SPEC all together and see the difference! :-)

Seriously, with the same environment of the single benchmark, why not run
two or three or all at the same moment, child of the same shell, etc. etc.?

So, with some comparision, people can have an idea of the real life
multitasking capability of various processor, architecture and OS.

Bye, Lanfranco

-- 
Lanfranco Albani - CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia
Email: (work:) albani@cadlab.sublink.org, (home:) bob@allan.sublink.org
Phone: (work:) ++39 (51) 6130360, (home:) ++39 (51) 727372; 
Fax: ++39 (51) 6130294 (work only), Fidonet: 2:332/407.1138 (home only).
Newsgroups: comp.benchmarks
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/17/91] Ways to fool the masses with benchmarks	(15/28) c.be. FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 15 Oct 92 11:25:09 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

15	12 Ways to Fool the Masses with Benchmarks	<This panel>
16	SPEC
17	Benchmark invalidation methods
18
19	WPI Benchmark
20	Equivalence
21	TPC
22
23
24
25	Ridiculously short benchmarks
26	Other miscellaneous benchmarks
27
28	References
1	Introduction to the FAQ chain and netiquette
2
3	PERFECT Club
4
5	Performance Metrics
6
7	Music to benchmark by
8	Benchmark types
9	Linpack
10
11	NIST source and .orgs
12	Measurement Environments
13	SLALOM
14

From David Bailey et al.

Quote only 32-bit performance results, not 64-bit results.

Present performance figures for an inner kernel as the performance of the
entire application.

Quietly employ assembly code and other low-level language constructs.

Scale up the problem size with the number of processors, but omit any
mention of this fact.

Quote performance results projected to a full system.

Compare your results against scalar, unoptimized code on Crays.

When direct run time comparisons are required, compare with an old code
on an obsolete system.

If megaFLOPS rates must be quoted, base the operation count on the parallel
implementation, not on the best sequential implementation.

Quote performance in terms of processor utilization, parallel speedup or
megaFLOPS per dollar.

Multilate the algorithm used in the parallel implementation to match
the architecture.

Measure parallel run times on a dedicated system, but measure conventional
run times in a busy environment.

If all else fails, show pretty pictures and animated videos, and don't talk
about performance.

Ref. 1
NAS TR #

Ref. 2
%A David Bailey
%T Twelve Ways to Fool the Masses when Giving Performance Results on
Parallel Computers
%J Supercomputing Review
%V 4
%N 8
%D August 1991
%P 54-55

References
Darrell Huff, How to Lie with Statistics
	How to Lie with Maps

Gordon Bell's 11 rules of supercomputer design:

1) Performance, performance, performance.
2) Everything matters.
3) Scalar matter most.
4) Provide vectors as price allows.
5) Avoid holes in performance.
6) Place peaks in performance.

7) Provide a decade of addressing.
8) Make it easy to use.
9) Build on others work.
10) Design for the next one (and do it again) [three times]
11) Have slack resources.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Newsgroups: comp.benchmarks
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/17/92] music to benchmark by	(7/28)	c.be FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Wed, 7 Oct 92 11:25:10 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

7	Music to benchmark by					<This panel>
8	Benchmark types
9	Linpack
10
11	NIST source and .orgs
12	Measurement Environments
13	SLALOM
14
15	12 Ways to Fool the Masses with Benchmarks
16	SPEC
17	Benchmark invalidation methods
18
19	WPI Benchmark
20	Equivalence
21	TPC
22
23
24
25	Ridiculously short benchmarks
26	Other miscellaneous benchmarks
27
28	References
1	Introduction to the FAQ chain and netiquette
2
3	PERFECT
4
5	Performance Metrics
6

Benchmarking takes time.  Might as well listen to something useful.
Hey, engineers and scientists need some general education requirements and
to see the generally inteconnectedness of computing to the rest of the
world.

The Photographer by Philip Glass.
[Also "How to Get away with Second Degree Murder."]

Einstein at the Beach by Philip Glass.

"Democratic Process"
"Cowboy Lips"
"Art For Art's Sake" 
all off the "The Bobs" album on Kaleidoscope Records "K-18"
(P.O. box O, El Cerrito, CA, 94530)
[Excellent!  You are RIGHT!  SIGGRAPH 1984 as a good example]
jason@cs.utexas.edu

Dmitri Shostakovich
Aram Khachaturian
Sergei Prokofiev

as well as major cello concerti throughout the ages.  Paul Chihara's work
before he started writing for movies (if you can find it) is also good.
 
Or, if you're benchmarking a 16-processor Cray Y-MP C90, Chopin's Minute Waltz.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Newsgroups: comp.benchmarks
From: lyndon@unbc.edu (Lyndon Nerenberg)
Newsgroups: comp.benchmarks
Subject: Wanted: NCR Benchmark Source
Date: 9 Oct 92 22:33:40 GMT
Organization: University of Northern B.C.

Can someone point me at a copy of the NCR Benchmark Suite source code?
I can't find it via archie. Thanks.

--lyndon
Newsgroups: comp.benchmarks
From: justin@scs.leeds.ac.uk (J M Ware)
Subject: Re: wanted: benchmark results for DEC alpha
Originator: justin@csparc5
Keywords: Dec alpha
Organization: The University of Leeds, School of Computer Studies
Date: Fri, 9 Oct 92 10:00:36 GMT

In article <1992Oct9.013429.29995@e2big.mko.dec.com> pettengill@cvg.enet.dec.com () writes:
>I have no idea how one would benchmark a chip against a system.  Would you care to
>explain your methodology? ....
I was first attempting to ascertain if there was a new system for 21064 or if
DEC 5000 owners could enhance their systems with it.  Basically could someone
get hold of a 21064 chip either in a new machine or put it in their old
machine.  Compile and optimize their code on it, and get it to run 14 times
faster.  Which someone claimed to me (through one other person) they had done.

>....  You can buy the 21064 chip today and do the benchmarks
>yourself.  ;-)
What colours is it available in and does it have leather upholstery? :-)

>what is missing is the information on the hardware platform, compiler versions, the
>source code, and so on that are required to interpret the results.  However it is very
>unlikely that the figure cited is due to the compiler failing to generate correct code.
The lack of details about how it had been done or what system it had been done
on made me very suspicious about the validity of the claim.  I should like to
point out that this claim shouldn't be taken by any readers of this group as
gospel truth.  The chip (system/whatever...) may be faster or slower than
this!  All I attempted to do was to try to ascertain the validity of the claim.
Certainly, no one should quote this figure as a performance estimate.

>I assume that the reason for this posting is that you are skeptical of the figure cited.
I'm not sceptical that the (chip/system - delete as applicable) can do it, I'm
sceptical the person who claimed it did the test.

>As far as I know, the chip is available in only one size and that is on a pretty
>small scale.  ;-)
So no big synchronously flashing lights then? :-)  Computers just aren't fun
anymore.

Justin						justin@scs.leeds.ac.uk
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Newsgroups: comp.benchmarks
Subject: Re: wanted: benchmark results for DEC alpha
Keywords: Dec alpha
Date: 13 Oct 92 04:26:52 GMT
Organization: Boeing Computer Services, Seattle

justin@scs.leeds.ac.uk (J M Ware) writes:


>I'm looking for any pointers on where to find benchmark results for the new DEC
>wonder-chip 'alpha'.  Preferably ones done by someone other than DEC.  I have
>been quoted by someone that the new DEC alpha performed his Finite Element Code
>14 times faster than his DEC5000/200 -- is this likely?

>Incidentally if anyone has news of what stage DEC are in making the alpha chip
>available on a large scale, can they let me know.

>Thanks in advance,

>Justin M. Ware

>justin@scs.leeds.ac.uk                   - research assistant, dogsbody, grunt.

I assume that when you get your answer, you will post it for the rest of us,
won't you?

Jeff Silverman, Boeing Commercial Airplane
silverman@ilvxd0.fteil.ca.boeing.com

Newsgroups: comp.benchmarks
From: shah@tay1.dec.com (Amitabh Shah)
Subject: Re: wanted: benchmark results for DEC alpha
Organization: Digital Equipment Corporation, TAY1, Littleton MA
Date: 8 Oct 92 10:08:02


On Thu, 8 Oct 92 09:10:26 GMT, justin@scs.leeds.ac.uk (J M Ware) said:

> I'm looking for any pointers on where to find benchmark results for the new DEC
> wonder-chip 'alpha'.  Preferably ones done by someone other than DEC.  I have
> been quoted by someone that the new DEC alpha performed his Finite Element Code
> 14 times faster than his DEC5000/200 -- is this likely?

I doubt if you will find any such pointers at this stage. The Alpha-based
machines are being shipped to our software partners and some customers with a
no-benchmarking policy. Heck, I, being part of DEC's Software Performance
Group, have limitations on what kind of benchmarking I can do. The reason for
this is that these initial Alpha machines come with non-optimized operating
systems and compilers, since a lot of debugging is going on at this time. 

While it is certainly likely that Alpha will perform 14 times faster than a
DEC5000/200 on that application, no one could have tested this in the first
place without violating the no-benchmarking policy.

> Incidentally if anyone has news of what stage DEC are in making the alpha chip
> available on a large scale, can they let me know.

If you are interested in purchasing a large quantity of the alpha chips,
contact your local DEC salesperson; they might be able to help you out. DEC is
certainly producing these chips on a production scale. 

-amitabh.

--
______________________________________________________________________________
Amitabh Shah                                   shah@tay1.dec.com----(INTERNET)
Digital Equipment Corporation                  santur::shah----------(EASYNET)
Software Performance Group                     +1 508 952 4430---------(PHONE)
151 Taylor St. Littleton MA 01460              +1 508 952 4197-----------(FAX)
From: wllarso@sandia.gov (William L Larson)
Newsgroups: comp.benchmarks
Subject: Sun SPARCstation 10 benchmarks
Date: 8 Oct 92 15:19:23 GMT
Article-I.D.: cs.1992Oct8.151923.28095
Organization: Sandia National Laboratories

Does anyone have any info as to what the TPC benchmark results
are for the new SPARCstation 10 machines?
Newsgroups: comp.benchmarks,comp.sys.sun.misc,comp.unix.misc
From: jeff@onion.rain.com (Jeff Beadles)
Subject: Re: NFS performance on AUSPEX ?
Reply-To: jeff@onion.rain.com (Jeff Beadles)
Distribution: comp
Date: Sat, 10 Oct 1992 01:52:29 GMT

murai@rd.yahata.enicom.nsc.co.jp (Toshifumi Murai) writes:


>I'm looking for report of NFS performance on AUSPEX(NS3000) compared
>with SparcStation2.
>Does anyone have any report about the NFS performance?

Auspex should be more than happy to supply this information.
They blow Sun away in this area.

We've got a 5000, and it literally smoked the 690 with a similar
configuration.  (10gb(20?), 8 ethers, etc..)

Sparcstations are not really fileservers.  If you have to halt the system
to replace a disk, it's not a fileserver.  (IMHO, of course. :)

	-Jeff
-- 
Jeff Beadles		jeff@onion.rain.com
Newsgroups: comp.benchmarks
From: pjd2@po.CWRU.Edu (Pedro J. Diaz)
Newsgroups: comp.benchmarks
Subject: HP 7100 Architecture and Performance Info
Date: 17 Oct 1992 01:46:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: pjd2@po.CWRU.Edu (Pedro J. Diaz)
NNTP-Posting-Host: thor.ins.cwru.edu

Can some one point me to available data/publications on the performance
and architecture of the HP 7100 series.           
                                                  
Thanks.                                    
               
               
P. J. Diaz, Asst Professor
EBME
 

Newsgroups: comp.benchmarks