Hello all, first post to the forums... hope I can get some help with this issue...

I've installed YellowDog Linux on my PS3, was able to get BOINC and BOINCMGR running, got it working and all, retrieved WU's (2 of them) and the only problem I have is that it's only crunching one WU at a time... I tried adding a cc_config with ncpus set to two, and told it to read the config file, but it didn't seem to work... wondering if anyone has any input ??

I used a full linux install, with this boinc manager for ps3... http://www.ps3grid.net/PS3GRID/PS3client/boinc_client_ps3grid.tgz


I then copied the project folder that was located here ---> http://setiathome.berkeley.edu/forum_thread.php?id=39910

into the project folder from the first link... that seemed to get it working, crunching numbers and all...



I tried each of those links by themselves, and no luck... when I combined the project folder from the second link into the first link's boinc manager, it seemed to work... I believe this is because the first link did not include an app for the PS3, and it couldn't get one from SaH... so, putting in the compiled for ps3 app from the second link got it going... with the full-gui and all... now I just need to get it crunching numbers on the second cpu in the ps3.... any help is appreciated!!


Thanks so much..
Brandon

The Playstation 3 utilizes a single core CELL processor which has 8 "synergistic processing elements" or SPEs. [Edit] Of the 8, one is disabled to improve yields (if a chip has a bad SPE, it doesn't have to be discarded), and one is reserved for the Sony PS3 OS, leaving 6 SPEs available to programmers.

This means that it is up to the programmer to properly take advantage of all that the hardware has to offer, such as whoever coded the PS3-Linux app. The problem is that Sony nor IBM are willing to offer help to SETI in how to best optimize code to get the performance out of the PS3, so it has been left up to any volunteers with whatever limited knowledge they may have on the architecture.

In other words, it is working as it should.

---

Oh thank you so much :) I thought I would be able to run two seperate tasks, as in the system monitor on the PS3 it shows CPU1 at like 3-10% utilization, and CPU2 at 100% utilization running the SaH app.... I'll just keep checking and see if any updates are made to the SaH on PS3 program



thanks

brandon

I'm not exactly sure how or what the OS or monitor program are coded to display, but my best educated guess is that CPU1 is probably the reserved CPU for the OS while CPU2 is probably either 1 of or all of the 6 remaining SPEs.

---

Hi

The 64 bit POWERPC in PS3 is a dual thread processor ( not dual core! ), so CPU1 and CPU2 shows two threads running on one processor.

The load of 6 SPUs can be viewed with spu-top command , found in spu-utils package or simply view the contents of /spu directory ( ls /spu ) where every subdirectory symbolizes a process running on SPU.

Many programs can run on POWERPC found on PS3, but not on the SPUs, if that is the case the SPUs are idle all the time.

For example of good, full CELL PS3 usage is project distributed.net which has got a very heavily optimized client for PS3 which actually utilizes all available SPUs. The POWERPC part runs single optimized thread as this proved to be faster than two threads.

This thread is only a month old, so I'll consider it still live. Has there
been any update to PS3 SaH clients since Khanna's release of SPE optimized FFT
clients in May, 2007? Most PS3 users seem to be noobs that aren't even aware of
those. I'm just now getting my PS3 up and running. SaH MB units take 16-20hrs
on average, and running two together, it'll take well over 24 hours to finish.
It's evident there's a lot to be done. I don't think CELL BE is being utilized
well at all, though Khanna's work is certainly impeccable. FFT is only a chunk
of the problem, not the biggest one, it seems.

Since the SPE's are cooperatively shared by a pair of client processes
(according to Khanna), it looks like there's a severe bottleneck at the PPE,
to start with. Though it's a 2xSMT processor. the PPE is a brain-damaged analog
of the parent PPC 970, with only one of each functional unit. Maybe two
threads just aren't good for it (the highly optimized FaH client over at
distributed.net uses only one thread so it bears out the architectural
limitation of the PPE). It appears to me that the non-FFT code may have
high branching factor, as well as considerable nesting depth in places. That
suggests that the branch prediction table is thrashing. I wouldn't guess
that with the small code size of the app as well as small data sets of the
WUs that TLB shuffling or cache misses are a problem. I don't yet have IBM's
SDK to do any investigating (that's next). Does anyone have any analytical
information to share?

Stuart

Gauravs SETI application, which is available on my homepage (http://www.dotsch.de/seti uses the SPEs of the PS3, and should been faster than the Applikation from Alex Kan.