Date: Wed, 14 Jul 1999 19:42:53 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Terry Lambert" <tlambert@primenet.com> Cc: <Doug@gorean.org>, <scrappy@hub.org>, <beyssac@enst.fr>, <chat@FreeBSD.ORG> Subject: RE: Known MMAP() race conditions ... ? Message-ID: <000001bece6b$bcf66740$021d85d1@youwant.to> In-Reply-To: <199907150210.TAA11380@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Large RAID arrays. > > You mean software RAID, right? SCSI cables don't care what they > are connected to. Hmmm. I could do a SCSI commercial: Would that that were true. But unfortunately, a lot of hardware RAID controllers do care what driver they are talking to. And NT tends to get premium effort from the manufacturer. I think this same issue with Linux-versus-NT had a lot to do with the recent benchmark disasters. > > Applications requiring large numbers of threads. > > Balk. "Rodents of unusual size? I don't believe they exist...". Sadly, there are some problems that are very hard to solve any other way. Especially when licensing requirements get in the way. I'll give you a contrived example, since I'm not at liberty to go into details on the specifics of real examples. Suppose I might potentially have to do 3,000 'gethostbyname's at the same time in a commercial product. On NT, I can create 3,000 threads and call 'gethostbyname' in every one. Not pretty, but it works. On FreeBSD, I'm basically screwed. I'd have to write me own resolver library to do the job. Licensing problems prevent me from using pretty much every nice resolver library out there. > > There's nothing I know of in any UNIX that comes close to NT's > > completion ports for efficient network I/O. > > I want whatever you're smoking confiscated. > > Completion ports are no more, and no less, than VMS AST's. Just > like aio* in FreeBSD, and much of the POSIX crap that's passing > for standards these days. > > They may make it easier to code, by calling your callbacks, but > the idea that network buffers should be in user space instead of > on the kernel side of the protection domain barrier is just > plain nuts. They're on both sides in every implementation. It's just a matter of when the borders get crossed. > > I won't bother listing NT's problems -- we all know them. But > it doesn't do > > us any good to ignore its strengths. > > The anti-NT sentiment wasn't mine. On equivalent hardware, it > handily beats FreeBSD's SMB server performance (one of the major > impetus' for the work Kirk is now doing). I've address some of > that in another posting, from my experience optimizing a similar > hosted server for NetWare on Solaris, UnixWare, Dell UNIX, VMS, > and AIX. The problems are correctable, but require work to be > done, and code to be committed. And that's good, because this kind of comparison is what spurs development. Embarassing benchmark results have done a lot for Linux's development lately. :) DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001bece6b$bcf66740$021d85d1>