Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Apr 2000 11:28:17 +0930
From:      Greg Lehey <grog@lemis.com>
To:        Lanny Baron <lnb@freedomtc.com>
Cc:        Noemie Buzaglo <nbuzaglo@mrs.com>, questions@FreeBSD.ORG
Subject:   Re: SMP & RAID
Message-ID:  <20000425112817.B26934@freebie.lemis.com>
In-Reply-To: <XFMail.000424082520.lnb@freebsdsystems.com>
References:  <20000424181548.E12676@freebie.lemis.com> <XFMail.000424082520.lnb@freebsdsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 24 April 2000 at  8:25:20 -0400, Lanny Baron wrote:
> On 24-Apr-00 Greg Lehey wrote:
>> On Monday, 24 April 2000 at  2:46:26 -0400, Lanny Baron wrote:
>>> On 24-Apr-00 Greg Lehey wrote:
>>>> On Sunday, 23 April 2000 at  2:27:42 -0400, Lanny Baron wrote:
>>>>> Hello,
>>>>> Can I get some information with respect to SNP and how well FreeBSD can
>>>>> handle up to 8 processors.
>>>>
>>>> You mean SMP (symmetrical multiprocessing)?  It depends on what you
>>>> want to do.  The big limitation is the giant kernel lock which only
>>>> allows one processor to run in kernel mode at any one time.  Depending
>>>> on your application, this may make no difference at all, or it may
>>>> completely bog it down.
>>>>
>>>>> Would anyone know what RAID cards are supported.
>>>>
>>>> Take a look at the release notes, for example
>>>> http://www.freebsd.org/releases/4.0R/notes.html.
>>>>
>>>>> Someone sent me mail saying that only Vinum will work.
>>>>
>>>> Don't rely on "someone".
>>>
>>> Yes sorry it is SMP. Typo.
>>> As for what type of application might require multiple cpu's, I
>>> would think large database applications.
>>
>> We've done some comparisons with Solaris in this area recently.  They
>> show that we have a long way to go to catch up with Solaris, and we're
>> planning to do some work on it.  At the moment, I wouldn't recommend
>> FreeBSD SMP for database applications.
>>
>>> I know for a fact that a certain company with very large database
>>> bogs the entire network down for them. They run AIX and have several
>>> AS400's. A question then arises as to the claims of company's that
>>> sell systems and offer up to 8 CPU's. If FreeBSD cannot utilize the
>>> processing power, how can Linux?
>>
>> As a followup to the Mindcraft benchmarks, Linux has given more
>> attention to kernel locking than we have.  Don't count on them being
>> behind us.
>>
>>> This Kernel lock you speak of, is there anyway around it?
>>
>> Sure, it's a SMOP (Simple Matter Of Programming).  It took Sun about 5
>> years to get where they are now.  Don't expect us to be any better.
>
> I fail to understand why FreeBSD would not want to pursue large
> corporate users. If it is what you say (SMOP..) then why doesn't one
> of the programmers for FreeBSD get SMP up to par with other systems?

This was supposed to be ironical.  It's a lot of work, as should be
evident by the fact that it took Sun 5 years with a large team of
programmers.

> The answer provided does not demonstrate FreeBSD as being a
> commercially viable solution against other systems, which is
> contrary to what we believe. To be blunt, sucks.

Well, we can discuss the terminology but yes, we're not happy about it
either.

> Greg, as you are not only a genius in his own right, you are a lover
> of FreeBSD! AS the saying goes "if it's not broken, BREAK it and fix
> it"

I wouldn't go along with that one.

> There must be some secret here, if MS is using FBSD for hotmail and
> Yahoo! is using it for web. One processor to deliver all that?

Well, per system.  Each of these companies has several thousand
machines.

Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000425112817.B26934>