HDTenEightyP/NetNews huggingface dataset:
From: ckurs-2@goofy.uni-mainz.de (Teilnehmer am C-Kurs WS 1992_93)
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Organization: Johannes Gutenberg Universitaet Mainz
Date: Fri, 18 Dec 1992 12:00:41 GMT

In article <1992Dec16.215109.27531@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
|> 
|> [...]
|>  
|> Several people have mentioned the RAM-disk idea, and yes, it would be
|> very simple indeed, as linux already has a ramdisk option - right now it
|> gets its memory from the low end of the 1M+ area, but changing it to use
|> the high addresses would be very easy indeed.  I never use it, though,
|> as I find ramdisks generally silly (but it's useful at installation-time
|> when you don't have a ready-made filesystem etc, and some people seem to
|> perfer to have a ramdisk). 
|> 
|> After you've created the ramdisk, swapping to it is as easy as saying
|> "mkswap /dev/ram <size> ; swapon /dev/ram".  And the linux swapping
|> routines can already handle multiple devices (or multiple swapfiles, or
|> any combination of these), so after one device (the ramdisk) fills up,
|> the swapping algorithms automatically use the next swap-device (thus you
|> automatically get the best performance if you do the "swapon"s by how
|> fast the device is: first ramdisk, then disk partition and then
|> swapfile). 
|>
|> [...]
|> 
|> 		Linus

There is another considerable option to this:
Is it possible to use one of those old Hardware-EMS-Cards for swapping?
They offer up to 32 MB and should be a lot faster than swapping to disk and you
can get them cheap ... This would be helpful the for old-style 386 computers
with slow HD's and limited RAM size (eg Amstrad: 4 MB RAM, *NO* SIMM's ...).
Only problem that i can see is the bankswitching.

+-----------------------------------------------------------------------------+
| eMail to:      kubla@MZDMZA.ZDV.UNI-MAINZ.DE                                |
| sMail to:      Dominik Kubla, Steinsberg 34, 5428 Nastaetten, GERMANY       |
+-----------------------------------------------------------------------------+
|                                                                             |
|                     I don't like LINUX, I  *LOVE*  it ...                   |
|                                                                             |
+-----------------------------------------------------------------------------+
Newsgroups: comp.unix.pc-clone.32bit
From: "David Herron" <david@twg.com>
Subject: Re: Adaptec 1742A on ISC-3.0
Sensitivity: Personal
Encoding:  25 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Sat, 12 Dec 1992 03:03:10 GMT

Okay.. so I'm answering my own question.  So what?

> We just received an Everex 486 DX2 (25/50 MHz) EISA system.  It
> has an Adaptec 1742A with Maxtor ~600 meg SCSI drive.

And I continued on with a tale of woe ..

After a call to Interactive I found that the answer was right there
in the manual in a chart I (obviously) hadn't read too closely.  It
boils down to these pieces of information:

- The Interactive install stuff is unable to talk to a 1742 in
  its enhanced mode.  (The chart on page 113 doesn't list aha1740
  as a possibility).

- Therefore the card *must* be put in compatibility mode to do
  the installation.

- When it's in compat mode it must be accessed via the I/O addresses.
  The only possible value for the addresses is listed in the chart.

  My mistake was not seeing this chart and using those addresses.  I
  just put it in compat mode & continued on my merry way.

I've done this & things are working fine.

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
Newsgroups: comp.unix.pc-clone.32bit
From: root@combdyn.com (0000-Admin(0000))
Subject: adding 2nd ESDI harddrive to ISC 3.0
Followup-To: lawrence@combdyn.com
Organization: Combustion Dynamics Ltd.
Date: Thu, 17 Dec 1992 00:20:20 GMT

I'm running out of harddrive space on my ISC 3.0 UNIX box, I'm told that it
currently has a WD1007-VSE2 controller with a MAXTOR 8380E harddrive.  I'd like
to get some general comments from the net (by Email, I'm not connected to the
comp.unix hiearchy since the reorg) on adding an additional harddrive to this
combination.

I'll also accept well explained reasons for abandoning ESDI and moving to SCSI,
which is my personal preference, to sell the idea to management.....8-)

-- 
 --EMAIL-----------------------------PHONE-----------FAX------------
 | WORK: lawrence@combdyn.com      | (403)529-2162 | (403)529-2516 |
 | HOME: dreamer@lhaven.uumh.ab.ca | (403)526-6019 | (403)529-5102 |
 -------------------------------------------------------------------
  disclamer = (working_for && !representing) + (Combustion Dynamics Ltd.);
Xref: sparky comp.unix.pc-clone.32bit:828 comp.unix.sysv386:17464 comp.unix.bsd:10300 comp.os.linux:20737
From: hasty@netcom.com (Amancio Hasty Jr)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Subject: Re: ET4000/W32 and VESA VL-Bus
Date: 16 Dec 92 23:26:47 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <1992Dec16.191911.9003@bmerh85.bnr.ca> Daniel.Tessier@bnr.ca writes:
>In article <1992Dec16.155355.7416@netcom.com>, hasty@netcom.com (Amancio Hasty Jr) writes:
>|> In article <BzBEI1.CH@aeon.in-berlin.de> thomas@aeon.in-berlin.de (Thomas Wolfram) writes:
>|> >Hi,
>|> >does anyone already using the new ET4000/W32 chip, perhaps in an
>|> >VESA VL local bus version? How is the performance compared with
>|> >ET4000AX and does it work with XFree86 1.1?
>|> >
>|> >Thank you,
>|> >Thomas
>|> >-- 
>|> >Thomas Wolfram, thomas@aeon.in-berlin.de
>|> >EANTC, TU Berlin, wolf@prz.tu-berlin.de, +49 030 31421294
>|> 
>|> S3 is faster than the et4000 based technology the reason is because
>|> of the server and its use of hardware assisted graphics functions.
>|> We are about  6 times faster than an ISA et4000. In fact, it is more
>|> accurate to say that XS3 can compete against your typical workstations
>|> such as suns workstations. Typically an S3 801 costs less than $220(US).
>|> XS3 is our X server for S3 chipsets and it runs on 386bsd and Linux.
>|> 
>|> XS3 has been clocked at 64k xstones on 486/33Mhz ISA machines. However,
>|> our xbench complex tests are typically higher than on the sun workstation
>|> ipx/gx.
>|> 
>|> Soon I will find out how fast is XS3 on my new 486/50Mhz VL bus with a 
>|> local bus S3 801 card.
>|> 
>That's nice, but did it answer the question?
>- "How fast is the ET4000/W32?"
>- "The S3 is so fast, it'll blow Suns away"
 XS3 has been clocked at 64k xstones on 486/33Mhz ISA machines. 
>
>Try to keep your preaching/propaganda for people who actually wan it.
>-- 
I just copy again how fast is my X server. It appears that you can't read.
Later chump,
Amancio

>/---------------------------------------------------------------\
>| Dan Tessier		       PHONE   : (613)765-2380		|
>| Bell-Northern Research, Ltd. INTERNET: Daniel.Tessier@bnr.ca 	|
>| Ottawa, Ontario, Canada      UUCP    : none right now...	|
>+---------------------------------------------------------------+
>| "Live and don't learn, that's us."				|
>|			       - Calvin & Hobbes		|
>\---------------------------------------------------------------/










-- 
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail hasty@netcom.com	|  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Newsgroups: comp.unix.pc-clone.32bit
From: andy@homebase.vistachrome.com (Andy Finkenstadt)
Subject: Re: Adaptec 1742A on ISC-3.0
Reply-To: andy@homebase.vistachrome.com
Organization: Vista-Chrome Incorporated
Date: Sun, 13 Dec 1992 18:52:56 GMT

I was about to write you with this solution, but I see you already
found it.  I too initiated my 30-day support the first time I had
to use the 1742. :>  Thank god for multiple licenses!
-Andy

"David Herron" <david@twg.com> writes:

>Okay.. so I'm answering my own question.  So what?

>> We just received an Everex 486 DX2 (25/50 MHz) EISA system.  It
>> has an Adaptec 1742A with Maxtor ~600 meg SCSI drive.

>And I continued on with a tale of woe ..

>After a call to Interactive I found that the answer was right there
>in the manual in a chart I (obviously) hadn't read too closely.  It
>boils down to these pieces of information:

>- The Interactive install stuff is unable to talk to a 1742 in
>  its enhanced mode.  (The chart on page 113 doesn't list aha1740
>  as a possibility).

>- Therefore the card *must* be put in compatibility mode to do
>  the installation.

>- When it's in compat mode it must be accessed via the I/O addresses.
>  The only possible value for the addresses is listed in the chart.

>  My mistake was not seeing this chart and using those addresses.  I
>  just put it in compat mode & continued on my merry way.

>I've done this & things are working fine.

><- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
><-
><- During the '80s Usenet's mantra was: "Not all the world's a VAX".
><- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
-- 
Andrew Finkenstadt, Vista-Chrome, Inc., Homes & Land Publishing Corporation
GEnie Unix RoundTable Manager, andy@vistachrome.com, andy@genie.geis.com.
  Join GEnie, call 800-638-9636/301-251-6415.  Join Unix, CASE, and Desktop 
  Oracle RDBMS Database discussions, send mail to ora-request@vistachrome.com
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: ET4000/W32 and VESA VL-Bus
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 16 Dec 1992 15:53:55 GMT

In article <BzBEI1.CH@aeon.in-berlin.de> thomas@aeon.in-berlin.de (Thomas Wolfram) writes:
>Hi,
>does anyone already using the new ET4000/W32 chip, perhaps in an
>VESA VL local bus version? How is the performance compared with
>ET4000AX and does it work with XFree86 1.1?
>
>Thank you,
>Thomas
>-- 
>Thomas Wolfram, thomas@aeon.in-berlin.de
>EANTC, TU Berlin, wolf@prz.tu-berlin.de, +49 030 31421294

S3 is faster than the et4000 based technology the reason is because
of the server and its use of hardware assisted graphics functions.
We are about  6 times faster than an ISA et4000. In fact, it is more
accurate to say that XS3 can compete against your typical workstations
such as suns workstations. Typically an S3 801 costs less than $220(US).
XS3 is our X server for S3 chipsets and it runs on 386bsd and Linux.

XS3 has been clocked at 64k xstones on 486/33Mhz ISA machines. However,
our xbench complex tests are typically higher than on the sun workstation
ipx/gx.

Soon I will find out how fast is XS3 on my new 486/50Mhz VL bus with a 
local bus S3 801 card.

Enjoy,
Amancio Hasty








-- 
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail hasty@netcom.com	|  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386
From: deutsch@euclid.math.colostate.edu (jesse deutsch)
Subject: Re: PC-Clone UNIX Hardware Buyer's Guide
Date: Sat, 12 Dec 1992 22:54:03 GMT
Organization: Colorado State University, Fort Collins


Was such a hardware buyers guide posted?  Must have missed
it.  Is it archived anywhere?  Else, can someone be so
kind as to email me a copy?

Thanks for your help

Jesse Deutsch
#insert standard disclaimer
Newsgroups: comp.unix.pc-clone.32bit
From: aarond@xibm.StorTek.com (Aaron Dailey)
Subject: Re: Which motherboard?
Organization: StorageTek
Date: Fri, 11 Dec 1992 23:33:31 GMT

In article <1992Dec8.144629.17255@microware.com> adam@microware.com (Adam Goldberg) writes:


   The biggest problem isn't a caching problem; it's a DMA problem.  The
   standard ISA-bus DMA will only work for memory <=16MB.  In fact,
   although many boards support more than 16MB of memory, none of them
   (to my knowledge) have implemented a DMA system which is backward
   compatible, and will work past the 16MB line.  I don't believe it is
   possible.

Actually it's possible, I just don't think anyone does it in a
standard way.  We use a PC VLSI Technologies chipset for an embedded
system we are building, which will support DMA over 16MB with some
additional registers.  However, I doubt (pure speculation) that anyone
else does this, or if they do if it's in a standard way.  Also, I
don't think VLSI is a very popular chipset manufacturer.

   You wouldn't be buying a crippled board, you'd be buying the best that
   is available that is PC-compatible.  You should note that it is
   possible for an OS to do things in such a way as to take advantage of
   >16MB--by insuring that DMA xfer will only take place under the 16MB
   line. 

   >Does anyone know of an EISA board with a cache controller
   >which has more than 24 bits in the tag field?

   This I do not know.

   -- 
   Adam G.
   adamg@microware.com, or ...!uunet!mcrware!adamg
   The above is not to be construed in any way as the official or unofficial
   statements of Microware, or any Microware employees.

--
Aaron Dailey Internet: Aaron_Dailey@stortek.com
StorageTek Corporation   Voice: (303) 673-4989, FAX: (303) 673-2570
Mail:  MS0242, 2270 South 88th Street, Louisville, C0 80028

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
Date: Sun, 20 Dec 1992 15:33:14 GMT

Oooppps, now I can see the point that caused confusion.

The ET4000 and the ET4000/W32 are completly different chips. The latter one
is Tsengs answer to the other Windows Accellerators. It has a full blown
graphics engine, from the set of possible things compareable to the S3
chips, but more tuned for MS-Windows. It ought to use DRAMs, and Tseng
said it will extend the chips speed up to a total memory bandwidth of
160 MB/sec enabling users to display 1280x1024 @ 70Hz. Most of the
chip is backwards compatible to the ET4000, but has an additional set
of memory mapped registers for the graphics engine (similar to the XGA).

I must admit that most of this information is from an article in a
german magazine, which was sometimes very unclear (and hence I didn't cite
here more details). One OEM board company is said to ship ET4000/W32 based
boards already, but I cannot approve this.

Before I forget it, the chairman of the VESA Local Bus commettee is a
manager from Tsengs Labs. Hence one can expect this chip running on the
local bus pretty neatly ...

- 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 ...
From: wadswort@babss.UUCP (John H. Wadsworth)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Which motherboard?
Date: 14 Dec 92 15:25:10 GMT
Followup-To: comp.unix.pc-clone.32bit
Organization: Bell Atlantic Business Systems Service Branford, Ct.

In article <AAROND.92Dec11163331@xibm.StorTek.com> aarond@xibm.StorTek.com (Aaron Dailey) writes:
>In article <1992Dec8.144629.17255@microware.com> adam@microware.com (Adam Goldberg) writes:
>...although many boards support more than 16MB of memory, none of them
>   (to my knowledge) have implemented a DMA system which is backward
>   compatible, and will work past the 16MB line.  I don't believe it is
>   possible.
>
>Actually it's possible, I just don't think anyone does it in a
>standard way.  We use a PC VLSI Technologies chipset for an embedded
>system we are building, which will support DMA over 16MB with some
>additional registers.  However, I doubt (pure speculation) that anyone
>else does this, or if they do if it's in a standard way.  Also, I
>don't think VLSI is a very popular chipset manufacturer.
>
Technology Power Enterprises does this on their boards. I've been using
their boards for quite a while with great results. And I'll agree that
VLSI isn't very popular but it doesn't mean they're not outstanding chips.
I believe they are slightly more expensive than others which limits their
use in todays cut-throat market. On the other hand, those who require
performance and reliability usually know beter than to buy on price alone.
I'm not sure if TPE is still using VLSI or Northport but either is a good
choice. 

From what I've seen on the net most of the problems people have
are with bottom-of-the-barrel clone boards that they got a real good
price on. It's a shame to see them get discouraged because they were 
burned by a weak system board. No where elese is the old addage "You
get what you pay for" more evident than in today's motherboard market.

John H. Wadsworth            BABSS           wadswort%babss.UUCP@cs.yale.edu
(800) 677-8549 voice    (203)481-0276 fax      {uunet,yale}!babss!wadswort
Newsgroups: comp.unix.pc-clone.32bit
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Organization: University of Helsinki
Date: Mon, 14 Dec 1992 23:12:44 GMT

In article <17543@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>In article <1992Dec11.150512.21282@texhrc.uucp> someone@Texaco.com (Larry D. Pyeatt) writes:
>>I recently saw an IBM clone with 32M RAM and 256K cache running OS2.  We
>>ran several benchmarks and it was blazingly fast whenever the program was
>>loaded in the lower 16M.  However, when the program was loaded in the 
>>uncacheable upper 16M, performance dropped to about 25% of what it was.
>>This had nothing to do with DMA.  We finally took out the upper 16M and
>>the machine now provides better average performance than when it had 32M.

First off, I can verify that this is true at least with some
motherboards: I've had reports of similar things happening, and when I
upgraded to 20MB I saw it myself.  The performance drop was more than an
order of magintude in the worst case (ie when a process got only pages
in the 16MB+ area, it slowed down *a lot*: dhrystone went from 12 secs
to two minutes). 

The problem seems to be caching: the 16MB+ area doesn't get cached at
all for some reason.  I've had reports of it being cahce-size dependent,
and that some motherboards need more than 64kB cache to handle the upper
memory areas.  I'm waiting for my 256kB cache to find out. 

>This reminds me of something the CDC mainframes used to do:  They had
>X amount of fast memory, Y amount of slow memory and Z amount of disk swap
>space.  They would only execute programs out of fast memory.  When fast
>memory started to fill up, they would swap out jobs/processes to slow
>memory.
>
>Likewise, when the slow memory filled up, jobs that had been hanging around
>in slow memory were swapped to disk, leaving more space for jobs being
>swapped out of fast memory.
>
>It seems that Linux and 386BSD people would be in an ideal spot to try this
>idea.  Yeah, it's using strange software to get around inferior hardware,
>but that is what swapping to disk is too.  (Otherwise, we would all have
>128 meg of ram instead of a swap area. :)
>
>So has anybody tried this?  Any comments on feasibility?

I haven't tried anything like that, and frankly, I don't want to.  The
PC architecture has it's problems as it is, and I don't really want to
add more cludges to the system just to get that extra bit of
performance.  I might have to change my attitude if it turns out that
the new cache won't help, but we'll see. 

As to feasability: why not? The natural thing to do would be to use them
as buffer cache, but on an AT architecure that also loses (DMA... 
Arggh).  It's not pretty though, and it would be terribly inconvenient
to try out (do an additional memory test to check which areas are
slower? The idle task could do it.  Hmm). 

		Linus
Xref: sparky comp.unix.pc-clone.32bit:849 comp.unix.sysv386:17523 comp.unix.bsd:10387 comp.os.linux:20997
From: hasty@netcom.com (Amancio Hasty Jr)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Subject: Re: ET4000/W32 and VESA VL-Bus
Date: 18 Dec 92 18:56:12 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <1992Dec18.095906.3950@Informatik.TU-Muenchen.DE> roell@informatik.tu-muenchen.de (Thomas Roell) writes:
>>I thought that since EGA boards have been using double ported DRAM to
>>avoid this?  Or are you saying 100MBs is for both ports?  I have noticed
>>some ads saying their S3 board uses double ported DRAM so are we to
>>assume that most are not?  If so then as you say this will instantly
>>destroy any speed a coprocessor can give as the only thing that matters
>>then is faster DRAM.  I am no expert (as is obvius to the experts by
>>now) but I am just trying to get this picture.  If ram access has always
>>got this refresh overhead (assuming a single port) then any board will
>>simply be limited by DRAM bandwidth.
>
>Yes, you are right, partially. Of course the serious graphics boards
>use all VRAM, which are dual ported RAMs specifically for graphics
>boards. They have a internal shift register for the screen refresh
>data and a random access port for the graphics engine. And of course
>those allow you to use the 100MB/sec (which was again just a sample
>number which seems to be realistic for the WD90C31) exclusively for
>the drawing operations. But the point was that somebody asked about
>the ET4000/W32, which is a DRAM based (and not VRAM based) solution.
>In my eyes, nothing justifies the usage of DRAMs for a graphics board if
>you want to use it for a GUI. The price difference is rather minor
>in those days.
>
>Also there are quite a number of S3 chips, which use EITHER VRAM or
>DRAM:
>
>	86C911		VRAM
>	86C924		VRAM
>	86C801		DRAM
>	86C805		DRAM
>	86C928		VRAM
>
>
>What I am saying is that for 1028x768 in 70Hz and 1280x1024 you should
>generally forget the DRAM based solutions. Even if they look good at
>benchmarks; most of these benchmarks used a 640x480 resolution,

All XS3 published benchmarks are run at 1024x768 clocked at higher
than 60 Hz. I obtained the results from netters because I don't
own a high resolution monitor. During candid, e-mail exchange I do
state my own benchmarks. In the future I will state the clock 
frequency and the resolution.

Amancio Hasty

>where the screen refresh only takes 25MB/sec, and the available
>bandwidth for graphics operations is quite the same as for VRAM based
>solutions. But if you use the DRAM based boards at 1024x768, 70Hz,
>you'll see the difference.
>
>- 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 ...


-- 
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail hasty@netcom.com	|  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Newsgroups: comp.unix.pc-clone.32bit