HDTenEightyP/NetNews huggingface dataset:
From: sheldon@iastate.edu (Steve Sheldon)
Subject: Re: Question about ISA/IDE disk throughput (pc newbie)
Organization: Iowa State University, Ames IA
Distribution: comp
Date: Tue, 22 Dec 1992 20:51:50 GMT

In <MUTS.92Dec21193512@PMCS.estec.esa.nl> muts@estec.esa.nl (Peter Mutsaers) writes:

>Sorry if you see this message twice. I posted before but the article
>didn't seem to show up.

>In a magazine I read for a couple of 386sx PC's that disk access (IDE)
>is only at 200 kbyte/s. This seems terribly slow to me, especially
>for an OS like unix. Is this really true? Do 486dx's have much better
>IO speeds? How can UNIX live with such a low bandwidth. Are local
>busses much faster (how much)?

 That's not right.  On my 386sx PC at home I get a transfer rate of 
around 550 Kb/s with a WD Caviar 80 IDE drive.

 We have several machines here in our lab running Unix on IDE drives:

 486DX50 w/16 Megs RAM 256K cache
 340 Meg IDE drive
 SCO Opendesktop

 Transfer rates on these machines are in the neighborhood of 1000 Kb/s
to 1200 Kb/s, depending on the drive.  (Western Digital's 340 Meg is
slightly faster than the Maxtor)

 How can *nix survive?  Quite easily... These do everything they're called
upon to do quite well.

 But then our machines are single user consoles, where disk activity was
less an issue than processor speed and graphics speed.

 I don't know if I'd recommend an IDE setup for a machine to be setup
as a server, or one with a lot of users.  But then I don't know as if I'd
recommend anything on an ISA bus for that either.

 
-- 
sheldon@iastate.edu                Steve Sheldon
Project Vincent                    ICSS Resource Unit
SCO ODT, Arc/Info, Atlas GIS       2142 Agronomy Hall
                                   Iowa State University
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
From: roell@informatik.tu-muenchen.de (Thomas Roell)
Subject: Re: ET4000/W32 and VESA VL-Bus
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
	<1992Dec20.153314.24148@Informatik.TU-Muenchen.DE>
	<BzKqwn.5vA@wimsey.bc.ca>
Date: Tue, 22 Dec 1992 21:30:14 GMT

>DRAM cycles, therefore if you are using say 110Mb of bandwidth to
>feed a 1280x1024x8 display, the theoretically 50Mb/sec bandwitdh
>left over will actually be more like 10-20Mb/sec, as most graphics
>operations will not be able to take full advantage of page mode,
>even if the bus interface to the local bus supports it.

This raises the intresting question how much is exactly left over.
Let's do some computations for the currently common case of 1024x768
in 60Hz (i.e. 65MHz dot-clock). First a few assumptions (which seem to
be realistically for the WD90C31 (where I looked deeper into the
databook)):

	a) 100MB/sec total bandwidth (fast page mode)
	b) 32 bytes internal buffer for screen refresh
	c) a RAS cycle needs twice the time of a CAS cycle.
	d) all accesses are 32bit wide.

Hence we have 25 * 10**6 accesses/sec by using
(tRAS + 8 * tCAS) / 8 = 10 / 8* tCAS timeunits, which would mean that
tCAS is 32ns. Ok, for a 65MHz dot-clock we need during display a pixel
every 15ns. That means every 15ns * 32 we have to reload the internal
buffer, which is every 480ns. For reloading we need 32ns * 10 = 320ns.
In fact we now have 160ns for the graphics engine left. Now assume
that all accesses in this perion can be fast page mode, then we can do
3 accesses (we have to do one RAS cycle ...), which is that for every
480ns we can get 12 bytes, which then is totally 25MB/sec.

Unless I made a serious computing mistake this means that we get only
25MB/sec on a 100MB/sec bandwidtg system if a dot-clock of 65MHz is
used.

Now lets go on, and say we use a 75MHz dotclock to get the 70Hz high
refresh rate. Here we need every 420ns a reload of the buffer. Then we
have only 100ns for the graphics engine left. That says we can (by
rounding things a little bit up) get only 4 bytes over a 480ns period,
which is 8.3 MB/sec. 

Actually this computation doesn't include the fact the the real active
period is only 80% to 90% of the while time spent. Hence one could add
about 10% additional bandwidth to the numbers I computed here. But
what they show pretty clearly is that the bandwidth left after the
screen refresh for the graphics engine is pretty small, even if the
total available bandwidth (total bandwidth - screen refresh bandwidth)
would be much higher.

Note also that in a VRAM based system with the same characteristics we
would have roughtly the whole 100MB/sec available for graphics
operations.

- Thomas

--
-------------------------------------------------------------------------------
Das Reh springt hoch, 				e-mail: roell@sgcs.com
das Reh springt weit,				#include <sys/pizza.h>
was soll es tun, es hat ja Zeit ...
Newsgroups: comp.unix.pc-clone.32bit
From: acmrlb@gsusgi2.gsu.edu (Ronald L. Bolin)
Subject: Re: Booting DOS or Unix optionally from the same HD?
Organization: Georgia State University
Date: Mon, 28 Dec 1992 13:31:42 GMT


I use a program called "pfdisk" which provides
a menu of upto 4 operating systems to boot from. However, to use it
you will have to load UNIX on your HD first.  After that you could 
remove unix and continue using the the boot menu for other OS.


pfdisk with source is FREE, and can be found on the net.
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Which motherboard?
Date: 30 Dec 92 13:28:43 GMT
Organization: University of Helsinki

This is just a follow-up to the discussion about non-caching in the
16MB+ range - as I hoped, getting the bigger cache solved the problem. 
So, if you have problems with some of your memory seeming much slower
than it should be, upgrading your external cache to the maximum amount
may well help you.  On a 486, inability to cache may result in a
slowdown of more than one order of magnitude (I saw 20 times slower
execution in a non-cached area). 

The particular chipset on the motherboard I have is by Contaq,
specifically 82C591/82C592.  With a 64kB cache, only the low 16MB is
cached, while a 256kB cache allows for caching the full memory area
(well, I can try only up to 20MB, but I'd assume it gets cached at least
up to 32MB, and probably to the full 64MB that the motherboard
supports).  The problem is not mentioned in the motherboard manual. 

Hope this may solve similar problems by others: the reasons for these
slowdowns may not be immediately obvious, especially if the machine
seems to run DOS etc fine (at least DOS very seldom uses the 16MB+ area
heavily, so you'll probably never see the problem very clearly). 

		Linus
Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux
From: turbo@cse.uta.edu (Chris Turbeville)
Subject: Re: Question about ISA/IDE disk throughput (pc newbie)
Followup-To: Question about ISA/IDE disk throughput (pc newbie)
Summary: Get a better bus
Keywords: speed bus IDE EISA ISA SCSI VESA
Organization: Computer Science Engineering at the University of Texas at Arlington
Distribution: comp
Date: Mon, 21 Dec 1992 22:00:09 GMT

In article <MUTS.92Dec21193512@PMCS.estec.esa.nl> muts@estec.esa.nl (Peter Mutsaers) writes:
>Sorry if you see this message twice. I posted before but the article
>didn't seem to show up.
I didn't see it twice.
>
>In a magazine I read for a couple of 386sx PC's that disk access (IDE)
>is only at 200 kbyte/s. This seems terribly slow to me, especially
>for an OS like unix. Is this really true? Do 486dx's have much better
>IO speeds? How can UNIX live with such a low bandwidth. Are local
>busses much faster (how much)?
200kB/s sounds about right for IDE (save the newer caching controllers)
and it is terribly slow.  486dx's make no improvement on disk transfer
speed.  It is your 16bit 8Mhz ISA bus which is limiting it.  I don't
think full blown vmunix would live well in such an environment.  Local
busses are faster and so is EISA but here is my quandry.  I want top
transfer speed from a SCSI-2 FAST (is WIDE very available?) disk which
according to things I have read is 10MB/s (They put a big b as in
mega-bytes per sec can anyone confirm this for SCSI-2 FAST?).  Now
EISA's top transfer speed is well beyond that so technically EISA should
be fast enough right?  So is this the upper limit?  Or can we with a
caching (I know don't waste money on a caching controler till you have
>64meg on your motherboard but for the sake of argument) SCSI-2 FAST
controller with a VESA bus and move to the specified 110MB/s VESA LB is
supposed to have?  Or is it really that no hard drive can move faster
than even the EISA bus but graphics plus hard drive can outstrip EISA
requireing the new VESA standard?  Any techies out there have some
semi-hard (I know no numbers are really reliable) numbers on
ISA/EISA/VESA?  What I want to know is what is the fastest bus/HD
combination?  How will it work with a 32bit graphics card?  I am just
stumped as to which board to buy and I just keep putting it off to see
the results of these hardware battles.  (Sorry Peter to answer your
questions with questions but I am stuck in this and your questions "got
me going" on it.)
-Chris
Thanks
-Chris


Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.unix.bsd,comp.windows.x
From: fluet@ee.ualberta.ca (Kevin Blaine Fluet)
Subject: Re: Will Linux/386BSD/XFree86 run on my Gateway 2000 4DX2-66V?
Organization: University Of Alberta, Edmonton Canada
Date: Tue, 22 Dec 1992 09:59:59 GMT

>>>   (Micronics motherboard, 8MB RAM to be expanded to 16MB, VESA VL-Bus,

>   I thought that it was expandable to 64MB on motherboard !!!

It is expandable to 64 MB on board using 16MB SIMMs.  There are four banks
on the motherboard, and the standard 8MB configuration comes with two 4MB
SIMMs installed. 

By the way, Linux runs very well on my Gateway 4DX2-66V.  I am typing this
note in an xterm window under SLS linux .98p5 and Xfree1.1.  

----------------------------
Kevin Fluet
fluet@ee.ualberta.ca
----------------------------

Newsgroups: comp.unix.pc-clone.32bit
From: dewey@sooner.ctci.com (Dewey Coffman)
Subject: Re: Dell support?
Summary: Dell UNIX orphaned
Organization: CTC, Inc., Austin, TX. U.S. of A. 78757-3109
Date: Mon, 28 Dec 1992 00:14:38 GMT

In article <66@nearside.UUCP> shwake@nearside.UUCP (Raymond Shwake) writes:
>richard@pegasus.com (Richard Foulk) writes:
>
>>Some time back there was a rumor that a number of the more important
>>Dell support folks were let go or something.  I don't remember hearing
>>anything more about this and was wondering what actually happened, if
>>anything.
>
>	According to my sources, some of the Dell UN*X crowd have gone
>	over to Information Foundation in Denver, CO.

	*ONE* person from Dell's UNIX *DEVELOPMENT* team probably went there. 
	I know he left and went somewhere in Colorado, but I don't know the
	company name.
	Several are now at HaL Computer, Austin.
	Several are now contracting at IBM, Austin
	One is still there (on UNIX), Another left just recently.
	Another one is now on BIOS, and that's it.
	I believe they still have quite a staff of Support Personnel, but
	that basically all that's left.(or so I've been told)
>
>>What's the current status of support and development for Dell Unix?
>	Don't know, except that Dell seems to be moving toward Solaris,
>	rather than SVr4.2.

	I doubt you'll see any more development out of Dell on THEIR UNIX
	product.

	Good Luck.
From: stu@mav.com (Stu Donaldson)
Subject: gcc 2.3.2 (i386-isc)
Reply-To: stu@mav.com
Organization: Maverick International Inc.
Date: Wed, 23 Dec 92 20:37:33 GMT

  I just grabbed gcc 2.3.2 and did the following:
 
 	configure i386-isc
 	make bootstrap
 
  It made stage1 without error.  (Actually it should probably be pointed out
  someplace that a large ulimit is required to make this since the unstripped
  cc1 is about 2.8 Megabytes.  Hmm it could easlily be pointed out somewhere
  and I just didn't see it.)
 
  On to making itself with stage1, that seemed to go ok, but when it got back
  to making enquire.c with the new xgcc, it dies with:
 
 	./xgcc: Internal compiler error: program cc1 got fatal signal 6
 
  On invoking sdb on the program cc1, and looking at the stack, it
  yields the following:
 
 	kill: address 0xc6a50
 	* t
 	kill() has no subroutine linkage (pushl)
 	        Maybe kill(0x3275,6) from abort()   [abort.c] <-- My guess
 	        Maybe kill() from gcc2_compiled.()
 	abort()   [abort.c]
 	float_signal(signo=8)   [toplev.c:1400]
 	standard_80387_constant_p(x=0x413f20)   [aux-output.c:446]
 	record_reg_classes(n_alts=4,n_ops=2,ops=0x40ddf8,modes=0x7ffff394,constraints=0x
 	7ffff3bc,insn=0x413f7c)   [regclass.c:1126]
 	regclass(f=0x413bbc,nregs=25)   [regclass.c:826]
 	rest_of_compilation(decl=0x4302b8)   [toplev.c:2427]
 	finish_function(nested=0)   [c-decl.c:6088]
 	yyparse()   [c-parse.c:289]
 	compile_file(name=/usr/tmp/cca12915.i)   [toplev.c:1803]
 	main(argc=11,argv=0x7ffff9e8,envp=0x7ffffa18)   [toplev.c:3285]
 
  This is strange, it appears as though cc1 is getting a floating point
  exception from a floating point comparison in aux-output.c.  However
  the signal returned to gcc is 6, rather than 8.  Not to mention that
  this is straight out of the box, and it probably shouldn't be getting
  the error in the first place.
 
  Anybody else run into this?  This is running on ISC 386/IX VR3.2 (2.2.1)
  Should I be using a different configure option?  I tried i386-sysv,
  and it couldn't find putc when linking.

  Thanks for any suggestions.
 
 	-- Stu --
 


-- 
-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What happened?  Did you Fail Telepathy?"
Xref: sparky comp.unix.pc-clone.32bit:883 comp.unix.sysv386:17604 comp.unix.bsd:10580 comp.os.linux:21487
From: gab10@griffincd.amdahl.com (Gary A Browning)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Subject: Re: ET4000/W32 and VESA VL-Bus
Date: 23 Dec 92 05:03:36 GMT
Organization: Amdahl Corporation

In article <BzKqwn.5vA@wimsey.bc.ca>, bhenning@wimsey.bc.ca (Bill
Henning) writes:
> The problem with DRAM based accelerators, even if they get 160Mb/sec
> bandwidth out of the DRAM's is that the bandwidth is not
> random-access,
> but is rather a result of page mode (or static column, or nibble
> mode)
> DRAM cycles, therefore if you are using say 110Mb of bandwidth to
> feed a 1280x1024x8 display, the theoretically 50Mb/sec bandwitdh
> left over will actually be more like 10-20Mb/sec, as most graphics
> operations will not be able to take full advantage of page mode,
> even if the bus interface to the local bus supports it.
> 
> Bill

Don't overlook bus width in your analysis.  The W32 sounds like it is 32 bit
wide path instead of the 8 (16?) - bit wide path of the standard ET4000.
This would quadruple (double?) the bandwidth of any type of ram access.

-- 
Gary Browning        | Exhilaration is that feeling you get just after a
		     | great idea hits you, and just before you realize
                     | what is wrong with it.
From: lewis@ais.org (David T. Lewis)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Booting DOS or Unix optionally from the same HD?
Summary: Zenith used to do this in BIOS PROMS
Date: 27 Dec 92 20:45:52 GMT
Organization: UMCC

In article <1992Dec26.231830.2301@weyrich.UUCP> 
uunet.uu.net!weyrich!orville writes:
>In article <BzFnwF.6ox@leo.irv.icl.com> tim@leo.irv.icl.com (Tim Holdener) 
writes:
>
>>After installing Unix, the system always booted Unix from the
>>hard disk.  The only way I could boot DOS was to place a DOS boot
>>diskette in the floppy drive.  Does anyone know a method of
>>configuring such a system to allow the option of booting either
>>Unix or DOS from the same hard disk?  I'm sure an appropriate
>>BIOS would work, but can I buy such a PROM commercially?
>

. . .

>I have never seen a BIOS that provides boot manager services -- although
>I am sure that it could be done. 

My Zenith Z-241 (6MHz AT clone) provides this service in BIOS.  I use it
to boot either DOS or Microport System V/AT.  It also permits booting
from a partition on the second hard drive.  I don't know if Zenith still
supports this feature in current machines.
From: noah@acsu.buffalo.edu (Philip D. Noah)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Linux from tsx-11.mit
Keywords: HELP !!
Date: 23 Dec 92 14:12:34 GMT
Organization: UB

I have the SLS package from tsx-11.mit.edu. now would someone be so kind
as to tell me how to uncompess it.
thanks


Philip D. Noah Jr.
SUNY University Center at Buffalo
LAN SYSTEMS
108 Computer Center
Buffalo, Ny 
(716)-645-3508
noah@acsu.buffalo.edu (sun)
opnsnoah@ubvms.cc.buffalo.edu (vax)
opnsnoah@ubvm.cc.buffalo.edu  (ibm)
From: oswms@diamond.pgh.wec.com (William J Seng)
Newsgroups: comp.unix.cray
Subject: UNICOS MLS version of op
Date: 31 Dec 1992 15:30:46 -0500
Organization: Westinghouse Corporate Computer Services
Distribution: world

Hello,

I am looking at Tom Christiansen's version of "op" with thoughts of
using it on a UNICOS system running Multi-level Security (MLS).

MLS introduces additional levels of security that even root cannot
bypass.  Has anyone out there looked at this or have any experience
with it (good, bad, otherwise)?

I appreciate any and all comments on this.

Thanks.

BIll Seng
From: spl@pitstop.ucsd.edu (Steve Lamont)
Newsgroups: comp.unix.cray
Subject: Re: Cray EL
Date: 21 Dec 1992 18:51:24 GMT
Organization: University of Calif., San Diego/Microscopy and Imaging Resource
Distribution: inet
NNTP-Posting-Host: pitstop.ucsd.edu

In article <BzL9CC.9E@rex.uokhsc.edu> ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:
>      I havn't heard too much about the Cray-3 -- is it out yet?  I
>heard that they were still having problems, but I don't talk to too many
>people who work in this area.  It sounds like a nice computer...

Rumor has it that Cray Computer (note: different company than Cray
Research, makers of the "letter" Crays) has contracted with NCAR for a
Cray-3.  The first contract, with Lawrence Livermore Labs (NERSC???
Memory fails), fell through due to delivery problems.

Someone at SDSC mentioned to me that Seymour Cray is already on to
designing the Cray-4.  Comments from CCC?

							spl
-- 
Steve Lamont, SciViGuy -- (619) 534-7968 -- spl@szechuan.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
Where is the summer, the unimaginable
Zero summer?                 - T.S. Eliot, "Little Gidding"
From: nguye_d@mist.cs.odu.edu (Duc Nguyen)
Newsgroups: comp.unix.cray
Subject: Cray C-90
Date: 3 Jan 93 18:30:29 GMT
Distribution: usa
Organization: Old Dominion University, Norfolk, Va

My question is:  is there any improvement on vectorized dot-product operation 
new model on Cray C-90.  On Cray Y-MP, dot-product is not as good as Saxpy. 
Is it still true on Cray C-90? 
Any information will be greatly appreciated.
--
From: dpmccul@afterlife.ncsc.mil (Dean McCullough)
Newsgroups: comp.unix.cray
Subject: Re: Cray EL
Date: 22 Dec 92 01:07:46 GMT
Organization: The Great Beyond


>       I am curious as to what anybody thinks of the Cray EL.  I am
>looking over some stuff, but I was wondering what other people think of
>it -- especially people who have worked with it.  I have worked with
>the Cray YMP as a user, but I wonder how much translates down to
>the Cray EL.  How does it run vector, scaler, IO, etc?
 
Just started looking at it, but in an initial set of benchmarks,
comparing one processor to one processor of the YMP-8, the EL was
running 5 to 8 times slower.  This is more than the difference in
clock rate would account for (each program was recompiled for each
machine).   We have not looked hard at the code to understand why the
differences; which will need to be done before any thing definitive
can be said.
From: handeli@phoenix.ocf.llnl.gov (David I Handeli)
Newsgroups: comp.unix.cray
Subject: Simple User Interface Toolkit
Keywords: gui, motif, windows, mac, unix
Date: 22 Dec 92 21:06:19 GMT
Distribution: usa
Organization: Lawrence Livermore National Laboratory

I was looking at the documentation for the Simple User Interface
Toolkit (SUIT) from University of Virginia.
Has anyone ported this toolkit to UNICOS? If so, is it freely
available. Thanks.
Newsgroups: comp.unix.cray
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: Cray EL
Organization: University of Alabama at Birmingham
Date: Tue, 22 Dec 1992 01:45:11 GMT

In article <1992Dec22.010746.12873@afterlife.ncsc.mil> dpmccul@afterlife.ncsc.mil (Dean McCullough) writes:
>
>>       I am curious as to what anybody thinks of the Cray EL.  I am
>>looking over some stuff, but I was wondering what other people think of
>>it -- especially people who have worked with it.  I have worked with
>>the Cray YMP as a user, but I wonder how much translates down to
>>the Cray EL.  How does it run vector, scaler, IO, etc?
> 
>Just started looking at it, but in an initial set of benchmarks,
>comparing one processor to one processor of the YMP-8, the EL was
>running 5 to 8 times slower.  This is more than the difference in
>clock rate would account for (each program was recompiled for each
>machine).   We have not looked hard at the code to understand why the
>differences; which will need to be done before any thing definitive
>can be said.  

Might be memory.  Seems that the memory on the EL is significantly
slower than the base YMP.  The new big memory YMP can be significantly
slower due to it's memory speed.... and I suspect that the EL uses
this slower memory as it's standard.....  Not having run on either
of the two machines (EL or big Y), I don't qualify as an expert.  


-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
From: oswms@diamond.pgh.wec.com (William J Seng)
Newsgroups: comp.unix.cray
Subject: UNICOS MLS and "op"
Date: 31 Dec 1992 15:59:57 -0500
Organization: Westinghouse Corporate Computer Services
Distribution: world
NNTP-Posting-Host: diamond.pgh.wec.com

Hello,

I am looking at Tom Christiansen's version of "op" and would like to
port it to UNICOS running Multi-level Security (MLS).  Does anyone
out there have any experience with running "op" on UNICOS MLS?

An extra layer of security has to be passed in order to perform
certain functions (even as root).

Any ideas?

Thanks,

- Bill Seng
From: chet@odin.ins.cwru.edu (Chet Ramey)
Newsgroups: comp.unix.questions
Subject: Re: The Revenge of CSH
Date: 1 Jan 1993 22:07:09 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: odin.ins.cwru.edu

In article <800@cebu.sbi.com> goldfish@cebu.sbi.com (P. Goldsmith) writes:

[about ksh]
>(it is also the official POSIX shell, so it is, after a fashion, a standard
>in itself)

This is somewhat inaccurate.  The Posix 1003.2 folks took a number of
features from the Korn shell and incorporated them into their shell
specification, but ksh-88 (and perhaps not ksh-92, if Korn follows through
on some of his previous statements) is not fully compliant with the Posix.2
spec.  There is no `official Posix shell'.  There are simply shells which
comply with the 1003.2 specification.  ksh is quite close to complying.  So
are bash and the 4.4 BSD-alpha sh. 

Chet

-- 
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu
Newsgroups: comp.unix.questions