From owner-freebsd-hackers Fri Jan 9 07:02:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA04890 for hackers-outgoing; Fri, 9 Jan 1998 07:02:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA04855 for ; Fri, 9 Jan 1998 07:02:14 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199801091427.JAA07552@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Fri, 9 Jan 1998 09:29:15 -0500 (EST) From: Jamie Bowden To: John Peter DeVale cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Fri, 9 Jan 1998, John Peter DeVale wrote: > On Fri, 9 Jan 1998, Jamie Bowden wrote: > Well, the benchmarks are not about performance as we really think of it - > as in faster is better. These benchmarks are about how well the system > stands up to rocks beting thrown at it. Meaning, does the system casue > the process to abort (ungracefully) when it should return an error code > and terminate the process in a controlled fashion. In some systems, the > entire OS can be crashed via user code - most notably Irix 6.2 or 6.3, or > whatever the latest irix is. > > Network performance isn't an issue, except since I didn't have a freeBSD > disc, I needed the network up to ftp the install binaries. > > So, as far as that goes, freeBSD was, to my surprise, one of the worst > offenders. Linux, on the other hand, did very well in our tests. I have > given it alot of thought, and I think I know why this is. I think that > the average freeBSD user is in general a more advanced computer person, > who knows how to operate a system, and programs well (excluding you of > course on the last item :) ). Thus when her/his program aborts > catastrophically, they debug it, and feel stupid that they did something > like pass NULL to atoi (which actually causes an abort in freeBSD). The > linux users, on the other hand, can't figure it out, or bitch and whine, > and as a result, the system call is fixed to return an error code instead > of an abort. Since you have to know about these bugs to fix them, it > seems likely that freeBSD users/programmers just do fewer stupid things. > > So, now that I have explained what the benchmarks are, you may be saying > to yourself, that sounds really stupid. You wouldn't be the first. While > it would be nice if the OS people fixed all these things, keep in mind > that the real target is thrid party libraries to be used in > mission-critical systems that are supposed to be fault tolerant. Meaning > they degrade gracefully, rather than crash the process. Operating systems > just provided us with a rich set of different objects with a common > interface to test on. Although some people here in the fault tolerant > computing group think that they should fix every possible bug, this is > ludicrous. With the exception of the OS's we tested that claimed to be > fault tolerant real time operating systems, there is no payoff for the > vendor to jump through hoops to get all of these robustness problems > fixed. It might do some good for them to fix the easy ones though. For > instance, many many problems are caused by nulls getting passed in to > system calls. Sure, the programmer should test this out, but they still > creep in, especially in complex programs. If you could fix a large amount > of these problems just by adding in null checks to the system calls, it > would be pretty easy, and inexpensive in terms of cpu overhead. > > In any case, you are welcome to check out bang, or not. Since you have > been so helpful I just wanted to give you the opportunity to check it out > if you wanted to. > > thanks again, > > John > > I have cc'd this to freebsd-hackers because I think quite a few of them might be very interested in what you are doing. I could also be very wrong. -- Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle)