PDA

View Full Version : Ogr-ng(26)



Brucifer
11-01-2008, 01:34 AM
So are there any "in-the-know" people around here regarding the client development. While it appears that the PS3's aren't going to be crunching on this, is there any known work going on with the nvida video cards? Can they be used or are they going to fall victim to the same issue as the ps3's?

LAURENU2
11-01-2008, 02:34 AM
Of Of-coarse there are people "in-the-know" here
Please continue to hold your Post is vary important to us and it will be answered in the order received :jester:

PCZ
11-01-2008, 03:03 AM
I'm hoping for a GPU client as well.

BTW
Were is everyone, R@R is over report for duty immediately.

alpha
11-01-2008, 05:56 AM
Someone wrote a CUDA core for RC5-72 (http://www.free-dc.org/forum/showthread.php?t=12256) capable of 125 Mkeys/sec but I don't think it ever got finalized or released to the masses. The author's comments on OGR at the time were:


I agree that OGR is much more interesting but reading the documentation surrounding the core algorithm, the non-constant execution times may present a significant challenge WRT getting good performance out of a GPU implementation. But, I haven't looked too closely at the underlying code, so my comments may be irrelevant.

I personally haven't heard of any developments in the GPU field since. It doesn't sound hopeful, but with a new project having only just started hopefully it will spawn more interest in the area.

gopher_yarrowzoo
11-01-2008, 11:26 AM
I'm hoping for a GPU client as well.

BTW
Were is everyone, R@R is over report for duty immediately.

Sorry "Sweetheart" was only crunching this one till OGR-25 was over to try and maintain position, the kindly donated dualie loved it but right now is offline due to erm well it also loved eating massive chunks of power :(... Yeah I saw the hike in power usage and knew it had to be that as I've got other running and the power usage isn't as noticeable - IF I could manage to transfer over all that on my one remaining Win98se box - i.e it's running FTP / Web / MySQL servers I'd do that and close down that box totally, but I'd need to recreated the directory structures etc, bit slow over the wire to transfer it yeah that and I'm a lazy sod - but it will get done one day , when I find a project worthy of the dual power, well the 98 box is a AMD X2200+ so it's not slow just old....

Brucifer
11-01-2008, 12:27 PM
You let a little thing like power consumption stand in the way of the team accumulating high points in OGR????? :roadkill:

Actually, get rid of those old amd's and get a new quad or a couple 60 watt X2's, and your power will go down. I was running a bunch of the old stuff, and shifted over to a few quads and some 60w X2's, and my power bill dropped by half......... that totally impressed the spouse!!

Brucifer
11-01-2008, 10:22 PM
Ahhh... my perproxy is working just fine. :)

So it looks like we be in #4 spot, but there are some teams ramping up now. Those cows have already got a (pardon the pun) herd of members. :jester:

gopher_yarrowzoo
11-02-2008, 12:23 PM
Ahhh... my perproxy is working just fine. :)

So it looks like we be in #4 spot, but there are some teams ramping up now. Those cows have already got a (pardon the pun) herd of members. :jester:

Oh time to MOOOOve on from that baaaad joke..

Yeah I powered down a X2000+ for that very reason it was the really early model ate power i think, it's not the chip swap that bothers me it would be a total replacement system and where do I off load the old one.. Oh wait I think I know, just need a case :P can give it as a christmas pressie :D

Chuck
11-09-2008, 03:45 PM
Ahhh... my perproxy is working just fine. :)

So it looks like we be in #4 spot, but there are some teams ramping up now. Those cows have already got a (pardon the pun) herd of members. :jester:


With the help of a few friends, A WHOLE LOT OF TRUST AND PRAYING.... I setup and switched to the D.net Perproxy ON MY K6-2!!!!!!....


Yes, K6-2 500Mhz, stripped down just fine w/2k install. It DOES have a 100 Mbit Enet card in it and given it's running nothing else, all the non-essential services are OFF.

Now, thanks to help from Brucifer and a bit of experience using the other proxies, I took a shot at the transition NOW instead of tonight. SO gang..... If I have LITTLE to NO points on OGR-NG, you will know why. I do think I botched one machine, but hope the fallback to the Dnet server caught it. It looks like it did.

Either way, The K6-2 sits there, quiet as a can be, serving up my movies (yes, it has a few *nice* drives on it) AND serving up my OGR packet needs within 2 seconds (typically 1) of the cruncher deciding it needs to send/receive packets!

I hardcoded the IP address in each cruncher to avoid resolv.conf time (every cycle counts) and it's working like a champ.

So, unless i *lost* data in the switchover, things are a whole lot more efficient here now. Given I put the K6 on the appropriate side of the routers and have a 'magic port' open *somewhere*, should the need ever arise at the end of the project, I will be willing to supply data for the thirsty to the limits of the proxy & Inet.


Now, if there were a proper eOn proxy..... .


Again, thanks to all. A K6-2 is now very happy again being able to do SOMETHING useful !!!


Tnx,
C.


PS: I know many of us wanted to do 'pet projects' after OGR-25, but would some consider coming back????

Death
11-09-2008, 04:02 PM
there IS eOn proxy.

http://www.pubquizcentre.nl/DigiK-oz/dceon.aspx

well, sort of...

Chuck
11-09-2008, 04:23 PM
Thanks,
However, the Target OS isn't compatible, IIRC. I'm a linux shop here with 2 W/2k boxen. Last I knew, and PLEASE correct me if wrong, the proxy does require the .NET which is W/XP or better?

Tnx,
C

Death
11-09-2008, 04:39 PM
.net 2.0 that eon proxy use 2k compartible

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en

System Requirements
Supported Operating Systems: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2
Required Software:
o Windows Installer 3.0 (except for Windows 98/ME, which require Windows Installer 2.0 or later). Windows Installer 3.1 or later is recommended.
o IE 5.01 or later: You must also be running Microsoft Internet Explorer 5.01 or later for all installations of the .NET Framework.

Disk Space Requirements: 280 MB (x86), 610 MB (x64)

Chuck
11-09-2008, 04:57 PM
Thanks very much... that's how little I remember of the MS world..... Last I used it for anything more than simple web stuff was before I went to FC5.

Tnx again,
C

gopher_yarrowzoo
11-11-2008, 02:57 PM
I've thrown a PC at this, dropped it from SoB to this, so should help out.

IronBits
11-13-2008, 11:54 PM
I finally got around to adding the PS3 pharm (all 3 of them) on OGR and on RC5 at the same time. :)
Looks like I can make 3-4T per day on OGR without any impact on the RC5 output.
:cheers: to the developers :D

Chuck
11-14-2008, 09:28 AM
I've got another machine 'breaking in' on this + some extra horsepower left over from what isn't needed for my mathematics work..... It's been added

FWIW: If you can run the linux client, you can have about 30-40% more output. Windows just wastes too much due to the lack of separation of the threads, so they bounce around between the cpu caches like ping-pong balls.

Otherwise, I like this version and look forward to the polished final release client.

C.

Digital Parasite
11-20-2008, 02:44 PM
Is it just me or has http://stats.distributed.net been down for the past couple of days?

Even http://downforeveryoneorjustme.com/ is saying they can't find a DNS entry for it.

wirthi
11-20-2008, 02:48 PM
Check the plans: http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=mikereed


Our stats system is down. We apologise for any inconvenience this may cause.
More to follow.

Chuck
11-20-2008, 02:50 PM
I would think it's down. Their DNS is responding and resolving... You can see it if you watch it in the FF status bar.

I get the 'The server at stats.distributed.net is taking too long to respond.' message, which I don't get unless there is a problem.


C.


/me feels dumb now.... we posted at the same time... :)

alpha
11-22-2008, 01:35 AM
The stats are back and fully up to date.

Ars Technica slipped past us at more than double our rate for yesterday.

Digital Parasite
11-22-2008, 05:57 AM
The stats are back and fully up to date.

Ars Technica slipped past us at more than double our rate for yesterday.

I think a lot of people are bailing on their ABC@Home push and switching to other projects like OGR-26

alpha
11-22-2008, 08:00 AM
Yeah, I saw the thread over there and was in awe at the amount of computing power which was collaborated in such a short time. I didn't realise either that 100% on ABC@home did not mean the project was over, so I'm glad I tracked the thread.

We've still only got a handful of people running OGR-26 so hopefully when the client gets out of pre-release we can rally up a bit more support.

Digital Parasite
11-22-2008, 05:11 PM
We've still only got a handful of people running OGR-26 so hopefully when the client gets out of pre-release we can rally up a bit more support.

I see that the 1 and 3 day averages are showing project end in Jan and Feb so we might whip through this thing. I was originally planning on putting most of my systems on OGR-26 in January to help finish it off but it looks like I will start doing that next week.

I wonder when they finished the new client algorithm. Since the new algorithm makes that much of a difference they really should have used it part-way through OGR-25 as well unless it was just finished recently.

Brucifer
11-22-2008, 11:11 PM
look:
http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=bovine

10% done already.

alpha
11-23-2008, 07:12 AM
That's an interesting update Brucifer!


We're working on updates for some of the remaining platforms (like
NetBSD and OpenBSD) plus some exciting new ones (like nVidia CUDA), so look forward to future announcements.

Digital Parasite, the amount of processing required for OGR-26 was supposed to be significantly greater than for OGR-25, but due to some changes (not sure if it was the algorithm itself or some other change or both) the quantity of work was heavily reduced.

IIRC, they said the new algorithm should be able to decide sooner when to stop processing the current stub, which effectively reduces the average stub size over what it would have been with the old algorithm. But also, it seems there must have been some other change to reduce the overall number of stubs to check because we went from 304,857,742 stubs for OGRp2-25 to 9,967,533 for OGR-26. Perhaps it wouldn't have been possible to have made such changes mid-way through a project.

Brucifer
11-23-2008, 12:49 PM
That's an interesting update Brucifer!

I thought it was too! :) The CUDA info will be interesting to watch. Initially they said they had some severe memory constraints with the PS3 too, but they have a working client for that which is interesting too. As Ironbits mentioned that he could get a lot of rc5 work done at the same time as the ogr-26 without seeming to impact the ogr-26 crunching. So I'm watching the CUDA issue too.

The other thing that surprised me was that they said the project was about 10% done. That's rocking along, and it isn't going to be that long of a project. A lot of processing power that was on the ogr-25 effort at the end has moved back to other efforts, but even so, ogr-26 seems to be moving along pretty good. I wouldn't be surprised to see the completion date move closer as teams realize they aren't going to have as much time to do ogr-26 and other stuff as it initially appeared. Time will tell. :)

alpha
11-23-2008, 02:53 PM
Actually, the memory problems with the PS3 client are still ongoing. With the latest version of the client, they just have it crunching OGR on the PPE but none of the six (available) SPEs.

If/when we have a working CUDA client unleashing the kind of processing power we expect we could be bashing through the OGR projects in no time, not to mention increasing the chances of finishing RC5-72 within our lifetimes! I'd be more tempted than ever to buy the appropriate hardware and get it running. :)

Digital Parasite
11-24-2008, 10:16 AM
Too bad there is such good support for CUDA and nothing for ATI cards. If only NVIDIA or ATI would make CUDA compatible. :music1:

alpha
11-26-2008, 02:29 AM
Wow, what a find when I wake up this morning:


Updated PS3 client which now supports OGR-NG on the SPEs
CUDA client for AMD64 Linux, RC5-72 support only! (no OGR-NG yet :()


Find them here! (http://www.distributed.net/download/prerelease.php)

IronBits
11-26-2008, 03:02 AM
I'm not ready to burn up my expensive gaming card to crunch numbers.
The video card puts out LOTS-O-HEAT and sucks up more watts than a cpu to.
Thanks for the linkage to the updated dnet client for CellBE :thumbs:

Death
11-26-2008, 03:36 AM
what kind of cooler are in your video card?

IronBits
11-26-2008, 05:46 AM
Stock, and I don't OC it either.
A GTX280 is plenty fast enough for what I need. :)

Digital Parasite
11-26-2008, 02:11 PM
Wow, what a find when I wake up this morning:

Updated PS3 client which now supports OGR-NG on the SPEs
CUDA client for AMD64 Linux, RC5-72 support only! (no OGR-NG yet :()



So they were able to squeeze the new OGR-NG algorithm into the SPEs then? IronBits, how fast does that puppy run on your PS3s?

Digital Parasite
11-26-2008, 02:12 PM
I'm not ready to burn up my expensive gaming card to crunch numbers.
The video card puts out LOTS-O-HEAT and sucks up more watts than a cpu to.
Thanks for the linkage to the updated dnet client for CellBE :thumbs:

What?!?!? You mean you bought an expensive gaming card to play games on? What kind of a DC fanatic are you... :Pokes:

the-mk
11-26-2008, 02:37 PM
:rotfl:
:D

IronBits
11-26-2008, 06:23 PM
Holy crap!

OGR output went way up!
http://stats.free-dc.org/dnet/ogr/byemail.html
~101 Mnodes/s

RC5 output went down because OGR is using all 7 cores :D
http://stats.free-dc.org/dnet/rc572/byemail.html

dnetc.ini shows
project-priority=OGR-NG,RC5-72

I was using
project-priority=OGR-NG=1,RC5-72=1


[Nov 26 15:19:36 UTC] Automatic processor detection found 7 processors.
[Nov 26 15:19:36 UTC] Loading crunchers with work...
[Nov 26 15:19:36 UTC] Automatic processor type detection found
a Cell Broadband Engine processor.
[Nov 26 15:19:36 UTC] OGR-NG: using core #1 (KOGE 3.0 Hybrid).
[Nov 26 15:19:36 UTC] OGR-NG #a: Loaded 26/2-7-33-14-15 (131.86 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #b: Loaded 26/2-7-39-11-26 (171.58 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #c: Loaded 26/2-8-11-1-49 (169.85 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #d: Loaded 26/2-8-15-16-40 (171.72 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #e: Loaded 26/2-9-5-12-27 (167.87 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #f: Loaded 26/2-9-14-10-46 (172.27 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG #g: Loaded 26/2-9-20-12-4 (169.37 Mnodes done)
[Nov 26 15:19:36 UTC] OGR-NG: 168 packets remain in buff-in.og2
[Nov 26 15:19:36 UTC] OGR-NG: 0 packets are in buff-out.og2
[Nov 26 15:19:37 UTC] 7 crunchers ('a'-'g') have been started.

Chuck
11-26-2008, 06:30 PM
Catching up / verifiying if you don't mind? I would like to make sure I'm in sync about CUDA / SPE-type/based GPUs and OGR.


first the obvious.... The OGR algorithm is a Linear Algebra / Combinatorics problem, right? If so, then memory and access time (like texture maps) along with list construction/destruction (like display lists) uses just the core instruction/capability set of a GPU/GPU-set... and the big gain comes from having so many processsors (like IB's machine) ?

So, your results IB mean they are testing the support in the OGR code as well but not saying anything publicly yet????




ANd, if I understand CUDA correctly, two CUDA support cards can use the SLI as well to gang up a bunch/pair of medium grade cards using SLI, provided there's enough main application CPU data bus speed to feed them (and do other housekeeping) for yet more fun? That right?

If so, what about accessing the spare/extra P4 in the xboxen? We can use that too, can't we?

Regarding the ATI side.... AMD is doing the CUDA support now. Granted a bit late, but it is apparently coming for the new Firestorm side, but how much do you want to bet we end up with ""limited"" support for the rest of the line?

Thoughts? Knowledge? Ideas? Wish lists? WHO DO WE WRITE TO???



Thanks,
C.

Bok
11-26-2008, 07:00 PM
IB's is a PS3 running linux (x3 - was x10 at one point :p )..so yes, more SPE's all being utilized now.

If Microsoft would release any code then sure, XBOX360 could be utilized, I just imagine with all the trouble they normally get this would make it worse...(red ring of death)

SLI Nvidia can be utilized as two seperate cards I believe, not sure if it is seen as one, though I'm sure that's possible..

ATI, most likely but down the line once the instruction set is more understood, seeing as it is only now being released...

Bok

Chuck
11-26-2008, 07:21 PM
Thanks Bok,
Wasn't sure of the machine etc.... thanks.


And yes, I agree that MS is probably VERY reluctant to let us use any more of the xboxen given how many melted down the first time around, but it would be nice to hack it.... i've been told, but not seen it done, that accessing the processor is not a big deal... the issue is overtasking it and the heat it produces.... Please correct me if I understood my son wrong, but MS had to fix/recall/whatever a bunch of machines because the now 'spare' P4 inside (could be used for housekeeping and offload one of the properly cooled mains ??) was once allowed to be used at 'full strength'... hence the Red Ring of Death and overhaul that "didn't quite live up to expectations" ???

I would love to see what IB gets over the long haul on the machine.... I see the memory fragmentation that OGR currently causes.


Oh, and from what I know.... once the ATI weenies finish their brain dump and map the instruction sets.... the new development kit (like for the firestorm, etc) will be regular C code development-level... so perhaps a 'port' to it won't be too painful, but the compiler's internals are going to be a nightmare.

One can hope????? :)


Thanks again,
C.

Brucifer
11-26-2008, 10:28 PM
I'm probably all wet, but as I understand it the CUDA/nvida is only being tested on the rc5-72 stuff right now on 64-linux. What I'm not aware of and wondering is what all hast to be loaded onto the host system for the cuda stuff to work??

As for the spe's on the ps3, that is supposed to be intentional with the latest beta release for the cell ogr.

Chuck
11-27-2008, 12:41 AM
Bruce, you are probably right.... probably nVidia, and I agree since it is the most common and currently best engine out there accessible to the mass user base.

I know I did read it is AMD64 and not X86-64, but that would simply imply it's AMD scheduled (for speed) and not EM64T (Intel scheduling for speed).

Please forgive all my questions as I am looking at this to properly understand how to best use the GPU (assuming it can't really be programmed into an FSM engine... and what would be the fastest way to do the math to a) eliminate non-Golomb ruler sets as well as b) validate a 'proper' ruler in as few machine instructions / memory accesses as possible. I know the guys at D.net have had 8 years to prepare for the '26' effort and I am still 'wet behind the ears' to the problem.... but it does have other applications that I am looking at.... and no, it's not prime finding (that will come).

Another thought is 'data compression'. Sounds strange at first... but if you did 'block compression' (like 1080p HD aka Blue-Ray or MP4 format) video to a PC over slow cable/ std dsl) where much of the individual pixels are the same, building in the CRC/ECC into the data stream for live feed for proper decoding and error correction without retransmit is essential to get the audio & video out efficiently and then display or encoding speed.

I'm just 'thinking out loud' and like you, wondering what all has to be loaded & what are the limitations. Also, I must admit that not having a PS3 here to use for DC apps and/or video is a handicap.... so the ultimate question is.... how much better (if at all) can a current CISC cpu be programmed for those of us who don't have PS3s, but do have 'middle -> upper end' graphics cards because we insist on good quality, dual head operation of our machines being the 'geeks' we are. :)

Eventually the 'other' math will come into play, but not yet. GPUs by design love to stream their data.... so how best to do it?

I've even wondered what the testing results for OGR were on multi-core machines where it puts one stub per core..... what if it were better to split/pipeline the stub between the cores/cpus (that is what the GPUs are doing). What happens if cpu/core 'a' filters out all the obvious non Golomb constructions and then 'b' determines the 'optimal' adjustments/compliance with other limits.. would we go faster or a lot slower? Could that be part of the 'algorithm improvements' that have happened since OGR-25 ?



Thanks,
C.

Death
11-27-2008, 03:30 AM
afaik ogr stub size calculations is linear.
i mean they got a lot of cycles included in each other like

for i = 1 to 100
for j =1 to 200
for k = 1 to 150

compare size of current stub to shortest

next k
next j
next i

kinda like that.

this is a very VERY simplified view but it's real, so you can't make it parallel.

alpha
11-27-2008, 06:13 AM
The source is available to download (http://www.distributed.net/source/), if that helps, Chuck.

Digital Parasite
11-27-2008, 02:56 PM
Oh, and from what I know.... once the ATI weenies finish their brain dump and map the instruction sets.... the new development kit (like for the firestorm, etc) will be regular C code development-level... so perhaps a 'port' to it won't be too painful, but the compiler's internals are going to be a nightmare.

Looks like ATI's new C-code like SDK will be included in the December release of the 8.12 Catalyst drivers. Details here:
http://www.behardware.com/news/lire/24-11-2008/

Should make porting your code to ATI a whole lot easier I would imagine.

Chuck
11-27-2008, 07:32 PM
The source is available to download (http://www.distributed.net/source/), if that helps, Chuck.


Looks like ATI's new C-code like SDK will be included in the December release of the 8.12 Catalyst drivers. Details here:
http://www.behardware.com/news/lire/24-11-2008/

Should make porting your code to ATI a whole lot easier I would imagine.

THANK YOU! I thought I had seen current/semi-current source available, but could not remember where. Thank you DP for the update on the SDK.

Now, having had *some* time to go over it.... in spite of the .cpp extensions (C++), it appears to be classic C code with the appropriate asm pieces where it is critical. I still have not mapped the entire algorithm flow and structure in my head yet, but think taking the code back to pure .c doesn't seem to be too difficult.... but then i haven't found that one piece of code (which has to be there SOMEWHERE) which would require rewriting...... Murphy's Law always prevails.

One thing I did see is the reference to gcc 3.4..... I currently have 4.1.2 which is a NICE step forward over the horrors of gcc 3.x (at times).

The 1-byte array of data is kinda wild. Haven't seen a monolythic table that big in a while. Making that available to / getting it sliced & stuffed into a GPU properly is going to be fun.

With the rest of the code being mostly regular C and the SDK coming out sooner than I was told it would be.... I have to ask.........Is it worth giving it a shot?


C.

Digital Parasite
11-27-2008, 07:54 PM
With the rest of the code being mostly regular C and the SDK coming out sooner than I was told it would be.... I have to ask.........Is it worth giving it a shot?


The SDK itself is available for download now:
http://ati.amd.com/technology/streamcomputing/sdkdwnld.html

Support for it built-into the ATI driver will be available in a couple of weeks.

Are you talking about would it be worth it for your project? Compared to what, writing the assembler code or CTM (Close To Metal?) style code that needed to be done before? This SDK will probably be the main way to write code for ATI cards for the foreseeable future so I would think it would be worth it. Debugging might be a lot easier too.

Chuck
11-27-2008, 08:50 PM
Are you talking about would it be worth it for your project? Compared to what, writing the assembler code or CTM (Close To Metal?) style code that needed to be done before?


I'm talking about what it means to us here with OGR.... and getting that back to D.net for their 'blessing' as official. What else we do with the technique/technology for our next target project can be decided later. As for my personal project, it is even more compute intensive so a stub == a WU and that is clearly where to draw that line.

Using the new SDK (and standard they are giving us w/wo CUDA) is part of learning that is going on as well as what is going on in the main app so what is already ASM can stay where it is.... UNLESS it's part of what needs to be put CTM.

Granted, I would love to just put all but the I/O (comm + local files) onboard, but this is a learning process for me compared to my regular job. The 'learning' part is how to slice / scale down (i know that sounds funny) from having 100+ individual cpus/boxen handle the network traffic and 'node' management, where 1 is the 'master', and the nodes below it are grouped into a 4 'render' per 'combiner' and each 'render' node has two cards in it. So the overall structure is Master -> Combiner -> Render machine structure. The Combiner is that strange piece of 'middleware' that speaks both 'render' language as well as does a bit of work on its own and then sends the finished data downstream, status back up, while waiting for the next block/task to be sent to it.... All of this occurring at a crazy rate 75 full 'cycles' per second.

The raw data comes into the master and is parceled out to the appropriate combiner/render nodes, where the 'master' is driven by the application machines (5 + a coprocessor SGI machine)


What I'm looking at now is essentially a 'quad core' (master + combiner) -> 1 or 2 'render' nodes.

The nice part is it's all in one box here.....but also makes it tougher since we can't 'just add another combiner/render set' as needed and the application is part of that task load in the box.



I've sent out an email already to the guy who was the original architect of it all (plus my mentor) and see what advice he has. If I know him, he's already been playing with the new SDK. Heck, he could (and most likely) have had a hand in its development / testing / tweaking.

Now, if you want to grab a quad cpu, quad core machine with 2 cards in a box.... that is something i can mentally directly map to.....

So, given I have only potentially only 4 cores and 1 card is the 'scaling' I need to verify.

Either way, this will get a LOT closer to the metal.... It's just a question of WHERE to draw the line.

Does that make sense? Any thoughts / advice?

I would like to know how you (all) would feel about having one machine be the 'master' and parceling out 'sub-tasks' to the other machine(s) you've configured as part of a 'cluster' on your lan ? Should I even give that any thought? Present thinking for me says 'no' as these are sufficiently compute-intensive *AND* asynchronous compared to massively parallel 'rendering' *AND* the proxy server is really the 'machine' that parcels out the work to be done anyway. true?

I have the proxy on my K6, but run the app on all of my other machines. In my case, I only care that a stub gets done, not by which machine or when. Is this correct thinking?


Maybe that's the real question here..... how do we define a 'cluster' and where are the layer boundaries?


Thanks,
C.

Chuck
11-27-2008, 09:26 PM
Rather than edit.... please let me say it here...


I said "75 'cycles' per second".... that would be, in OGR terms, the equivalent of 75 stubs per second.

and....

If you think about the GPUs on a Graphics Card with a single cpu driving it to drive a display (or multi-display group)..... expand that to be a group of cpus (or cores) driving multiple graphics cards to produce multple images, all in perfect sync with each other...

The transition from sync -> async and reducing multiple 22U tall cabinets into a machine or two (or whatever) which make up your pharm.

that help? it's a cpu cluster running one application driving multiple cores which in turn each drive a graphics card.

Sorry for the difficulty in explaining. It's a lot easier if I had a pic or two to show you.


thanks for understanding,
C

Chuck
11-29-2008, 10:57 PM
First... hope you all had a great holiday weekend, travelling, relaxing, or whatever.


I downloaded the 508 source by accident, but found it very interesting.... Also got some things working pretty nicely.

Has anyone tried the same and, if so, can we talk about the results you got in pvt ?

Tnx,
C

gopher_yarrowzoo
11-30-2008, 05:50 PM
I'll have to power back on this a bit as well for some reason the fan on my GPU has stopped working so I've got another fan on it to keep it cool but due to where it takes air in, I don't know if I can stand the noise of this at full speed in the same room, we'll see...
Well I don't know how it stopped as well playing a game, when screen flickered oddly and then monitor went to power save I was able to exit game and safely reboot windows. It came back up so thought PSU glitch but then it did it again and so I took the rig apart and dusted it, removed all the crap I could, I even took the card out carefully and check it removing some more dust in the process. I put it back in and made it go to BIOS to check and no fan movement thankfully I had a 2 slot fan cooler so I can put it near enough to keep it cool and it's working so far..

Chuck
11-30-2008, 09:36 PM
Goph,
I ran into that with my sister's pc.. it was full of tumbleweed to the point both the cpu and gpu cooler fans were a mess. The CPU cooler had stopped and GPU was about to seize.

Luckily with CRC spray lube in the can, I got the fine grit out of the bushings/bearings and got it turning again. (I did alcohol wash the CRC over-spray off the main board (GPU) to prevent attracting other dust. The CPU fan was cleaned and washed externally (grateful for screws to remove it).

Then I put in a drop of 'sewing machine oil' (of all things).... and it has worked at full/proper speed since.

I did add a 'tumbleweed dust grill' to the main air intake and mounts on the outer surfaces of the chassis (120 & 90 mm flavors) behind the outer cover. It keeps the main cause.... pet hair/dander/field dust (corn fields all around) from getting inside.

Since then, there have been no complaints, unexplained shutdowns or other quirks with games..... no need to clean out the 'heavy stuff'.... they just externally vacuum the dust grill and give it an air can blast internally every once in a while.

I do similar for my machines if/when an issue pops up... it's always worked.... The Intel, nVidia (GPU + mobo) coolers are tough little fans to recover to easily.

Never had a problem with my AMD's but they are in a different air quality environment and use a sponge-like filter (washed monthly) across the face of the 4U rack units.

Hope that helps.


C.

gopher_yarrowzoo
12-01-2008, 10:09 AM
Thanks Chuck... I'll try that, the thing is it being an AGP card the fan is underneath so a PITA to work on, I'll power down the machine and see what I can see might be a simple fix hopefully else. I guess i'm gonna have to keep the side on it it in future. Time to swap the current "hideaway" I'm using with something a bit more open, or maybe more air flow around about the case...
I'll swap the hideaway even if it looks like a cupboard...

Chuck
12-01-2008, 10:28 AM
Goph,
It should recover well, and quite easily.

I did mistype a bit... I meant to write.....

"... they are tough little fans and easy to recover "..


As for recoverying AGP or even PCIE.... AGP's tend to be a bit harder to get the last bit of oil on, but even if you drip it in and let it run down behind the blades onto the main prop shaft, all will be fine... PCIE's tend to be just a tad easier.

FWIW: my ATI 9800SE (AGP) still works fine and has ad the treatment 1 time.

With regard to putting the 'tumbleweed grill' on the front. Yes, please do keep the side cover on. Compensate for cooling with a 90mm temp controlled fan on the rear (venting out), and a nice 120mm internal of that front metal chassis (so the case metal is sandwiched between the fan and dust grill) have that one drawing in air to positive-pressurize the chassis.

That always does the trick for me, as I have a 120mm in front of each stack of HDs inside the case, behind the foam filter for my 4U cases.

C.

gopher_yarrowzoo
12-01-2008, 01:35 PM
I've managed to get it spinning back up I think the cleaning of it just took it off spindle a little but I will try and oil it, I got an 80 mm fan at the front as that's what I think the vent in the front is made for I got a rear fan as well but the thing is it goes up and up and up as it's in an fairly enclosed space in my hideaway 3 hdd's + dvd reader & a dvd writer don't help the cause either.
:) It's running cool now 50-52 rather than about 60 seen it peek at 62 :cry:

Chuck
12-01-2008, 01:54 PM
Goph,
Sounds good! If you can't get some good oil in there... then even some WD-40 or CRC type 'dribbled' in through the spray hoze/tip does help a lot.

I understand about the HD's and burner.... I have 10 drives on the front face, and then 8 more right behind it. The burner is on the front face. Lastly, there are 4 drives (2x2) mounted in a 3.5" frame which is part of the overhead superstructure and case structural integrity.

If I may suggest, check on T-take (thermal take) fans as some of them are the very quiet 'blower' type which can pull / or push a lot of air.

Re cleaning out the AGP.... i know some of those are a pain to clean... If the ductwork on the ATI 9800 gets clogged, I have a lot of work ahead of me.... sometimes even shoving the compressed air nozzle into the duct and giving it a full blast.

With the amount of heat you have.... Do you have an optional 2nd rear fan? If so, may I suggest a temp regulated one?

Here is what I use.... http://www.thermaltakeusa.com and feel free to browse the site and switch to the appropriate UK/EU site as needed.
The main site is http://www.thermaltake.com and it should auto-switch for you. I use the smart fans with remote sensors.... that way I can put the sensor where needed to pull air out & in at and as needed at the key heat locations.

C