Bitcoin Forum
December 08, 2025, 11:06:39 AM *
News: Latest Bitcoin Core release: 30.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Other / CPU/GPU Bitcoin mining hardware / Re: Linux GPU Mining - Efficiency and Optimization on: January 17, 2011, 11:14:32 PM
I'm getting ... about 220 on the 6870.

I'm not sure where the data in http://pastebin.com/AvymGnMJ came from. But I was running at about 220 on my 6870. (Using m0mchil's miner under Windows 7.)

If you want a quick boost, you can try overclocking it. I'm not sure what tools are available for Linux to do this. I would typically overclock my 6870 from 950MHz core to 1050MHz, and boost the fan speed to compensate. This was good for about 250Mhash/sec.
2  Bitcoin / Pools / Re: Cooperative mining (>4000Mhash/s, join us!) on: January 06, 2011, 06:50:23 AM
One other suggestion from me, and then I'll shut up...  Think you could implement a way to show the Last Share At date and time to the user's local time, instead of the server's?  See, my last share that went in was at 12:24pm, but on the site it shows 6:24pm (18:24).  Just a suggestion.

Only slush can implement it, but maybe I can be helpful anyway...

I would do it in JavaScript on the client's side. This avoids having to know the user's time zone on the server.

I assume dates in the server are stored as GMT.

So to generate a local time, make the server generate this HTML code:

Code:
<script language="javascript" type="text/javascript">document.write(new Date(Date.UTC(2011, 1, 6, 18, 24, 0)).toLocaleString())</script>

Have your server generate the "real" numbers above.

If the server stores times as milliseconds-since-1970 in GMT, you can do it even easier:

Code:
<script language="javascript" type="text/javascript">document.write(new Date(1297016640000).toLocaleString())</script>
3  Bitcoin / Development & Technical Discussion / Happy with a pool? on: December 21, 2010, 02:01:14 AM
If you haven't been ripped off by a pool server, post here.

(Hey, this thread is just as legitimate as the other one, right?)

I have donated 10BTC to slush for what I consider to be excellent and selfless service.
4  Bitcoin / Development & Technical Discussion / Re: Comparison of GPU's on: December 19, 2010, 12:31:55 AM
I've not spotted how to figure out what hash speed the entire network is searching at? Can anyone link me?

Maybe there's a web page out there that says "the current hash speed of the entire network is..." In the absence of this, we can calculate it.

Assume that the network calculates 6 blocks per hour (i.e. 2016 blocks every 2 weeks).

If we go to http://www.alloscomp.com/bitcoin/calculator.php and play around with it, we discover that 80000000 khash (or 80,000 million hashes) per second equals an average of 10 minutes. Therefore that's my current wild estimate!

(It's probably slightly higher than this, because we're generating more than 6 blocks per hour. Add a bit more.)
5  Bitcoin / Development & Technical Discussion / Re: Comparison of GPU's on: December 18, 2010, 10:28:35 PM
Of course, if the price of bitcoins rises enough, the economics of generation changes completely.

Does anybody have an idea what happen when even strong GPUs won't be profitable? I'm affraid of monopoly of few entities with extremely large processing power. Not because they will accumulate bitcoins, but because of possible fragility of network itself. It should remain p2p somehow.

If it's not profitable for individuals like us, it won't be profitable for monopolies either. Unless they expect to make their profit in different ways.

If ArtForz wishes to spend $200K of his own money on generation hardware, more power to him (pun not intended). Money talks and he is putting it up.

If it were me, I would consider the risk unacceptable of people leaving the system, and Bitcoin collapsing, and being left with $200K of rapidly depreciating and otherwise useless hardware.
6  Bitcoin / Development & Technical Discussion / Re: Comparison of GPU's on: December 18, 2010, 02:11:09 PM
Previously, someone posted this list of GPU performance:

http://golubev.com/gpuest.htm

A rough estimate of Bitcoin hash speed is: take the figure in "Single SHA1 speed" and divide by four. (How's that?)
Wow this is pretty extensive coverage. But I don't get why you'd divide by 4

Why divide by 4? Well, Bitcoin requires you to do two rounds of SHA-1, per operation. And... I don't know, I suspect that Bitcoin requires you to hash a larger amount of data? (Or is that why it requires you to do two rounds?)

@slush: I want to come out +/- 0 in the end, I love playing with new stuff, so it'd be just for entertainment. Problem is that the overhead of buying a new rig is quite high, so I'm trying to find the right balance between expensive GPUs and time to get the investment back.

I don't think it's possible to make back your money. I bought a Radeon 6870 a month ago when the difficulty was 3000, to play Team Fortress 2. I hoped that I could make some bitcoins back to recoup the cost. I did, but now the difficulty is 12000 and increasing rapidly (http://nullvoid.org/bitcoin/difficultiez.php). If you're in it to make money, there isn't a future for you.

The best reason to do this is because electronic cash is an interesting concept (as slush says above), and because you wanted the GPU anyway to play Team Fortress 2 Smiley
7  Bitcoin / Development & Technical Discussion / Re: Comparison of GPU's on: December 18, 2010, 12:34:04 PM
Previously, someone posted this list of GPU performance:

http://golubev.com/gpuest.htm

A rough estimate of Bitcoin hash speed is: take the figure in "Single SHA1 speed" and divide by four. (How's that?)
8  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 09:09:51 PM
Is there any commission going to the pool server? If there is no wonder he doesn't want to release the source; I wouldn't be too happy about doing that either.

Exactly.

Don't ask him to open the source.

Make him an offer. This is Bitcoin...
9  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 01:12:03 PM
32 is not difficulty, it means that target have 32 bits of zeros. You cannot compare this difficulty to global difficulty. 32 bits of zeros leads to ~1-2 blocks at 1000khash/s.

I suspect that 32 bits of zeroes = a difficulty of 1? (i.e. the original and easiest difficulty?)
10  Bitcoin / Pools / Re: Cooperative mining (>1300Mhash/s already, join us!) on: December 16, 2010, 09:00:29 PM
feature request:
would be nice to have the system stats available on the profile-page too,
auto-refresh is not needed, but it would be nice to just open 1page, not 2, to check how big my share is.

I don't know how the web site is coded, but:

It would be nice to have the stats on every page. Maybe in a header, or on the side?
11  Bitcoin / Pools / Re: Cooperative mining (>900Mhash/s already, join us!) on: December 16, 2010, 08:55:56 AM
I was already thinking about how get paid for server resources and I like proposed idea of voluntary continuous donations.

Well, it doesn't even need to be voluntary...

If you release the server code, many people will compete to offer servers. Some people may charge a mandatory 2% fee to cover costs; perhaps some people will charge 1%. It will be competition, and we can choose based on fee, how much we trust them, etc.
12  Bitcoin / Pools / Re: Cooperative mining (>900Mhash/s already, join us!) on: December 16, 2010, 08:11:14 AM
You might like to code this feature:

When we find a block and you pay out bitcoins, allow us to donate a percentage of the reward to you.

For example, I would be happy to donate 5% or 10% of all my bitcoins earned, to compensate you.
13  Bitcoin / Development & Technical Discussion / Re: Selling cuda enabled client on: December 03, 2010, 12:10:29 PM
Scammers, send your funds to an address,
people seeking to get extra coins send 5 times as much clean money to the same address.

For bonus points, occasionally refuse to return the scammers' money!
14  Bitcoin / Mining software (miners) / Re: OpenCL miner for the masses on: November 17, 2010, 09:34:27 PM
I'm using the SHA hashing rate information from golubev's hash tables. His programs brute force attach md5 and sha algorythm's using GPU's. His numbers are extremely accurate and recently updated. Remember we are running two SHA calculations per try.

http://btco.in/4s

Take his single sha1 speed and devide it by 4.5 And somehow I messed it up really nicely, and I now get the 200 mhash/s as well. Must have been sleeping when I did that before.

The other issue is, we are using SHA-256, not SHA-1. This means that we take a further speed penalty... SHA-256 is both more computationally complex (more steps to run) and more data complex (more memory to need to shuffle around).

Not sure how you got a factor of 4.5. I would estimate 2 (due to needing 2 iterations of SHA-256 instead of 1) multiplied by 1.5 (penalty of using SHA-256 instead of SHA-1). So a factor of 3?

Maybe there is room for optimisation in our SHA-256 program, yet!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!