Date: Wed, 6 Mar 1996 13:41:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, gpalmer@FreeBSD.ORG, jeff@tad.cetlink.net, questions@FreeBSD.ORG Subject: Re: TCP Tuning? Message-ID: <199603062041.NAA11774@phaeton.artisoft.com> In-Reply-To: <199603061829.TAA08790@labinfo.iet.unipi.it> from "Luigi Rizzo" at Mar 6, 96 07:29:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Just for the records... There are PCI-based ne2000 clones, which
> > > sell for approx US$60 here. Programmed I/O on the PCI bus should not be
> > > slow at all.
> >
> > Unless you compare it to DMA I/O on the same bus... 8-).
>
> Unless you compare prices...
>
> As I just said in reply to Garret's message, it might be a 5-10% CPU
> overhead, which is perfectly tolerable for a board which costs
> perhaps half as much. Not to mention the fact that in some countries
> some pieces of hardware are simply not available.
>
> On this list there are often strong statements against certain pieces
> of hardware just because they don't have top performance, totally
> ignoring the price factor and some technical issues.
My strong comments about hardware are *always* motivated by technical
issues, with performance being second, and price being third. It's
possible to pick other selection criteria ordering for price/performance,
but it my book, it's whether or not it will work that is the most
important issue.
> IMHO, this is a bad thing, because people believes them blindly,
> often ending up buying SCSI disks (because "IDE sucks"), with cheap
> ISA-based SCSI controllers, or, worse, ISA SCSI controller with an
> on-board 4MB used as a cache (so that often they end up doing
> programmed I/O to read from the controller's cache!)
This is a performance issue -- like our discussion of the NE2000
clones.
SCSI is better than IDE for technical reasons. If your primary
concern isn't technical, then be prepared to sweat out your install
with a "high performance but technically abyssmal" machine. At the
very worst, be prepared to use a a low performance, but technically
useful machine to help you sweat out your problems.
It is no cooincidence that the boot blocks do not support LBA, and
that IDE has problems that haven't been scrupulously worked around,
like on other OS's, or that ATAPI IDE CDROM's don't work well for
drives that are "barely out of spec".
It's no coincidence that for the only systems where Bad144 is useful,
the replacement sectors are (more often than not) past the 1024 cylinder
boundry, making large areas of the disk unusable. Like every WD1007
disk (and where besides ESDI or MFM is Bad144 useful????).
If you want to use crud hardware, you have to prepared baby it.
As to the performance issues, well, *after* the technical issues are
solved, then you have the leisure to diddle around with tradeoffs
between price and performance.
It just seemed to me that "Programmed I/O on the PCI bus should not be
slow at all" was a *very* subjective statement, and was entirely too
relative for me to not call you on it. 8-).
> About IDE drives: I agree that they might not be the best approach
> to fast file I/O, but this is what I get on a P133/32MB ram with
> a WDC AC21000H 1GB IDE disk:
>
> diani: {21} iozone 128 8192
> Writing the 128 Megabyte file, 'iozone.tmp'...32.101562 seconds
> Reading the file...30.429688 seconds
>
> IOZONE performance measurements:
> 4181034 bytes/second for writing the file
> 4410749 bytes/second for reading the file
>
> Sure, probably the system is more loaded than a SCSI thing:
>
> Cpu states: 0.4% user, 0.0% nice, 33.9% system, 38.5% interrupt, 27.2% idle
> Memory: 13M Act 1748K Inact 2032K Wired 80K Free
>
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 589 root -6 0 240K 548K sleep 0:02 53.23% 11.79% iozone
>
> but the savings on the SCSI stuff almost get me 16MB RAM. For a
> personal workstation, and if I am on a budget, this is the way I would
> go.
You are an engineer. It is expected that you will buy an IDE controller
that does its geometry handling in hardware rather than in BIOS, or
that you will know how to properly pound the software into the machine
despite it being the second drive and the install being buggered, or
handle the use of OnTrack or some other MBR-based TSR that does LBA
translation to get around the fact that IDE using standard INT 13
interfaces is limited to 512M.
And it's expected that if you have to use Bad144, you have the ability
to realize you need to split the drive into multiple extents so that
the boot partition is entirely below the 1024 Cylinder boundry so the
second stage boot can access the relocation sectors.
But realize that you are an uncommon individual, and that as such, the
recommendations you make will require the same efforts of less educated
or less capable, or simply less *patient*, people, and that use of
cruddy hardware is an easy way to get turned off about FreeBSD.
It is *important*, IMO, to *first* make recommendations that cause the
software to be easily usable -- technical recommendations based on
driver avilability and existing software workarounds, etc. -- and THEN
worry about making speed vs. budget trade-offs, once the "it works, and
it works easily" constraint has been satisfied.
Like you, I *do* own some bitch-to-install-but-fast-and-cheap hardware;
I just don't expect "Joe Average User" to be able to get over the
"bitch-to-install" barrier to entry... I expect him to say "screw
this" and install Linux instead (since Linux has taken pains to
work with marginal-and-below hardware).
I am not going to buy *more* crappy hardware and beg/cajole/steal
documentation from vendors whose first line support people don't even
know what chips their hardware uses. It's just not worth it to me to
own crappy hardware soley to compete with Linux in the "ability to be
installed and run like a pig on crappy hardware" category.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603062041.NAA11774>