Subject: Recommendations on mother boards?

From: Douglas Bates <[email-masked]>
Date: Thu, 8 Aug 96 05:53 CDT

I will soon be purchasing a custom system to run Debian GNU/Linux.  Since
I must get bids from different vendors, I might as well give detailed
specifications if that will enhance the performance with Linux.

Does anyone have comments on specific Pentium Pro motherboards?

For example, Bruce Perens mentioned on this list some time ago that
the combination of the IDE controller in the Triton chipset with an
EIDE drive is as fast as fast, wide SCSI.  I found that the system I
was using had the Triton chipset and enabled the Triton-specific
optimizations in the kernel.  The results were very pleasing.

Are there similar things to look for when purchasing a motherboard today?

Please e-mail me and I will summarize to the list.

-- 
Douglas Bates                            [email-masked]
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/

---

From: Sherwood Botsford <[email-masked]>
Date: Fri, 9 Aug 1996 10:29:17 -0600

> optimizations in the kernel.  The results were very pleasing.
That would depend on how hard the disk subsystem is being hammered.
SCSI's advantage is that it can handle multiple outstanding requests at
the same time, while EIDE has to wait for one to complete before it can
start a second one.  Under a single tasking OS, this is ok, but if you
have a a hundred or so user processes fighting over the disk, this
becomes a losing proposition.  Check out the results when you have a
fast/wide scsi 2 drive on a good controller, with a a few meg of cache
on the drive.  (This allows the drive to start being clever and resort
the queue'd I/O's for fastest return.  E.g. If the head is on cylinder
7, and it gets a read request for cylinder 2000, and cylinder 500, it
will do the 500 on the way to the one for 2000.)

For a personal workstation, I don't think you would notice the
difference, until you are doing enough that you have to swap.  Pushing
one process out to disk while reading a new one off the disk puts
strain on the disk...
> Please e-mail me and I will summarize to the list.

Sherwood Botsford |Unsolicited email that advertises commercial 
Physics Dept      |activities will consitute a request for 
U of Alberta      |spellchecking of all words of less than three 
Edmonton, AB,     |characters.  I charge $US500 for this service. 
T6G 2J1		  |There is no warranty of correctness of this service.

---

From: [email-masked] (Wayne Schlitt)
Date: Fri, 9 Aug 1996 18:50:12 -0500

> > EIDE drive is as fast as fast, wide SCSI. 
>
> start a second one.

SCSI can handle multiple request to _different_ devices on the same
SCSI bus, but I don't think you can have multiple requests to the same
device.

EIDE, on the other hand, can only have one device active at a given
time.  Considering that you can only have two devices, this isn't too
bad, but if one of them is something slow like a tape drive or a
CDROM, it will really slow down a hard disk.

>                                              with a a few meg of cache

This is known as elevator seeking and should be done at the OS level.
The order that data is written out is very important for data
reliability, and for this reason, I don't think any hard disk change
the order of the writes.  

The really big problem that IDE had that EIDE fixed was that IDE
couldn't do DMA, so the OS had to move each byte from the disk drive.
On the other hand, SCSI's command overhead can be significant, often
adding up to 10ms to the simplest command.  

I would expect that if you only have one disk per EIDE controller, you
will significantly outperform a single SCSI bus with two disks on it.

-wayne

---

From: Sherwood Botsford <[email-masked]>
Date: Tue, 13 Aug 1996 11:36:17 -0600

> SCSI bus, but I don't think you can have multiple requests to the same

Yup, it can.  One of the parameters exchanged on start is how many
requests the device can queue.  Typically queues range from 16 to 50.
But don't ask me to back that up -- top of hte head number.

This is one of the big differences between SCSI 1 and 2.  That and the
disconnect/reconnect feature. (Don't *ever* buy a scsi 1 tape drive.
Everything stops when you rewind the tape.)

> reliability, and for this reason, I don't think any hard disk change

There are several different algolrithms for doing this.  Elevator seek
is the simplest of them.  Some put a higher priority on reads over
writes.  Some re-priortize the queue so that requests that have been
outstanding for a while get bumped up the queue.  

I agree that you can do this in the OS, but I don't think that it
*should* be done in the OS.
0.	In general smarts should be at the point they are used. We had a
VAX that was about as speedy as a 12 MHz 286 with 287 co-processor.
However, that vax could handle 8 simultaneous 19 KB terminal lines.
How?  Smart serial cards.  
	The CPU should do those tasks that are either too general for
dedicated hardware, or that don't happen often enough to take up much
time.
1.	The OS shouldn't have to care about the layout of the disk.
2.	I don't understand why the order matters for reliability --
unless you're talking about power failures.  This is a low order failure
mode -- which is why you do backups -- for those rare occasions when the
disk does lose a file when the lights go out.  The disk is smart enough
to recognize that a new request to write out sector 12345 makes the
previous request to write out sector 12345 invalid.
3.	The kernel of any unixen caches metadata for most of the file
system for long periods of time.  This is the whole point of the sync
daemon -- to flush this out to disk.

---

From: Rob Browning <[email-masked]>
Date: 13 Aug 1996 19:19:16 -0500

> 1.	The OS shouldn't have to care about the layout of the disk.

Not trying to start a flame war here, but if the overhead to the cpu
is minimal, which I would guess it is for seek algorithms, you are
often better off doing it with the cpu.  Mainly because changing the
algorithms, fixing bugs, trying out new approaches, etc. can happen
with a simple kernel recompile, and improvment's in CPU speed (which
happen all the time, as opposed to the somewhat slower embedded
controller market) immediately translate to improvements in algorithm
speed.  Now if the disks just had some flash ROM and a 386 (or
equivalent that gcc knows about) on board, things might be different.
Either that or a couple of cheap 386's on the motherboard for stuff
like this...

I'm mostly just speculating.  I don't know that much about drive
hardware.

--
Rob

---

From: Kevin M Bealer <[email-masked]>
Date: Tue, 13 Aug 1996 20:51:20 -0400 (EDT)

> outstanding for a while get bumped up the queue.  

Linux currently uses (accord. to the kernel lists) something
called sawtooth ordering.  This means the head moves in the same
direction until no more is left to read in that direction, then
does the same in the other direction... This provides more
"fairness" ie applications with data at the extreme ends of the
disk don't stall for a long time.

> However, that vax could handle 8 simultaneous 19 KB terminal lines.

I agree for most hardware, but some issues of hard drive usage,
ie reading ahead, really should have support, not only in the
kernel but in the application, for best performance.  The
application knows more about it's usage patterns, which could
help in speeding up hardware.  (for example, "file" only reads a
small chunk of a file, but grep always scans the entire file.)

> previous request to write out sector 12345 invalid.

The reasoning is that the filesystem should be in an
"inconsistent" state as little as possible. (ideally...)  This
is for power failures, kernel oops'es, etc.

> T6G 2J1		  |There is no warranty of correctness of this service. 

I think the OS's job should be efficiency, reliability, etc. 
Hardware is nice... but doing it in software is cheaper.  If
Linux can do well on cheap flaky hardware, more power to it.

[email-masked]/GNU__1.1___Linux__2.0.11___
    THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP
This otherwise unremarkable language is distinguished by the
absence of an "S" in its character set; users must substitute
"TH".  LITHP is said to be useful in protheththing lithtth.

---

From: [email-masked] (Bruce Perens)
Date: Wed, 14 Aug 96 11:15 PDT

> *should* be done in the OS.

Disks should serve filesystems, not raw blocks. There have been attempts
at this, but nobody's had a commercial success.

	Bruce
--
       Clinton isn't perfect, but I like him a lot more than Dole.
            Please register to vote, and vote for Democrats.
Bruce Perens AB6YM          [email-masked]            http://www.hams.com/