cgminer - CPU/GPU miner in C for linux/windows

[-ck]

Temporary breakage... hold on please...

[1714031970]

1714031970

[1714031970]

1714031970

[-ck]

Temporary breakage... hold on please...

I've temporarily backed out the binary loading of kernels till I get it working properly everywhere. A couple of potential fixes have also been committed that could have caused segfaults due to memory dereferencing. It should be stable again but I still have more stuff I want to do...

[burp]

I'm not sure what causes this behaviour but, repeatedly in two nights of running minerd, after some time it just produces rejected shares:

[2011-06-30 08:57:30] [607.75 | 605.73 Mhash/s] [1091 Accepted] [3890 Rejected] [0 HW errors]

EDIT: Just read you discovered that already yourself.

[Tobin]

One more thing. I do not exactly understand how bitcoin generation works but I have noticed the following thing.

oclHashCat-lite (http://www.hashcat.net/oclhashcat-lite/) gives me about ~290M/hash sha256 password bruteforce speed but gpumine only ~120M/hash. Are there any differences with sha256 password bruteforce and bitcoin mining process?
Maybe is it possible to improve the gpumine using kernels from hashcat?

For block generation Bitcoin uses two rounds of sha-256. So one would expect at most half of the speed of oclhashcat, which is in your case 145Mh/s. This explains the huge different. Nonetheless it would be interesting to analyze haschcat's kernels.

[-ck]

I'm not sure what causes this behaviour but, repeatedly in two nights of running minerd, after some time it just produces rejected shares:

[2011-06-30 08:57:30] [607.75 | 605.73 Mhash/s] [1091 Accepted] [3890 Rejected] [0 HW errors]

EDIT: Just read you discovered that already yourself.

Yeah thanks. It's killing me trying to figure out / instrument that as well since it happens only after a long time. There is also a bug with cpu mining at the moment where block submission can cause a segfault. I spent hours and hours coding today and threw out heaps of code. Oh well, there are days like this.

Thanks to the other anonymous donor! If you make a donation and want a specific feature, feel free to drop me a line when you donate and I'll see if I can do it.

[-ck]

Experimenting with this on a single HD5970 (2 GPU cores):

    - I seem to be getting pretty much the same hashing rate as with phoenix
    - The reject rate seems to be much higher though:
         - with phoenix I usually get a reject rate of about 2% of accepted blocks
         - with this, it seems to be around 10%  

Code:

[2011-06-30 10:29:27] [745.63 | 727.37 Mhash/s] [54 Accepted] [6 Rejected] [0 HW errors]

Any idea what's causing this ?

I'm running:

Code:

./minerd                          \
    --intensity 12                \
    --cpu-threads 0               \
    --user $USER                  \
    --pass $PASS                  \
    --url "http://$ADDR:$PORT"    \

There are a few reasons for this. The reject rate goes up if you set the intensity too high on minerd because it can literally take 10 seconds before the gpu returns its results from one single request at high levels! In that time the blocks can get stale. Also, setting the number of gpu threads high basically slows down how long each request takes as well (the purpose for multiple threads is to make sure the gpu remains busy). Finally, some stale blocks are still sneaking through when a new block is detected. I'm working on all of these issues to try and minimise them, but for the time being, you may find less stale blocks with an intensity around 8-9, and the rate doesn't really go up substantially at higher levels anyway.

[-ck]

Keep going down, or try dropping gpu threads to 1 ?

[-ck]

No worries, bear in mind this is still all new code and maturing.

[dc740]

Hi, I'm experimenting with m0mchil python gpu miner, jgarzik cpu miner, and your miner.
I think I can reproduce this "bug", but I don't know why it happens, just that it can be reproduced in slower hardware.
The thing is my CPU gets accepted solutions while my gpu doesn't.
I get 4.8 Mhash on a Geforce 8600GT and 0.9 Mhash on one AMD X2 +4400 core using sse2_64 algorithm. So the math doesn't add up. GPU should be getting more accepted solutions.
The difference is so big that the counter was 17 in the cpu and 0 in the gpu (I'm using deepcoin to track both workers). I restarted the gpu miner, got 3 shares in 20 minutes (it's a slow machine. I'm just experimenting) and then it stopped getting shares completely while the cpu just kept getting accepted solutions.

I'm running jgarzik cpu miner (using 1 cpu core), and m0mchil gpu miner (using the gpu and one cpu core for some reason).

I'm using Ubuntu 11.04 x64, 270 DEV drivers and NVidia CUDA 4.0.
AMD64 X2 +4400 EE

One last thing, I get segmentation faults whenever I try to use your miner.
http://forum.bitcoin.org/index.php?topic=24311.msg303201#msg303201
I used this to compile it:

Code:

LD_LIBRARY_PATH="/usr/local/cuda/lib" CFLAGS="-O3 -Wall -msse2 -I/usr/local/cuda/include" ./configure
make
sudo make install

I know it may be it's just not finding anything, but I really think we are talking about the same bug. How could the GPU find 3 shares in 15 minutes, and then just completely stop getting accepted solutions for 24 hours, while the cpu got 29 accepted solutions in the same time? I really don't know but it is strange because we are talking about pooled mining, if I were mining by my own I would have to way a few decades to find an accepted solution.

[-ck]

The code doesn't support make install yet... You have to run it from the directory where it's built for now. And you happened to try it at an unfortunately quite unstable development time. I'm working very hard at fixing the instability right now.

[-ck]

Updated tree:

The work submission and get work was done from the same "curl" and one would block the other. This would mean that delays on one would delay the other and could slow down processing unnecessarily. While trying to split them into different threads I discovered they would crash on using the same curl so each component has its own thread and own curl now. This should make it much less likely that stalls occur due to poor network connectivity. The separate curl instances may also fix other bugs (like the infinite rejects loop).

I've debugged the binary kernel loading and re-instated it. Now it should be much faster to begin after the first time it is started as it will generate an appropriate binary and then load it thereafter.

Still todo:
I'd like to use the block information received to tell submission threads to not both submitting queued stale blocks after longpoll has informed it of a change.
Find other ways of decreasing stale block rate.
Increase throughput (pipedream).
Start looking at cleaning things up for better building, configuration, windows builds and so on, to perhaps make a real release version.
Lots of other things... but sleep first zzzzz....

[-ck]

Updated tree:

Fixed the high stale block rate. Now it should be equivalent to other miners unless you set the intensity absurdly high.

[theowalpott]

Whats the reason for not including the cpu miner code developed by ufasoft? - Under a 32bit OS, I can get the same using his miner as the SSE2_64 code on a 64-bit OS. Why can't this speed be matched for a 32 bit OS?

[-ck]

Whats the reason for not including the cpu miner code developed by ufasoft? - Under a 32bit OS, I can get the same using his miner as the SSE2_64 code on a 64-bit OS. Why can't this speed be matched for a 32 bit OS?

Cause I'm hopeless with asm. Happy to include it if someone can port the 32 bit assembly to something more portable.

[-ck]

Updated tree:

I put a lot more effort into avoiding rejected blocks. I've reworked the get work code to not require locking and to be flagged itself if longpoll has notified us of a new block. If that happens it will discard and queued work. It also now stores the current block's header once it's known, and on block submission it compares the result being submitted and if it belongs to an older block it will discard it instead of trying to upload it. With these accumulated changes, the block reject rate is lower than ever.

[burp]

Yep, looks much better.

[2011-07-01 22:26:54] [619.73 | 618.90 Mhash/s] [1410 Accepted] [63 Rejected] [0 HW errors]

EDIT: [2011-07-02 12:40:02] [616.28 | 619.13 Mhash/s] [8599 Accepted] [318 Rejected] [0 HW errors]

EDIT2: worksize 256 and intensity 6: [2011-07-02 13:52:44] [612.71 | 617.55 Mhash/s] [233 Accepted] [3 Rejected] [0 HW errors]

Lowest rejection percentage ever

[-ck]

Thanks for your feedback. I believe I fixed the infinite rejects bug as well.

[2011-07-01 23:14:05] [1293.02 | 1065.65 Mhash/s] [5278 Accepted] [160 Rejected] [0 HW errors]

What next...

[Tartarus]

Thanks for your feedback. I believe I fixed the infinite rejects bug as well.

[2011-07-01 23:14:05] [1293.02 | 1065.65 Mhash/s] [5278 Accepted] [160 Rejected] [0 HW errors]

What next...

Locally, the long-term hash rate seems way off.  Looking at 10min worth of scroll-back I see instant rates of between 332MHash/s and 352MHash/s but the long average is 325MHash/s.  This was over a period of at least 3 hours where to start with after 5min or so it was around 342MHash/s, which is what phoenix+phatk show.

[-ck]

Updated tree:

Attribute correct GPU for accepted/rejected shares.
Check again that block hasn't gone stale if trying to resubmit after failed submit.
Make failure to load binary kernel go back to building from source instead of failing to initialise that GPU.
Increase gpu thread count back to 2 by default now that stale block control is more robust. This gives a demonstrable throughput benefit.

Currently working on: Incorporating windows build magic from Ycros (thanks!)

TODO:
Increase buffered work to configurable number instead of just 1 and perhaps default to 2.
Look at those other new kernel changes pointed out by znort987 (thanks!).

[-ck]

Updated tree:

First windows builds courtesy of Ycros (Thanks!)
http://ck.kolivas.org/apps/cpuminer-ycros-2011-07-02-1350.zip

New option
--queue N
how many items of work to queue (default 2)

can speed up higher powered hardware.