Bitcoin Forum
December 02, 2016, 06:11:54 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 »  All
  Print  
Author Topic: cgminer - CPU/GPU miner in C for linux/windows  (Read 70725 times)
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 10:20:00 AM
 #61

With 4 vectors, this change actually slows down the hash rate. With 2 vectors it speeds it up, but then I get runs of rejected shares. Not sure why but this is consistent now so I'm reluctant to include it at this stage.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
1480702314
Hero Member
*
Offline Offline

Posts: 1480702314

View Profile Personal Message (Offline)

Ignore
1480702314
Reply with quote  #2

1480702314
Report to moderator
1480702314
Hero Member
*
Offline Offline

Posts: 1480702314

View Profile Personal Message (Offline)

Ignore
1480702314
Reply with quote  #2

1480702314
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
June 27, 2011, 10:22:05 AM
 #62

With 4 vectors, this change actually slows down the hash rate. With 2 vectors it speeds it up, but then I get runs of rejected shares. Not sure why but this is consistent now so I'm reluctant to include it at this stage.
Huh
are you sure?

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 10:26:00 AM
 #63

With 4 vectors, this change actually slows down the hash rate. With 2 vectors it speeds it up, but then I get runs of rejected shares. Not sure why but this is consistent now so I'm reluctant to include it at this stage.
Huh
are you sure?

I can keep trying it on and off to see, but every time so far it has happened. It could well be my pool as they're experiencing technical difficulties, but it's always been the same time I enable it that I get the rejects.

2011-06-27 20:22:46] [173.08 | 191.67 Mhash/s] [81 Accepted] [40 Rejected]

Look at that reject rate. Normally it's <5%

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
June 27, 2011, 10:27:13 AM
 #64

With 4 vectors, this change actually slows down the hash rate. With 2 vectors it speeds it up, but then I get runs of rejected shares. Not sure why but this is consistent now so I'm reluctant to include it at this stage.
Huh
are you sure?

I can keep trying it on and off to see, but every time so far it has happened. It could well be my pool as they're experiencing technical difficulties, but it's always been the same time I enable it that I get the rejects.

2011-06-27 20:22:46] [173.08 | 191.67 Mhash/s] [81 Accepted] [40 Rejected]

Look at that reject rate. Normally it's <5%

I'm running GUIMiner with this change and I see no difference other than slight speed increase

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 10:30:44 AM
 #65

I don't doubt it, and no one else is reporting this issue. The other machine I've tried it on it does give a speed up (with minerd) but this one 6770 I'm using it on reliably spits out tons of rejects when I make this change. It's not a heating issue, the card is at 64 degrees.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 10:42:55 AM
 #66

Maybe it's just my pool. They're having a funky time so that would explain it.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Naven
Newbie
*
Offline Offline

Activity: 21


View Profile
June 27, 2011, 10:48:58 AM
 #67

@ckolivas, could u share daily builds of this minner?

If u got to much BTCs - 1PrbRQReXHTM9uXsivMuKDgbQMqxWxJVzA
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 10:50:48 AM
 #68

@ckolivas, could u share daily builds of this minner?

linux only at this stage, sure I could do that.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 27, 2011, 02:37:09 PM
 #69

Update tree:

I did incorporate that change into my kernel. It turns out that even though my hardware reports 4 as the preferred vector width, it's faster with 2. I assume many people have experienced the same. So I've made the default to be 2 when the hardware says its preferred vector width is anything larger than 1.

I found a little buglet that also would repeat some blocks, thereby artificially raising the hash rate, so the overall rate has dropped slightly (about the same amount it's increased with the other code!).

As for the daily builds, I assume the requester meant windows builds? Most people who have linux will likely be able to build it. It's not building on windows yet, but will in the near future I hope. If you really do want linux binaries, just say the word.

The problem with repeated blocks was my pool not sending me out longpoll information reliably.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
June 27, 2011, 03:42:57 PM
 #70

Update tree:

I did incorporate that change into my kernel. It turns out that even though my hardware reports 4 as the preferred vector width, it's faster with 2.
yeah, same thing in poclbm, window size 128, vectors 2 is the fastest setting for me

burp
Member
**
Offline Offline

Activity: 98


View Profile
June 27, 2011, 05:37:05 PM
 #71

Current status for my dual 5830 setup:

- one poclbm with phatk kernel for each card: 2*308MH/s = 616MH/s
- minerd with 2 threads for each card, gives me 605MH/s

so there is still some room for improvements Smiley
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
June 27, 2011, 06:04:28 PM
 #72

- one poclbm with phatk kernel for each card: 2*308MH/s = 616MH/s
- minerd with 2 threads for each card, gives me 605MH/s

Just for knowledge...  what performance do you get with 1 thread per card?


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
burp
Member
**
Offline Offline

Activity: 98


View Profile
June 27, 2011, 06:11:45 PM
 #73

- one poclbm with phatk kernel for each card: 2*308MH/s = 616MH/s
- minerd with 2 threads for each card, gives me 605MH/s

Just for knowledge...  what performance do you get with 1 thread per card?



About 586MH/s, means 293MH/s per card.

EDIT: Considering minerd uses poclbm kernel (which is slower for me than phatk), minerd might be already on par (with twice the number of threads).
figvam
Jr. Member
*
Offline Offline

Activity: 42


View Profile
June 28, 2011, 08:01:20 AM
 #74

It appears it's not possible to use minerd as a pure CPU miner anymore - setting GPU threads to zero doesn't work.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 28, 2011, 11:38:22 AM
 #75

Updated tree:

I've imported the phatk kernel into minerd. The maximum possible throughput is slightly faster on machines that support amd media ops which is nice. However, even nicer is that on sane intensity levels (including the default value of 4), the throughput is significantly faster now as well. The phatk kernel unfortunately doesn't even work on hardware that doesn't have amd media ops (radeon 4x cards and nvidia) so for now it defaults back to the poclbm kernel.

I've also updated the cpu mining component. Now it tries to keep its work sizes within the log update interval instead of the scan interval so that the hash rate doesn't fluctuate all over the place. It is also possible now to set number of gpu threads to 0 to run minerd as just a cpu miner again.

TODO:
-I want to find ways of allowing even larger settings for intensity that would only be suitable for headless boxes. Currently the code ends up racing too much (with all the parallel processing) and generates far too many rejected blocks when the intensity is set to >10. Making the cl code synchronous would avoid that but it also slows it down, thereby making it pointless to push it further.
-Store binary versions of the kernels that could be loaded faster when restarting the app.
-Any bugfixing remaining.
-Profit.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 28, 2011, 11:57:59 AM
 #76

Sorry for the rude OT question but was that you that maintained the -ck tree? Smiley

Quote
Update tree:

I did incorporate that change into my kernel. It turns out that even though my hardware reports 4 as the preferred vector width, it's faster with 2. I assume many people have experienced the same. So I've made the default to be 2 when the hardware says its preferred vector width is anything larger than 1.

It's due to the high GPR usage, it is high enough to balance the poorer ALUPacking coming from uint2, not uint4 vectors. In fact I found out 3-component vectors to work best and they should be supported by opencl 1.1 standart, but the OpenCL compiler is buggy and generates bad code with uint3. Interlacing uint2 and uint works though Smiley
burp
Member
**
Offline Offline

Activity: 98


View Profile
June 28, 2011, 05:40:28 PM
 #77

OK, it looks very good for me with 1 thread per gpu, intensity 10, and worksize 256. I get 619MH/s in total, means ~609MH/s per card. Rejection rate is at a normal level. For me it seems to be beneficial to increase intensity and worksize in favor of 2 gpu threads (which leads to more rejections for me).

EDIT: Rejection rate for now is higher than with poclbm (equal settings), minerd so far: 10/220 ~ 4.5%, poclbm: 41/2752 ~1.5%
EDIT2: Better results with intensity 8, gives me "just" 617MH/s in total but no rejections for 100 accepted shares so far. Probably the perfect settings for me.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 28, 2011, 08:49:38 PM
 #78

Sorry for the rude OT question but was that you that maintained the -ck tree? Smiley
Not rude at all. Yes it is me and I still do Smiley

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 28, 2011, 09:46:58 PM
 #79

I thought you quit kernel hacking. I've compiled some of your kernels a while ago on my desktop Smiley Had no idea you are into bitcoin stuff and OpenCL. Nice Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 28, 2011, 10:43:30 PM
 #80

I thought you quit kernel hacking. I've compiled some of your kernels a while ago on my desktop Smiley Had no idea you are into bitcoin stuff and OpenCL. Nice Smiley
Actually I'm very new to opencl and bitcoin. Just started a week ago, and had to learn all about opencl. I've put in over a hundred hours on this code already  to get up to speed Tongue

To see what I'm doing with linux kernel, check out http://ck-hack.blogspot.com

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!