Date: Sun, 12 Nov 1995 01:30:50 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511120730.BAA25976@brasil.moneng.mei.com> In-Reply-To: <14486.816158986@time.cdrom.com> from "Jordan K. Hubbard" at Nov 11, 95 10:49:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Notes: > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > loaded. Here is how it was described to me: You will be doing > > something (like skimming news articles in trn or tin) that is > > This one really needs some additional context. Suffice it to say that > I've not experienced such behavior myself, and that's about all one > can say with a fairly subjective report like this. That's not to say > that it's totally lacking in validity, but consider what you yourself > would do with a user report that "the system seemed slow." You'd > naturally want to know how many processes were running, what version > of the OS was being used, that kind of thing. In this instance you > say that "something starts up" but you don't say what it is. Doing > Tape I/O is something that's traditionally had a really bad impact > on the performance of *every* UNIX variant I've ever seen, so if you're > saying that the event in question is the operator starting a full dump > from the console, well, "duh!" :-) No, I'm not flaming you or shooting > the messenger, I'm just saying that there are always two categories > of bug reports: Ones that give you enough information to go on that > you actually have a hope of doing something about them and others > more the nature of "Your system sucks, dudes! Make it better!" Specific example of a system grinding to a halt in an "unexpected" manner: System, ASUS PCI/I P54*something Pentium 100 motherboard, a Rod Grimes board, dual NCR 810 controllers, 2x ST-12550N 2G Barracuda SCSI drives, 2x Micropolis 4G SCSI drives, 64MB RAM. FreeBSD 2.0.5R. Doing "newfs -b 4096 -f 512 /dev/sd10s1e" took the system down into the ground as far as I was concerned. I figured it would take a while to newfs a 4G drive, so I went to next console, logged in, noticed it was very sluggish, and tried to do a newfs on another drive. It worked but everything was extreeeeeeemely slow. I haven't looked recently to see if this still "happens". > Tell your ISPs that not all drives are created equal and that they > should find a winning combination before blaming the OS. Also mention > that today's winning combo may not necessarily be tomorrow's. I had > great luck with the GP drives until Quantum's quality control suddenly > took an unexplained nose-dive. As in all things, you just gotta keep > your ears open and be willing to investigate problems as thoroughly > as possible before pointing any fingers - this stuff isn't that simple > anymore! This is very true. news.sol.net runs a dozen drives on three SCSI channels and has performed _great_!! Aside from some nightmares configuring the PCI stuff (I still owe Stefan some debugging output), this is one area where FreeBSD excels. I _have_ seen cases where a particular controller and drive did not like each other (2.0.5R/NCR-810/ST-15150N, etc) but this is the exception rather than the rule, and even then, one can generally upgrade to more recent drivers and fix the problem. Just mild commentary, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511120730.BAA25976>