Topic: python OpenCL bitcoin miner - page 26. (Read 1239035 times)

The -f parameter should fix that travex. I use -f 120 and don't notice any lag. At -f 60 theres slight lag. On my box the performance difference is less than 10% between -f 120 and -f 15.

@momchild or anybody

Someone can tell me which command to lower the GPU usage for this miner ? Since my GPU is always load at 99% (which is a good thing) however every time I want to play a movie or youtube(flash player) , my computer will hang up ! So I guess maybe lower the GPU usage will help ? I'm using ATI HD6970 with newest driver.

Thanks!

The block has been accepted and everything is OK:
http://blockexplorer.com/block/0000000000f4d21aec6a2097008556d0a8341333355ccdce76a0e5a2df083d0e

It takes 120 confirmations for the block to appear in the balance. It will happen is 23 blocks or about 3 hours from now.

1.) Excuse me for this mildly obfuscated code. target[0] and [1] are actually A and B of original target - I'm using them just to pass a made up 32 bit target. If you look at kernel parameters you'll see that target[0] (0xFFFF0000) is passed as G.

2.) G is used in belowOrEquals because I didn't managed to understand why this leads to better/faster assembler I left it there wondering when someone will ask this question.

The "Invalid or Stale" rejection message should be split out into two error messages if possible,

That way miner side can trouble shoot when receiving a lot of these errors. If it is string of stale then it maybe a comms. problem on miner side (or pool connection possibly down).

Alternately, if it is a string of Invalid blocks then it maybe a computation problem on miner side.

A regular trickle of Stale messages indicates just the bad luck of timing and is situation normal (FUBAR).

Either way splitting the error message would speed troubleshooting and save confusing/conflating the two issues.

Hi, I've been solo-mining for about a week with an ATI 5770 getting about 150Mhash/s using poclbm. This morning when I woke up I saw "05/03/2011 05:01:13, 0000f4d2, accepted" had appeared in the console window.. It's now going on 8 hours since then with nothing showing in the bitcoin application and I am wondering if I should be expecting 50btc or otherwise would appreciate any advice to understand what the message means. Thanks a lot

I've been looking at code and now I'm confused, maybe someone can help me out:

At the end of BitcoinMiner.cl (the kernel) there's a condition for outputting a solution candidate:


Now 2 things strike me as odd:

1.) targetH is passed as 0xffff0000 (BitcoinMiner.py around line 293). why not 0? doesn't H have to be 0 even for a difficulty 1 block?

2.) (parts) of the calculation of G is commented out in the kernel code (likely to save some cycles, assuming that G is not going to be needed)...


...but G is used in the solution condition. So since G is some intermediary value of sha256 and targetG is 0, why does this even work?

I'm clearly missing or misunderstanding something and I would be happy if someone took the time to explain what's going on.

It's still quite high. With the default miner ask rate (5 seconds), the normal ratio of stale shares is around ~1-3%.

I'm watching pool console right now and there are no problems, so the higher-than-expected stale rate should be something on your side.

I'm using Linux. And there seems to be no problem now that slush's pool is back up and operating correctly, I'm still getting invalid/stale results but now only about 1 in 10 instead of 9 in 10.

You aren't submitting blocks to pool, you are submitting shares (hashes for difficulty 1). Block confirmation is not related to shares.

BTW, what operating system are you using ? If it's Windows, then you need older version of python miner to work with 5970s.

Yes, this was an temporary issue of the pool, bitcoin client crashed for no particular reason. Now it is OK.


Yes, there is difference between those pools. My pool is analyzing every submitted share in realtime and deepbit accept all submits and analyze them later. So the fact that you see more stale shares in my pool is not a bug, it is a feature.

But yes, the thing you reported was an issue of the pool, it's without debate.

Use stream 2.1... in my experience it has almost no cpu usage when GPU mining, and 2.2 and 2.3 both eat cpu.  I'm running linux, but windows users have reported similar circumstances.

OK, first off I need to thank you for making this miner. It's giving me much better performance than DiabloMiner ,which for some reason was giving me less than 40 Million Hashes per second with two 5970's, using all four graphics cores.

However, I'm seeing a huge parade of invalid/stale results when I run the miner, with a few accepted results between them (About 80% of results are invalid/stale). I've tried down-clocking the cores (they are running at 625 MHz now), removing the -v option, removing the -f option, and decreasing the work-unit size. Nothing seems to have helped it much. ATIConfig reports all core temperatures below 70 Celsius. I'm mining with slush's pool.

Any ideas as to why this is happening?

EDIT: I tried using Deepbit instead of slush's pool, and all of the invalid/stale results are gone. Is this something to do with using slush's pool, or does the deepbit server work differently? They say that "no block confirmation is needed", but does that mean that I'm still submitting invalid blocks, and that they aren't checking them?

ANOTHER EDIT: Tried changing drivers to Catalyst 10.11, as I read that was more stable and reliable. I am using it with Stream SDK 2.1. Nothing doing.

UNLIMITED EDIT WORKS: Anyone know of a verification program that I can run to ensure that the OpenCL Libraries are installed correctly? I got the list program to run correctly and return all of the GPU cores, but I don't know if there is one that will tell me whether or not the calculations going on in the cores are valid.

I get the right hashes/s, I'm not a noob don't worry I get 600mh/s in fact.

What i was saying is that it uses too much cpu.

Are you getting 500MH/s?

For some reason two of my CPU cores are maxing out with poclbm running on my 5970.

Any ideas anyone?

That's because this miner is GPU-only. It doesn't need the CPU much. It shows 1% here at 300MH/s.

I have a weird problem about cpu utilization.

Using 2x HD6950 with 2 separate process the total cpu utilizzation is around 15%. Starting a 3rd process on the 3rd card makes the cpu utilizzation rise to around 40% (13% each process as shown in the task manager). I'm using an i7 920 atm.

2 5870s at 5850 clocks, so yes, 2 downclocked 5870s, roughly the performance of 5850 x2 in CF. Easily Overclockable to 5870 clocks so that it makes 2 x 5870 speeds