Activate second CPU
Michael Klessmann
SMP license ?
Best regards
Michael Klessmann
Tony Lawrence
> What do i have to do to activate a second CPU ? Is the only way to buy an
> SMP license ?
Ayup.
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Bob Meyers
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:3C592C33...@pcunix.com...
> Michael Klessmann wrote:
>
> > What do i have to do to activate a second CPU ? Is the only way to buy
an
> > SMP license ?
>
> Ayup.
And it is so expensive you could just about go out and build a decent linux
server for the money. You might want to ask others in this group if it is
going to improve things much. Most of my customers have database
applications and I have never felt it was worth the money. I am sure others
in here will disagree. I think the money is better spent getting a fast
primary CPU and good hard disks.
Robert Steinmetz
Bob Meyers wrote:
Solaris x86 handles multiple CPU's well, it's close to free but software and
hardware are limited. If your software works it may be a good choice.
--
Robert Steinmetz AIA
Principal
Steinmetz & Associates
Bob Meyers
"Robert Steinmetz" <r...@steinmetznet.com> wrote in message
news:3C59A5F8...@steinmetznet.com...
> Solaris x86 handles multiple CPU's well, it's close to free but software
and
> hardware are limited. If your software works it may be a good choice.
Yeah, and MS Windows NT and W2K server come with a 2-CPU license as a
standard feature - no extra cost until you go over 2 CPU's. I wonder how M$
pulled that deal off so cheaply compared to SCO.
Tony Lawrence
But it doesn't matter a bit how well designed the SMP is if the primary
load doesn't tax the capacities of one cpu.
If sar isn't showing a pegged cpu at least part of the time, there isn't
going to be much sense in spending the money on the hardware or the license.
Bill Vermillion
<r...@Steinmetznet.com> wrote:
>Bob Meyers wrote:
>
>> "Tony Lawrence" <to...@pcunix.com> wrote in message
>> news:3C592C33...@pcunix.com...
>>
>> > Michael Klessmann wrote:
>> >
>> > > What do i have to do to activate a second CPU ? Is the only
>> > > way to buy an SMP license ?
>> >
>> > Ayup.
>> And it is so expensive you could just about go out and build a
>> decent linux server for the money. You might want to ask others
>> in this group if it is going to improve things much. Most of my
>> customers have database applications and I have never felt it was
>> worth the money. I am sure others in here will disagree. I think
>> the money is better spent getting a fast primary CPU and good
>> hard disks.
>Solaris x86 handles multiple CPU's well, it's close to free but
>software and hardware are limited. If your software works it may be
>a good choice.
Just be aware the Sun has just announced there will be no version
of Solaris 9 for the iNTEL platform - at least for now.
They indicated that they may bring out an iNTEL port in the future
but that is an unknow. They stopped the free downloads about 2
weeks ago when they made the announcment of dropping the iNTEL
platform for the Solaris 9. You can still get Solaris 8 on CD
media.
media.
--
Bill Vermillion - bv @ wjv . com
Bill Vermillion
Not really true. It depends on the program run and if the programs
are designed with multi-cpus in mind so you can process certain
processes in parallel instead of in serial fashion.
Tony Lawrence
SMP has overhead of its own. I guess you might be able to find a
pathological case where you could have a process set that wasn't
stressing a single cpu but ran faster on SMP, but I bet you'd be hard
pressed to do so even on purpose.
Bill Vermillion
As I said you really should have programs designed for that. I'd
think really intensive applications such as compilations might
benefit most.
I have not seen information on the scalabilty of OSR5.
However a while back in some email correspondance with an engineer
at Novell - before SCO bought Unix from them - he had said that he
found the Unixware 2.1 was scaling almost linearly - with a
4 CPU system having 375% performance of a single system CPU.
A few years ago some systems would perform more along the lines
of 200% with 4 CPUs.
Now what will be intersting is what will be able to be done
when the dual-core CPUs start becoming available.
Bill
Bob Meyers
"Bill Vermillion" <b...@wjv.comREMOVE> wrote in message
news:GquE...@wjv.com...
> Not really true. It depends on the program run and if the programs
> are designed with multi-cpus in mind so you can process certain
> processes in parallel instead of in serial fashion.
>
I think I have seen this in action. I don't remember where exactly, but in a
syslog or messages or stderr I saw where the SCO 5.0.5 reported something
like... "assigning SCSI tape operation to CPU#2". But after that, I could
see no real whoop-dee-do results from it. It didn't seem any faster than a
comparable single-CPU.
I'll bet 85% of SCO installations run I/O - disk based applications
(databases). In that case I don't think the SMP helps much. Maybe in theory,
but not in my personal experience. Just an opinion obviously - and I am
wanting to hear someone tell me different results.
Bill Vermillion
Well there are some awfully big SCO installations out there. So
much of this group seems target to small and medium installs that
you never see the big systems discussed here.
In an email with a person about year or so ago discussing some HW
issue I had made a comment that it sounded like a big system and he
came back with "Well we did $16,000,000 worth of business on it
Friday".
Your 85% figure may be right, maybe high, maybe low. I have no
idea.
James R. Sullivan
Bill Vermillion wrote:
>
> In article <3C5A2E10...@pcunix.com>,
> Tony Lawrence <to...@pcunix.com> wrote:
> >
> >But it doesn't matter a bit how well designed the SMP is if the
> >primary load doesn't tax the capacities of one cpu.
Agreed. The key thing to look at is not pegged CPU, but the length
of the run queue (sar -q, I think). Multiple processes being ready
to run at the same time will benefit from SMP. A single process
consuimg CPU won't
>
> >If sar isn't showing a pegged cpu at least part of the time, there
> >isn't going to be much sense in spending the money on the hardware
> >or the license.
Agreed, but you should also check the run queue
>
> Not really true. It depends on the program run and if the programs
> are designed with multi-cpus in mind so you can process certain
> processes in parallel instead of in serial fashion.
Yes and no. Since OpenServer doesn't really properly support process
threads, there is little benefit unless the program is designed to use
multiple processes. Most OSR5 applications are not.
--
Jim Sullivan
Director, North American System Engineers
Tarantella! http://www.tarantella.com
831 427 7384 - j...@tarantella.com
Robert Steinmetz
Bill Vermillion wrote:
They said they would support Solaris 8 for 7 more years. Openserver has
a hazy future as well. They may bring it back when their bottom line
improves. But for now if you need multiple CPU's on Intel processors it
is the best price/performance.
wvaughan
> I'll bet 85% of SCO installations run I/O - disk based applications
> (databases). In that case I don't think the SMP helps much. Maybe in theory,
> but not in my personal experience. Just an opinion obviously - and I am
> wanting to hear someone tell me different results.
Put filePro (http://www.fptech.net) into a tight loop, and as long as you
catch it before someone else causes a second instance, you will be pretty
happy that you have a CPU free to kill that 1st CPU.
I have always felt that SCO should have gone to a free 1-2 CPU license
when 2 processor boards became only a hundred dollar upgrade.
Walter
Matt Schalit
>> Just be aware the Sun has just announced there will be no version
>> of Solaris 9 for the iNTEL platform - at least for now.
>>
>> They indicated that they may bring out an iNTEL port in the future
>> but that is an unknow. They stopped the free downloads about 2
>> weeks ago when they made the announcment of dropping the iNTEL
>> platform for the Solaris 9. You can still get Solaris 8 on CD
>> media.
Yes, but for the sake of clarity, let it be said that they
are still releasing intel ports of Sol8, which has been updated
several times. The Oct 2001 version is much different from the
1999 version for instance. I was a day or two late, downloading
the newer Sol8, and missed it just like you mentioned, about two
weeks ago :-/
>> --
>> Bill Vermillion - bv @ wjv . com
>
>They said they would support Solaris 8 for 7 more years. Openserver has
>a hazy future as well. They may bring it back when their bottom line
>improves. But for now if you need multiple CPU's on Intel processors it
>is the best price/performance.
Really? I'd take an SMP Open Unix 8 box head to head against
that ancient OSR5 technology any day. And I'm not talking about
the 32-cpu version :) Still, let's bring it on .........
http://docsrv.caldera.com:1997/FEATS/ou800_32cpu.html
http://www.caldera.com/developers/community/contrib/aim.html
ftp://ftp.caldera.com/pub/opensource/aim-suite9/s9110.tar.Z
Well I got through test 29 and my system locked up. I figure
I need a new power supply, maybe an Enermax 350W, because I
upgraded to 1GHz cpu's the other day.
I'll post my results after this weekend in a new thread.
Best,
Matthew
>--
>Robert Steinmetz AIA
Robert Steinmetz
Matt Schalit wrote:
Sorry, I was not clear, I was referring to Solaris 8 x86 as the best
price/performance for Multiple CPUs on Intel. Solaris 8 x85 is currently
available for $45.
steve overy
snippety snippety...
>
> Really? I'd take an SMP Open Unix 8 box head to head against
> that ancient OSR5 technology any day. And I'm not talking about
> the 32-cpu version :) Still, let's bring it on .........
>
> http://docsrv.caldera.com:1997/FEATS/ou800_32cpu.html
> http://www.caldera.com/developers/community/contrib/aim.html
> ftp://ftp.caldera.com/pub/opensource/aim-suite9/s9110.tar.Z
>
>
> Well I got through test 29 and my system locked up. I figure
> I need a new power supply, maybe an Enermax 350W, because I
> upgraded to 1GHz cpu's the other day.
>
> I'll post my results after this weekend in a new thread.
>
> Best,
> Matthew
>
Matt,
couldn't resolve that FEATS link, isit right? (even port 1997
wasn't liked), I've had 16way SETI running but never got my hands on
the full house! mibbie I'll have to stash that AIM suite away for when
I do get a handful.
cheers
steve
Bill Vermillion
>> On Fri, 01 Feb 2002 13:57:18 -0600, Robert Steinmetz <r...@steinmetznet.com> wrote:
>>
>>>>Just be aware the Sun has just announced there will be no version
>>>>of Solaris 9 for the iNTEL platform - at least for now.
>>>>They indicated that they may bring out an iNTEL port in the future
>>>>but that is an unknow. They stopped the free downloads about 2
>>>>weeks ago when they made the announcment of dropping the iNTEL
>>>>platform for the Solaris 9. You can still get Solaris 8 on CD
>>>>media.
>> Yes, but for the sake of clarity, let it be said that they
>> are still releasing intel ports of Sol8, which has been updated
>> several times. The Oct 2001 version is much different from the
>> 1999 version for instance. I was a day or two late, downloading
>> the newer Sol8, and missed it just like you mentioned, about two
>> weeks ago :-/
>>>>-- Bill Vermillion - bv @ wjv . com
>>>
>>>They said they would support Solaris 8 for 7 more years.
>>>Openserver has a hazy future as well. They may bring it back when
>>>their bottom line improves. But for now if you need multiple
>>>CPU's on Intel processors it is the best price/performance.
The attributions are screwup here and it looks like I said the OSR5
was good from SMP>
>> Really? I'd take an SMP Open Unix 8 box head to head against
>> that ancient OSR5 technology any day. And I'm not talking about
>> the 32-cpu version :) Still, let's bring it on .........
When SCO acquired the USL stuff from Novell the Unixware was about
the best performing multi-cpu OS available on the intel platform.
Check back in the thread and you'll see I mentioned that a 4 CPU
version ran about about 375% of a single CPU. At that time nothing
else came close.
The Open Unix 8 derives from that technology. Just setting the
attributions straight as the OSR5 is V.3 and it is fairly ancient.
Other companies were releasing V.4's when the OSR5 - based on V.3
came out. Older reader of this group will remember when Larry
would harrangue everyone and accuse SCO of trying mislead others,
while he felt that Dells' UNIX was the best.
Intersting that in a year or so Dell dropped their Unix [A v.4
release] and earlier this year they dropped Linux support. They
just can't seem to get it together in the *n*x world.
Matt Schalit
>msch...@pacbell.net (Matt Schalit) wrote in message news:<3c5b0393....@news.sf.sbcglobal.net>...
>
>snippety snippety...
>
>>
>> Really? I'd take an SMP Open Unix 8 box head to head against
>> that ancient OSR5 technology any day. And I'm not talking about
>> the 32-cpu version :) Still, let's bring it on .........
>>
>> http://docsrv.caldera.com:1997/FEATS/ou800_32cpu.html
>> http://www.caldera.com/developers/community/contrib/aim.html
>> ftp://ftp.caldera.com/pub/opensource/aim-suite9/s9110.tar.Z
>>
>>
>> Well I got through test 29 and my system locked up. I figure
>> I need a new power supply, maybe an Enermax 350W, because I
>> upgraded to 1GHz cpu's the other day.
>>
>> I'll post my results after this weekend in a new thread.
>>
>> Best,
>> Matthew
>>
>
>Matt,
> couldn't resolve that FEATS link, isit right? (even port 1997
>wasn't liked),
If you can't hit 1997, which is the Ou8 doc server port,
then it's your firewall. Remember how it used to be 457?
Well I guess they chose one above 1024 to make it easier
on people's firewall, just not your corporate one :)
The links still good, but here's all it said:
| Release 8.0.0 new features
|
| Scalability: 32-CPU SMP
|
| The scalability of Open UNIX 8 on SMP systems up to 32 CPUs has been improved.
| Scalability is measured according to the requirements for running the TPC-C
| benchmark, with Oracle as the database vendor.
|
|
|© 2001 Caldera International, Inc. All rights reserved.
|Open UNIX 8 Release 8.0.0 -- 22 June 2001
>I've had 16way SETI running
What do you do, bind each seti process to a different cpu?
I tried that, and I think I found that it works ok if you
don't bind anything to cpu0, leaving it free to keep house
and that the device drivers get bound to cpu0. Does that
hold for more than 2 cpu's?
>but never got my hands on the full house!
I've never even seen a 16 or 32 cpu mainboard. I wish
I had a job with EG&G Energy Research so I could put some
of their smp machines to good use. It's also too bad Bell
Labs isn't someplace warm :)
>mibbie I'll have to stash that AIM suite away for when
>I do get a handful.
>cheers
>steve
Man, I tell you that AIM benchmark will teach you more about
tuning your bios chipset freatures than you ever knew before.
It's not even funny how repeatable the results are and how some
of the values go to hell when you set your
SDRAM MA Wait State Normal
as versus Fast, for instance. Or how about 2T,2T,2T,8T versus
3T,3T,3T,10T makes a huge difference (as the SPD eeprom would
have you set your ram for a PC133 7ns ECC sdram set). This
kind of stuff will sidetrack me for days... nuts.
My test results are posted in a new AIM Benchmarks Results thread.
Regards,
Matt
steve overy
snippety snippety...
> >Matt,
> > couldn't resolve that FEATS link, isit right? (even port 1997
> >wasn't liked),
>
> If you can't hit 1997, which is the Ou8 doc server port,
> then it's your firewall. Remember how it used to be 457?
> Well I guess they chose one above 1024 to make it easier
> on people's firewall, just not your corporate one :)
(All hail the network mafia)
> The links still good,
snip, snip...
>
> >I've had 16way SETI running
>
> What do you do, bind each seti process to a different cpu?
> I tried that, and I think I found that it works ok if you
> don't bind anything to cpu0, leaving it free to keep house
> and that the device drivers get bound to cpu0. Does that
> hold for more than 2 cpu's?
This was quite a while ago (over a year) our 32-way boxes (ES7000) had
just come out & nobody was sure just how UW would load on them,
outside of the plant I was propably the first to try. I can't quite be
certain just HOW I ran them, I suspect I just fired off 16 copies
(plus some cpu/memory/disk tests), and really only to see if they
would survive the weekend (which they did).
I've never seriously gotten into binding processes (pbind command) but
my Oracle people tell me there are are heavy benefits with selective
use (especially on our 32way boxes). Note "man sdevice" - you can bind
drivers to processors other than 0.
From my (limited REAL as against theoretical) experiences it can be
quite interesting watching a multiway box, the processes just get
distributed across the cpus. Its only if you have something thats
nearly constantly in use that it makes sense to bind & take advantege
of caching - or so I imply.
In the real world I never get a heavyweight system to experiment with
(which is really what you want to do with performance questions), I'm
just expected to fix things with as little disruption to operations as
possible!
>
> >but never got my hands on the full house!
>
> I've never even seen a 16 or 32 cpu mainboard. I wish
> I had a job with EG&G Energy Research so I could put some
> of their smp machines to good use. It's also too bad Bell
> Labs isn't someplace warm :)
Our ES7000 doesnt have a "cpu mainboard" as such, the cpus come in
4way sub-pods and you collect those up.
> >mibbie I'll have to stash that AIM suite away for when
> >I do get a handful.
>
> >cheers
> >steve
>
> Man, I tell you that AIM benchmark will teach you more about
> tuning your bios chipset freatures than you ever knew before.
> It's not even funny how repeatable the results are and how some
> of the values go to hell when you set your
> SDRAM MA Wait State Normal
> as versus Fast, for instance. Or how about 2T,2T,2T,8T versus
> 3T,3T,3T,10T makes a huge difference (as the SPD eeprom would
> have you set your ram for a PC133 7ns ECC sdram set). This
> kind of stuff will sidetrack me for days... nuts.
>
> My test results are posted in a new AIM Benchmarks Results thread.
>
> Regards,
> Matt
Seen the results - they look v interesting, pity our lab boxes are all
single cpu!
regards
steve
Matt Schalit
>I've never seriously gotten into binding processes (pbind command) but
>my Oracle people tell me there are are heavy benefits with selective
>use (especially on our 32way boxes). Note "man sdevice" - you can bind
>drivers to processors other than 0.
With seti, I found the greatest improvement was not with
binding it to a processor (which sort of gets in the way
of Uw7 dynamically balancing the load across the cpu's).
The most improvement came from putting the seti directory
into memfs and running it out of there. I must have
saved 1.5 hours per wu.
My uw7.1.1 box was so fast crunching seti that I spent
some time comparing wu-completion times against other
systems with the same Mhz.
Undeniably, Uw7 was the fastest at crunching a seti wu
on an intel based OS at a given Mhz. When doing these
comparisons at least a year ago with PII 400's, I would
get a wu in about 8.25 hrs. All the other intel boxes
could only manage about 11 hours. The main reason for
my speed was the memfs and redirecting the display output
to /dev/null. Seti used to output to disk and the screen
all the time back then, which was slow. Nowadays, Seti
does very little screen or disk writing, making my advantage
much less.
In comparison, a DEC or an SGI running at 300 Mhz with a
4MB L2 cache was doing a wu in about 2 hrs!
It's a shame that Intel took away the L2 cache from us and
put it on the cpu and now charges us $4000 if we want that
much cache. I still remember getting all exited when I
bought my first 512k L2 cache stick and put it in my old
Asus.
Comparing seti results taught me about the MHz myth.
Regards,
Matthew