Subject: Re: *this* would make a very nice NetBSD machine
To: Tiffany Snyder <tiffany.snyder@gmail.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 08/14/2006 18:12:41
Tiffany Snyder wrote:
> Solaris on this would be awesome. I brought this very subject in one
> of the Open Solaris mailing lists a couple of months ago. There was no
> interest. It wasn't for this product specifically, but something
> similar to Sun's Niagara,
> http://www.razamicroelectronics.com/products/xlr.htm.

If someone dropped a box in my lap, they might be surprised at what
happened.  Then again, they might not. :-)

    -- Garrett
>
> Later,
>
> Tiffany.
>
> On 8/14/06, Garrett D'Amore <garrett_damore@tadpole.com> wrote:
>> Timo Schoeler wrote:
>> > thus Garrett D'Amore spake:
>> >> Timo Schoeler wrote:
>> >>> http://www.movidis.com/products/rev.asp
>> >>>
>> >>> 16 core MIPS CPU, ECC RAM, very low power design.
>> >>>
>> >>> or wait for PA Semi and their PowerPC-based PWFficient? :)
>> >>>
>> >>> cheers,
>> >>>
>> >>
>> >> I want one. :-)
>> >>
>> >> Just when you think MIPS is a dying architecture, news like this
>> comes
>> >> out...
>> >
>> > definitely. :)
>> >
>> > given the energy saving hype MIPS (and a few others) really have an
>> > advantage due to their focus on embedded CPUs... (no, i'm not against
>> > it -- as long as it saves the environment, almost anything can be
>> > legitimated; and 'cos energy is equivalent to $$$, even people that
>> > don't care a shit about the environment are 'forced' to save it :)
>> >
>>
>> I just sent a sales inquiry to their folks.
>>
>> One of my questions I asked them is whether they were interesting in
>> funding a port of Solaris to it.  I've been toying with the idea of
>> doing a Solaris MIPS64 for a while now....
>>
>> I hate to say it, but I think on a highly SMP box like this NetBSD will
>> perform poorly (at least compared to alternatives).
>>
>> If I had more energy, I might have considered trying to work NetBSD
>> kernel concurrency.  But I suspect that is a major quagmire anyway,
>> because fixing it requires such a huge code overhaul to introduce better
>> kernel threading and eliminate the Giant Lock.
>>
>> -- 
>> Garrett D'Amore, Principal Software Engineer
>> Tadpole Computer / Computing Technologies Division,
>> General Dynamics C4 Systems
>> http://www.tadpolecomputer.com/
>> Phone: 951 325-2134  Fax: 951 325-2191
>>
>>


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191