Sure do, I toe the line on most voltages, but it looks like when everything is running the +12v runs up to 12.05, which is what leads me to think its an overvolt.

Howdy All,  I've been beating my head over this one for 2 days without luck so I'm tagging you guys in.

Machine in question:

Motherboard: Asus M488TD-V EVO
CPU: x6 1090T
PSU: corsair hx1000
GPU1: 5850
GPU2: 5870 (non crossfire, monitors connected to both)
Case: thermaltake element G  (pretty damn high amount of airflow)

The problem:

If mining with GPU1 and I fire up GPU2, immediately I get a loud screech/beep noise that sounds like its coming from the motherboard.

If I fire up GPU2 and not GPU1, no noise.

First thought was thermal issue, so I fired up the usual monitors, and everything appears well inside happy ranges.  When that didn't pan out, I played around some more, and found out if I CPU mine while running either GPU, I can get the screech to occur as well.

So, it is not isolated to just the GPU's, it is not a thermal issue,  powersupply should be more than enough to cover the setup, what am I missing here.  Overvolting the 12v rail because the CPU is a dirty whore?

Big plug here, arduino/offshoots, shields, standard components would be a fantastic thing to spend btc on.

If you look at his post history, all he ever does is complain about the quality if the FREE services people are giving him, either software/pool/whatever.  Seriously, go look at his post history, I can't find a single useful one in there.

BoBR, if I gave you 10 BTC, would you never come back and post in these forums every again?

I see nothing wrong with this, their pool, their rules, rules can be changed at any point.  So long as they are not holding onto any outstanding balance of yours I don't see why they are required to let you use their service. 

It was during the validation station, there were still a good 60 odd validations left before it went invalid.  Nothing new, fairly standard.

Go over to BURP(http://burp.renderfarming.net/) and start a dialog with Janus, he might be able to help a good bit here.  He made a huge attempt to take BURP as a pay to play project and just couldn't make it happen. 

Even with super encryption, the code/engine on the local users machine would need some means to decrypt it to process the work.  The minute that is in place, you're running the risk of someone opening it up.  Some of your examples could have the data-subset which would help a good bit, but others will require the "whole picture" to do any work at all.  Be it a memory scrape, HDD IO watching or various other means, it would not be hard at all to gain access to unencrypted versions of these.

Also, 90% of users who are running a system like this actually want to know what they are doing.  They want the little screensavers showing them proteins folding, or looking at stars etc.  The users also care about HUGE metrics on the various tasks they are doing.  Go checkout some of the BOINC projects like Milkyway@Home, Einstein@Home, Folding@Home. in BURP's example, you can actually see realtime images in the gallery of what you're currently rendering.

I'd love for you to find a means to make it happen, it just seems fairly technically impossible given what you're attempting to do.

I wish you the best of luck here.

Shameless plug here, but those of you with spare CPU cycles, go join Enigma@Home and help read Hitlers mail from WW2....

Not for nothing, but it seems you're pretty much described what BOINC does.  There are pleanty of both public and private boinc projects doing exactly what you describe here.

The biggest issue I've seen as a "for profit" model on this, is many of the companies that would be interested in the service just are unwilling to let their data go out to "anonymous" users, added to the fact that "crypto cracking" can be used for both good and evil purposes and depending on your geographic location, local laws can make that a HUGE no-no for you.

Animation wise, if you go look at the BURP render project you'll see the obvious issue, the only way to partition out the rendering of an animation requires you to send every single model/texture the animation requires.  No company is going to be willing to hand out those assets to "anonymous" people.  It also leads to everyone needs to grab HUGE packages, so then bandwidth starts becoming a giant issue.

Have you tried things such as traceroute to attempt to isolate the issue?

Slush is very much up and working.

HD3650 don't support openCL but they do support Stream, odds are your Pyrit is going into Stream mode and not open CL. 

The entire 3xxx family has no OpenCL support, sadly the SDK tends to report it as a valid device, until you try to go use it.

Since you're limiting yourself to $100, your best option I guess is to try to get a 5830 but you would be better off trying to come up with the difference and getting yourself into a 5850+.

Use a search engine to do a little bit of research, there are plenty of guides for this.

With WinRAR that seems to be true, good catch, with 7zip, my CPU never went over 40%, so pleanty leftover.   If I get some time tonight I'll actually watch the GPU with debuggers to see whats shaking there. 

I f'd up and had a virtual machine running on a mid-range P3 that was generating and it found a block, I was beyond impressed. 0.4Kh/s.

Card by card, and even card manufacturer,motherboard and many other factors in play, toss in different OS/Driver versions and it gets rather complex.  What you're setting here is basically the size of data being pushed to/from the card.  Depending on the ton of variables involved, certain settings work better for one reason or another.

There isn't and can never be a a guide where someone can say for sure "this will do better for you", you really just have to fiddle around and find the best config for your setup. 

Perfect example, I have 2 identical HP machines in terms of hardware/OS, the only thing that differs is graphics driver versions.  On one machine, "-w128" does better than "-v -w64" on the other.

Add WinRar and 7zip to the list.  With WinRAR you seem to get about a 10-15% reduction in hashing, but it also seems to depend on how large the rarset is.  Smaller sets/files seem to be kept at the CPU, but if its a larger (100meg+) set, the GPU gets into the mix.

7zip seems to make use of the GPU no matter what, but reduction was less, 5%-10%.

IE under 7 with the same card has the issue you mention however if I swap to something non-IE it is a non-issue.  Could this be a side effect of the recent GPU/DirectX enhancements to IE FireFox and other browsers don't have an issue with?

Just use FireFox, appears to be a non issue.