Date: Fri, 9 Jan 1998 09:29:15 -0500 (EST) From: Jamie Bowden <jamie@itribe.net> To: John Peter DeVale <jdevale@ece.cmu.edu> Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <199801091427.JAA07552@gatekeeper.itribe.net> In-Reply-To: <Pine.OSF.3.96.980109085641.2182C-100000@skate.ece.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801091427.JAA07552>