From used KWh to hourly usage:

Month kWh/30.33 (Average month is 30.33 days)/24
That's it, you got your hourly usage
So you were correct.

You are using ~137W only, that's amazing for those cards --- and can't be correct most likely. Many computers use @ idle that much.
But you would be getting ~3.95Mhash/W at those figures tho

That wouldn't work but something like this would:

 ______
F FPGA
A FPGA
N FPGA
  -------

and 2-3 side by side. Depending upon the fan size, this would create a 2x2 or 3x3 box, depending upon spacing ofc.

That funnel would fail to work because too small pressure differentiation and airflow speed, for the funnel to force the airflow to spread. Pressure being the more important factor.

Exactly the reason why i opened this thread was that i've not written a SHA256 algorithm from scratch based on documentation (nor studied it), tho i've written some other 10^(10^100) simpler algos.

But my original intent was not to attack SHA256 but rather utilize more of the underlying hardware for even some benefit, even how miniscule a single benefit is. But yeah, i guess it boils down to that.

crazy idea: Why not use a heat pump?

GPU-> Water to Water Heat exchanger -> pump -> GPUs

heat pump "cold side" would be warmed with the GPU temperature, giving you a better efficiency for heating the hot tub, while possibly making the GPUs inlet water temp below ambient, atleast at times.
Add water to air heat exchangers or other components as needed, just a basic crazy idea

Heat pumps can achieve close to even 1:6 ratios of efficiency, and i'm not kidding, there are a lot with those over 1:5 ratio for sale.

But yeah, your power consumption would still increase by at least 800W Plus the cost of making heat pump to heat the hot tub, no idea how much that will be.

Ok, maybe i am not articulating myself clearly enough.

DaT: Those figures were examples, completely from hat, meant to make a point. Plus you misunderstood what i were saying
rjk: Such a lookup of table of finished hashes or something, was not at all my intention.


What i meant, there is cases where at certain situation a certain outcome is certain to 100%.
Expanding THOSE lookups where we know that something will result into something 100% of the time is my intention.

Let's say beginning of the hash is e5da3, and for some statistical miraculous reason if char[0] == e, char[3]==d, char[5] == 3 then char[6] == a when we know that what we are hashing is N characters long.
Or maybe if the beginning of hash is 6be3c118da8acd56 we know the last character is 5, thus cannot be our match.
Or maybe if the first round beginning is 6be3c118da8acd56 we know that next round first 3 chars will be dcc, and therefore not a match.
Pending statistical analysis naturally.

I don't understand why that kind of statistical analysis is so difficult to fathom.
Similar things ARE being done with FPGAs, and probably on the GPU code.

Also, we know the format the original data is in, which might result in some odd coincidences in the resulting double hash.

I would definitively prefer a stand alone unit, if it's convenient to manage.
even 20$ extra for such wouldn't matter at all, because that's saved in electricity costs of having a host to run them, nevermind cost of the host machine ...

Let's assume system with 6x7970 underclocked and undervolted, that is something like 900-1000W usage, let's say 1kW exact.

Enermax platinum costs 330$ for 1200W unit, and seasonic costs 270$
They are running at 83% load.

Enermax report: http://www.plugloadsolutions.com/psu_reports/ENERMAX_EPM1200EWT_ECOS%202585_1200W_Report.pdf
Enermax is actually above 90% still on this load, let's say it's close to it's average of 90.62% at 90.3%

So let's say seasonic does 89.6% (load just above 80% so take just a notch off from 89.9%)

Seasonic usage: 1116W
Enermax usage: 1107W

It's less than 1% difference across the board.

For the dell 750W Platinum at ~400W usage i wouldn't mind paying the extra tho!
6% difference!
24W over a year does add up to 209kWh or around 25-28€ for me.
and it still uses a tiny inefficient high wattage fan oO;

Yeah, underclocking memory is one important step to lower temps (and cut electricity usage).

And i meant more like in a rainbow table fashion, for vast amounts. Like you said, big bandwidth, high latency. but there is also lots of ram.

No one of you actually were talking about what i were talking about. Thinking outside of the box here.

I was thinking utilizing that vast amount of ram AND vast bandwidth.
Like say after round  N compare to a hash table to see if we already have pointers to the end result or N rounds deeper.
And do it at vast amounts of hashes at once.

Say we calculate 1/4th of the double-SHA first for 500million hashes, then compare tables to known bad prefixes first 1/4th which will not result in what we want with a 99.999%+ confidence.
Only the remainder progress further.

There is ALREADY similar optimizations (looking on the FPGA threads), where at step # we know something will not result into what we want, or gives always certain result, part can be skipped.
Here i'm talking about it on a more massive scale. Think of it as "Big Data".
Of course that will require vast amounts of data to be analyzed to spot the cases where this can be done.

If extra latency of even 0.5s happens for 10s worth of work, but it results in 10.6s worth of work there is a net gain with the drawback that your result submitting might be 0.5s later than someone elses, but you complete a little bit more work every 10.5s you will over the long term haul in more results.

Also, another point to look at is that could somehow different parts of the GPU be utilized to achieve same results even if algorithm is totally "bonkers" for SHA, but always returns the correct result, ie. turning part of the algo into floating point operations (which afaik are done in different part, right?), it doesn't matter even if it's as FP operation 10x more expensive, but if it saves 1 cycle from integer operations every 160 cycles, that is already a 0.00625% increase in speed for just that operation if there is sufficient floating point capacity to do that.

I haven't worked on this kind of code, i don't know the exact inner workings of GPU and the code that goes with it, but as a coder it strikes me odd that atleast i don't see discussion about attempts to utilize the unused parts. Optimization is afterall mostly about squeezing the last little bit of work from the underlying hardware, sometimes cutting a step, sometimes adding thousands of steps to utilize additional portion of hardware for a net gain. (Think Memcached and other key-value datastores working in conjunction with MySQL ... or distributing data utilizing bittorrent)

Actually you are probably right, i did not check the ground connector count *whups*
Well, in any case, it's a good idea to also include extra grounding, just for that extra safety margin

You can start by looking at the air thermal transfer rate + surface area formulas. I guess nothing ready as every custom case is... well custom. I'd say just build it and test it.
Just remember that air is actually very poor in thermal transfer, you can actually use air as an insulator if you can stop it from moving ...

I've been thinking of doing the same thing, designed a case, based on single 3W 230mm fan after i get my first boards and got a bit of time on my hands, going to design in 3d and then print the casings. Testing will show how well it works.

But i'm still of a month or couple before doing that, other things to do in regards of mining first.

Doesn't take a genious to do the maths.
If there is 500Th going on, even getting BFL Minirigs (15k $, ~20Ghash/s) at 10% price would require 375 000 000$ to make 50% ... Nevermind the ~3.1MW consumption ...

ehrm, if you only connect the +12V what is going to ground it?
Hence no power delivered as expected, grounding would still happen via mobo and same burning effect will happen if that was required.

Grounding has to happen via some route. Probably the stupidest and most popular misconception/myth about electricity is "Grounding doesn't matter so mcuh, so it's ok if we use this 1mm2 ground with the 16mm2 power cable" (I've actually seen that with cars, barely any grounding, huge positive cable, end result: Burning wires)

Never, ever underestimate the stupidity of a script kiddie.
I just had a script kiddie threaten all kinds of DDoS type of attacks on our business, and even log entries with his IP trying to gain access to one of our control panels, and he threatened under his own name, his full contact details inputted into our system and publicly available, and he hosts warez sites under his real identity.
Googling his name resulted in his facebook, google plus accounts plus a lot of other information confirming his identity.

Script kiddies are the most intellectually challenged, ego driven maniacs you can think of. certain things just don't "compute" for them.

and that's not even the only case, i've seen people bragging about doing DoS type of attacks, under their own real name, all verifiable what has happened, and every bit of evidence pointing to them, like asking to get jailed!

As for 51% attack, as bitcoin grows it becomes even harder and harder to pull of, eventually being near impossible to pull of. Before that point is met, it's just expected that some people might come close to that. But as BTC value drives up, so does miner rewards and that much harder it becomes!

Updated Mhash/€ rates to the table. 7970 is based on quite low Mhash rating, testing will show what will be attained in practice per GPU.

Ignorance is a bliss!

Many pools don't charge a fee, and taking away the very tiny fee of those which has is trivial. You want to calculate based on HW potential, not for particular pool.

I know you guys are far more skilled and knowledgeable in terms of doing this kind of chance, but in the odd chance i had just a different view perspective.

Video cards usually sport a lot of VERY fast RAM as well, so couldn't this be used for portions of the algorithm in a 'rainbow table' fashion.
So for some particularly heavy operation in the SHA256 algorithm, trying to fetch the answer from video card ram, or maybe even system RAM as a fail over.

This has to be a very small portion key=value based store which is pre-generated upon launch, but a costly one, with a very high ratio of processing cost vs. memory needed.

As there is a latency cost, it will likely mean that the code needs to be split into 2 portions from the "look at tables" position, so that results are being cached for the 2nd stage (after lookup) to keep all SPs fully utilized all the time despite increased latency.

This would help utilize more of the (already paid for) hardware for a performance increase.

Ok, i think i recalled wrong :/

Very much true, but still a denial of service exploit does not give full access ... So in this case it's not the case.

I thought the recent RDP exploit was a mere DDoS, and proof of concept was done ~wednesday, far after it became known ... It's not even been "weaponized" yet, so kinda hard for that exploit ...