Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?000001bece6b$bcf66740$021d85d1>