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>