[comp.os.minix] 386 dx vs. sx

kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/07/90)

Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
because the basic integer size is 32 bits instead of 16 bits.  (Assuming
that the clock speeds are the same, of course.)

On the other hand, the 386dx offers no basic advantage over the 386sx
for DOS (yech) systems.  (Check the benchmarks, paying attention to
clock speed.)

What is the situation with Bruce Evan's 386 Minix?  Is the DX a big win
over the SX?  Upgrading users want to know . . .

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh

kls30@duts.ccc.amdahl.com (Kent L Shephard) (12/07/90)

In article <28664@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
>because the basic integer size is 32 bits instead of 16 bits.  (Assuming

The basic integer size on the sx is exactly the same as the dx.  The diff.
between the two processors, for the umpteenth time is:

sx does 16 bit fetches to memory and can only access 16 meg of real mem.
dx does 32 bit fetches to memory and can access 4 gig of real mem.
Besides that the are the same internally and software CANNOT tell the
difference between the two.

>that the clock speeds are the same, of course.)
>
>On the other hand, the 386dx offers no basic advantage over the 386sx
                              ~~~~~~~~~~~~~~~~~~~~~~~~~
Wrong again.  All dx fetches to memory are 32 bit so a dx has faster
performance given the same clock speed for ANY type of memory transfer.
This is the only advantage in speed besides clock that you can get given
two systems with the same basic arch. (cached systems are another story)

>for DOS (yech) systems.  (Check the benchmarks, paying attention to
>clock speed.)
>
>What is the situation with Bruce Evan's 386 Minix?  Is the DX a big win
>over the SX?  Upgrading users want to know . . .
>
>-- 
>favourite oxymorons:   student athlete, military justice, mercy killing
>Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh


--
/*  -The opinions expressed are my own, not my employers.    */
/*      For I can only express my own opinions.              */
/*                                                           */
/*   Kent L. Shephard  : email - kls30@DUTS.ccc.amdahl.com   */

norsk@sequent.UUCP (Doug Thompson) (12/08/90)

In article <28664@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
>because the basic integer size is 32 bits instead of 16 bits.  (Assuming
>that the clock speeds are the same, of course.)

Allow me a small correction here. a 386DX and 386SX both have 32 bit 
integers when in protected mode. The only difference is the Bus Interface
Unit. The DX is 32 bits wide and SX is 16 bits wide. Similiar to the
mechanisms used on the 8086 (16 bit wide BIU) and the 8088 (8 bit wide BIU)
which are  both 16 bit CPUs.

>
>On the other hand, the 386dx offers no basic advantage over the 386sx
>for DOS (yech) systems.  (Check the benchmarks, paying attention to
>clock speed.)
>
>What is the situation with Bruce Evan's 386 Minix?  Is the DX a big win
>over the SX?  Upgrading users want to know . . .
>

In some cases, the SX machine is the only machine some people can
get, even if it is ONLY two or so hundred dollars less than
a DX based machine.

-- 
Douglas Thompson		UUCP: ..{tektronix,ogicse,uunet}!sequent!norsk
				Internet:	norsk@sequent.com
"The scientist builds to learn; the engineer learns in order to build."  
Fred Brooks

ken@dali.gatech.edu (Ken Seefried iii) (12/08/90)

In article <28664@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
>because the basic integer size is 32 bits instead of 16 bits.  (Assuming
>that the clock speeds are the same, of course.)

This is, of course, absolutely wrong...

All 386's (SX, DX or whatever) have 32-bit ints.  32-bit registers,
32-bit intra-segment pointers (is that the right phrase?), 32-bit
ALUs.  End of story.  *Memory fetches* are done in 16-bit quantities
in an SX...I assume thats where you lost track...

As far as `big win', I've never seen (on 16MHz, non-cached, ISA-bus
machines) a DX beat an SX by more than about 20% on CPU intensive
stuff.  Perhaps just different definitions of what `big win' means...

--
	ken seefried iii	"A sneer, a snarl, a whip that
	ken@dali.gatech.edu	 stings...these are a few of
				 my favorite things..."

kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/09/90)

In article <18330@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes:
>In article <28664@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>>Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
>>because the basic integer size is 32 bits instead of 16 bits.  (Assuming
>>that the clock speeds are the same, of course.)
>
>This is, of course, absolutely wrong...

You didn't read my statement.  Read it again.  I'll repeat it with the
implications you missed to make sure you understand.

Getting a 386dx (as opposed to a 386sx) is a big win for V.3 and V.4,
because the basic integer size is 32 bits.  IT IS NOT SUCH A BIG WIN FOR
A MS-DOS SYSTEM, WHERE THE BASIC INTEGER SIZE IS ONLY 16 BITS.  As a
matter of fact, if you compare MS-DOS benchmarks, like Landmark AT and
Norton SI, you will find that they are directly proportional to clock
speed for all machines from the '286 on up.  There is no advantage to
the 386dx over the 386sx for MS-DOS, because MS-DOS uses 16-bit
integers.

The size of the integer in bits that I was refering to was the size of
the integers in the OS running on the machine.  Read the first statement
again.  The phrase about 32-bit integers clearly refers to V.3 and V.4.

Hence my question:  Does Minix 386 use 32-bit integers?  If they do,
then getting a 386dx will be a big win for Minix 386.

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh

KPURCELL@liverpool.ac.uk (Kevin Purcell) (12/10/90)

On Sat, 8 Dec 90 21:36:31 GMT Kenneth J. Hendrickson (kjh@EDU.USC.POLLUX) said:

>In article <18330@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii)
> writes:

[clarification of original question]
>Hence my question:  Does Minix 386 use 32-bit integers?  If they do,
>then getting a 386dx will be a big win for Minix 386.
>
>--
>favourite oxymorons:   student athlete, military justice, mercy killing
>Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh

I would like to extend this question a little further and in a slightly
different direction. BTW, this question was recently discused in
alt.folklore.computer (!) and comp.sys.unix.wizards.

One thing which does limit 'real' unicies on 386 'IBM-PC' machines is
the I/O, mostly to disk. This is most true when you run them as multi-user
systems. Although their raw processing power is much bigger than, say,
a PDP 11/70 or even a VAX 780, their I/O bandwidth is appallingly bad. They
were designed to run MSDOS as a single user systems and this shows when you
try to run anything a bit more demanding.

So from this point of view, is the how does the difference in bus bandwidth
of a dx compared to an sx affect the overall performance of a multi-user
system. (Minix neophyte question -- does Minix swap in the 386 versions?)

And a second question -- how does a cache on a 386dx affect the performance
of Minix relative to a uncached 386dx. I have heard it said that (again
with a real Unix system on a 386) a 20MHz cached 386dx will easily beat an
uncached 25MHz 386dx.

Finally, what affect is the hard disk system (disk + controller + driver)
performance have on Minix. Are you better buying a better disk and controller
and settling for a 386sx?

All of these questions should be answered for the two cases that most people
encounter -- the single-user case and the multi-user case.

Thanks for listening,
Kevin
                                                      _   .
Kevin Purcell          | kpurcell@liverpool.ac.uk   _/ \ / \   kgp@cxa.dl.ac.uk
Surface Science,       |                           /----/^^^\
Liverpool University   | There is now a damm fine /TWIN PEAKS\ email discussion
Liverpool L69 3BX, UK  | list for TPers. Mail me /    /       \ for details.

hp48sx@wuarchive.wustl.edu (HP48SX Archive Maintainer) (12/10/90)

I am not sure if the 386dx vs. 386sx discussion belongs to this
newsgroup. For me it is (almost) noise. But anyway, I would like to know
what are the differences between a standard 80386 and the 386dx ?

I am a Motorola 680x0 user since 1985, and has never programmed the
awfull 16bit 80x86 processor i Machine language. But I understand that
it is now possible to do some REAL programming on it now :-)

Please direct all information to me. Flames are also welcome, I will
forward them to dev/null. No flamewar on this list please.

-- 
*******************************************************
Povl H. Pedersen             hp48sx@wuarchive.wustl.edu
HP48sx archive maintainer

bad@flatlin.ka.sub.org (Christoph Badura) (12/11/90)

In <38578@nigel.ee.udel.edu> KPURCELL@liverpool.ac.uk (Kevin Purcell) writes:

>So from this point of view, is the how does the difference in bus bandwidth
>of a dx compared to an sx affect the overall performance of a multi-user
>system.

Most probably not much. With normal MFM, RLL, and ESDI controllers the
cpu has to copy the data to and from the controllers on-board buffer.
With an AT-style backplane you get a 16-bit data path to the
controller in the BEST CASE. Because of some critical signal timing
constraints you may not get a 16-bit transfer to/from the controller,
*even* if the controller supports it. Furthermore you may suffer some
wait states when accessing the controller. In this case a faster cpu
won't give you more performance. It normally doesn't either since the
IO-bus speed is fixed at 8 or 10 MHz.

Installing a busmastering controller such as the Adaptec AHA154x or
Western Digital WD7000FASST SCSI controllers will gives you a *real*
performance boost and it will free a lot of cpu cycles for real work.
These controllers have a Transferrate between main memory an
controller of 5 MByte/sec and (depending on the motherboard) higher.
My disk throughput raised from somewhere around 90KB/sec with a 1:1
interleave MFM controller to about 300-400KB/sec with an AHA1542. This
is a 16MHz SX running Xenix.

>And a second question -- how does a cache on a 386dx affect the performance
>of Minix relative to a uncached 386dx. I have heard it said that (again
>with a real Unix system on a 386) a 20MHz cached 386dx will easily beat an
>uncached 25MHz 386dx.

That's right. In fact my zero wait-state SX compares favourable
against 20MHz DXen without cache (and normally some wait states) even
with the MFM controller.

>Finally, what affect is the hard disk system (disk + controller + driver)
>performance have on Minix. Are you better buying a better disk and controller
>and settling for a 386sx?

While faster disks give higher throughput, the real bottleneck is in
the file system code. The controllers have an upper limit on the
number of requests per second they can handle. Increasing the request
size has a dramatic effect on disk performancs. Typically, doubling the
request size doubles the throughput. So if someone has some patches to
FS, to read multiple continguos blocks in one chunk... hint, hint.

>All of these questions should be answered for the two cases that most people
>encounter -- the single-user case and the multi-user case.

Well, it depends. 1/2 :-)

I think currently FS is the main limiting factor regarding disk bandwith.


	chris
-- 
SVR4 is an adventure; if you win		 |	Christoph Badura 
 you find you're playing VMS. -- Richard O'Keefe |	bad@flatlin.ka.sub.org

kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/12/90)

In article <1705@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
>In <38578@nigel.ee.udel.edu> KPURCELL@liverpool.ac.uk (Kevin Purcell) writes:
>Installing a busmastering controller such as the Adaptec AHA154x or
>Western Digital WD7000FASST SCSI controllers will gives you a *real*
>performance boost

Are device drivers yet available for these disk controllers?

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh

KPURCELL@liverpool.ac.uk (Kevin Purcell) (12/13/90)

On Tue, 11 Dec 90 18:40:48 GMT Kenneth J. Hendrickson (kjh@EDU.USC.POLLUX) said:

>In article <1705@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura)
> writes:
>>In <38578@nigel.ee.udel.edu> KPURCELL@liverpool.ac.uk (Kevin Purcell) writes:
>>Installing a busmastering controller such as the Adaptec AHA154x or
>>Western Digital WD7000FASST SCSI controllers will gives you a *real*
>>performance boost

I didn't write this -- please be more careful with your attributions.

>
>Are device drivers yet available for these disk controllers?
>
>--
>favourite oxymorons:   student athlete, military justice, mercy killing
>Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh
                                                      _   .
Kevin Purcell          | kpurcell@liverpool.ac.uk   _/ \ / \   kgp@cxa.dl.ac.uk
Surface Science,       |                           /----/^^^\
Liverpool University   | There is now a damm fine /TWIN PEAKS\ email discussion
Liverpool L69 3BX, UK  | list for TPers. Mail me /    /       \ for details.

ITOC100@indycms.iupui.edu (James Nelson) (01/07/91)

Ok, I've seen the comparisons of the 386 dx vs. the sx, but what (if any
is the difference between the dx and a straight 386?

I thought that the only difference between the sx and a straight 386 was
that the sx does 16 bit memory fetches and the 386 does 32 bit.  Now the
dx does 32 bit memory fetches...what am I missing?

Jim Nelson
jnelson@indymed.iupui.edu
itoc100@indycms.iupui.edu
itoc100@indyvax.iupui.edu

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/07/91)

Intel just renamed the 386 to 386dx when they introduced the 386sx.

C.v.W.

dpi@loft386.uucp (Doug Ingraham) (01/09/91)

In article <40867@nigel.ee.udel.edu>, ITOC100@indycms.iupui.edu (James Nelson) writes:
> Ok, I've seen the comparisons of the 386 dx vs. the sx, but what (if any
> is the difference between the dx and a straight 386?
> 
The dx designation was added when the sx part was released to distinguish
between the parts.  By accident this was also the d step part.  There is
no difference between a I80386 and an I80386dx except for the stepping
level and package labeling.

-- 
Doug Ingraham (SysAdmin)
Lofty Pursuits (Public Access for Rapid City SD USA)
bigtex!loft386!dpi
uunet!loft386!dpi

kls30@duts.ccc.amdahl.com (Kent L Shephard) (01/10/91)

In article <40867@nigel.ee.udel.edu> ITOC100@indycms.iupui.edu (James Nelson) writes:
>Ok, I've seen the comparisons of the 386 dx vs. the sx, but what (if any
>is the difference between the dx and a straight 386?
                               ~~~~~~~~~~~~~~~~~~~~~
A dx is a plain old 386 sx has 16bit  data bus and 24 adress lines.
>
>I thought that the only difference between the sx and a straight 386 was
>that the sx does 16 bit memory fetches and the 386 does 32 bit.  Now the
>dx does 32 bit memory fetches...what am I missing?

I don't know what are you missing?  sx=16bit, dx=32bit.
>
>Jim Nelson
>jnelson@indymed.iupui.edu
>itoc100@indycms.iupui.edu
>itoc100@indyvax.iupui.edu


--
/*  -The opinions expressed are my own, not my employers.    */
/*      For I can only express my own opinions.              */
/*                                                           */
/*   Kent L. Shephard  : email - kls30@DUTS.ccc.amdahl.com   */