OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

[1713252987]

1713252987

[1713252987]

1713252987

[1713252987]

1713252987

[1713252987]

1713252987

[xiangfu]

Hi

I make the Icarus work with cgminer. why I do this, because cgminer is pure C. since I will try to run cgminer in a home router like TP-LINK WR1043ND(400Mhz. 32MB memory. 8MB flash). python miner needs much space. for example it's needs about ~10MB under OpenWrt. so for those
kind of device I would like using cgminer.

The source code is here: (under 'icarus' branch)
  https://github.com/xiangfu/cgminer/tree/icarus

The OpenWrt package Makefile is here:
  http://qi-hw.com/p/openwrt-packages/622aa44

Xiangfu

sorry to bother you, but may i know if it's possible to add a support to Icarus mining board? i'm really not good at software coding. here is the protocol:


Icarus communication protocol

this specification is for anyone who want to write their own miner or want to add support for icarus.

this device is designed as  "the simplest is the best" idea.
the FPGAs on board or even in chain mode (under development) , act as a single miner to the uart port. when the board connect to a PC, it recognized as a ttyUSB device, or "COM*" on windows PC.
how to operate:
1, no detection is needed (no special command for this). 
2, sending work data:
  each data packet is 512bit (64 byte) length. the format is : 256bits MIDSTATE + 160bits fill bits(can be any value) + 96bits data (last 12 bytes of block header). over.
3, sending back the results:
  if the fpga found a valid nonce, they will send back the 32bits nonce result immediately. no any query protocol is implemented here.

so a simple work process is described below:

send a work pass the COM port, start a timer and a listener on the COM port.
if any data send back by the COM port, then this is a valid nonce. push a new work to the FPGA and send the result back to the pool.
if no data send back in 11.3 seconds (a full cover time on 32bit nonce range by 380MH/s speed, maybe increase so a shorter time is suggested, like 8s ), send another work.

some point:
1,FPGA will start the calculate when you push a work to them, even they are busy. that means if a block has been found, the miner could push a new immediately to overlap the old work in the fpga.
2,the 2 fpgas on one board will distribute the 32bit nonce to calculate. one will calculate the 0 ~ 7FFFFFFF, and the other will cover the 80000000 ~ FFFFFFFF. so if you want to do any performance measure on this device, please notice this feature.
3,FPGA will stop work when: a valid nonce has been found or 32 bits nonce range is completely calculated. notice that it's possible for 2 FPGA both find valid nonce in the meantime, the 2 valid nonce will all be send back.


here are 2 version of python miner already can work on Icarus.

https://github.com/ngzhang/Icarus/tree/master/miner_software

hope will get your response, and if there are any problem please let me know.

regards.

[bulanula]

I make the Icarus work with cgminer. why I do this, because cgminer is pure C. since I will try to run cgminer in a home router like TP-LINK WR1043ND(400Mhz. 32MB memory. 8MB flash). python miner needs much space. for example it's needs about ~10MB under OpenWrt. so for those
kind of device I would like using cgminer.

Yeah. That would be quite neat !

I also hate all that python BS and the reason I switched to cgminer in the first place. Python is for lazy programmers who can't code properly IMHO.

[Vbs]

You can install driver & SDK independently.

So you can install driver 11.12 to get the no CPU bug and then SDK 2.1 to maximize performance of 5000 series cards.  Be sure to delete any existing bins and run cgminer to compile bins with SDK 2.1.

Know how to do this on Linux ?

Or shall I just stick with 11.6 and 2.1 ?

Have you tested the difference between 2.4 and 2.1 on your 5970s ? Is it really that much better compared with 2.4/2.5 ?

I have 5870s only.

Thanks !

For my 5850's I'm getting ~400MH/s (Core ~975, Mem 150MHz) with 12.1 driver and SDK 2.5.793.1 (comes with the 11.11 driver), with phatk kernel, vectors 2, worksize 256 and intensity 9. It's much faster for me than SDK 2.1 and poclbm, especially because you can clock down ram so much and bump gpu core speed.

[-ck]

Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?

[bulanula]

Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?

I think we should leave it default 128 as I found that works pretty good as it is.

[BkkCoins]

Hi

I make the Icarus work with cgminer. why I do this, because cgminer is pure C. since I will try to run cgminer in a home router like TP-LINK WR1043ND(400Mhz. 32MB memory. 8MB flash). python miner needs much space. for example it's needs about ~10MB under OpenWrt. so for those
kind of device I would like using cgminer.

The source code is here: (under 'icarus' branch)
  https://github.com/xiangfu/cgminer/tree/icarus

The OpenWrt package Makefile is here:
  http://qi-hw.com/p/openwrt-packages/622aa44

Xiangfu

Awesome to see this. I hope to look at this and adapt to my own project too.

[Vbs]

Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?

Yeah, it's Cypress.

The best worksize really depends on the user correctly setting the ram clock; on the default (1GHz), it's best 64 or 128 with 4 vectors.

V2-W128 is the "safe" bet, since it's almost constant through ram speeds.

V2-W256 is always better than V2-W128 for ram speeds <~425MHz, because even on dips (bad gpu/mem ratio) it's always faster.

Gonna link again the graphic I like so much (from phatk thread)

[-ck]

Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?

Yeah, it's Cypress.

The best worksize really depends on the user correctly setting the ram clock; on the default (1GHz), it's best 64 or 128 with 4 vectors.

Gonna link again the graphic I like so much (from phatk thread)

Yes I remember this old graph. It would appear to me that cgminer's defaults of v2 w128 are the most robust for all tunings unless the user goes out of his way to tweak things manually, in which case he'll be choosing his own settings, thanks.

[Vbs]

Yes I remember this old graph. It would appear to me that cgminer's defaults of v2 w128 are the most robust for all tunings unless the user goes out of his way to tweak things manually, in which case he'll be choosing his own settings, thanks.

Yeah, exactly. Just updated my post to reflect that too.

[Diapolo]

Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?

Should be Cypress, yes. Dunno, what would be the best WORKSIZE default though ...

Thanks for your help with integrating DiaKGCN Con!

Dia

[Diapolo]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

[-ck]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

Tried it, much slower.

[-ck]

Thanks for your help with integrating DiaKGCN Con!

And thank you for the code. Now what advantage is there to reordering the variables passed to the kernel? In commit d86a38d1e75090e1ffb9df9e68aa13b1c8dcf9ec you shuffled arguments which appear to be mostly cosmetic. Would that be right?

[Diapolo]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

Tried it, much slower.

Did you use the code from the latest commits, here on Windows it's definitely faster with -v 2.

-I 9 -k diakgcn -d 0 -v 1 -w 256: ~524 MH/s
-I 9 -k diakgcn -d 0 -v 2 -w 256: ~539 MH/s

Dia

[Diapolo]

Thanks for your help with integrating DiaKGCN Con!

And thank you for the code. Now what advantage is there to reordering the variables passed to the kernel? In commit d86a38d1e75090e1ffb9df9e68aa13b1c8dcf9ec you shuffled arguments which appear to be mostly cosmetic. Would that be right?

That's true for the most part when reordering kernel-arguments to be in line with usage of them in the code, but I think it's part of a clean code, don't you think so?

So you created a new DiaKGCN branch, will this last so I can switch my local repo to that one ?

Dia

[-ck]

Thanks for your help with integrating DiaKGCN Con!

And thank you for the code. Now what advantage is there to reordering the variables passed to the kernel? In commit d86a38d1e75090e1ffb9df9e68aa13b1c8dcf9ec you shuffled arguments which appear to be mostly cosmetic. Would that be right?

That's true for the most part when reordering kernel-arguments to be in line with usage of them in the code, but I think it's part of a clean code, don't you think so?

So you created a new DiaKGCN branch, will this last so I can switch my local repo to that one ?

Dia

Yes, please do, and if things go well, we can have a new default kernel for GCN

[-ck]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

Tried it, much slower.

Did you use the code from the latest commits, here on Windows it's definitely faster with -v 2.

-I 9 -k diakgcn -d 0 -v 1 -w 256: ~524 MH/s
-I 9 -k diakgcn -d 0 -v 2 -w 256: ~539 MH/s

Indeed it is faster now, and with -v 2, it is fastest allow cgminer to choose worksize which is ends up being 128 - it queries the "preferred worksize" and divides that by number of vectors.

You are but 1 Mhash off my current poclbm kernel with that Diakgcn 716.5 versus ck-poclbm 717.5

[Diapolo]

With Diapolo's help we finally got the diakgcn kernel working on cgminer. I've just committed code to the git tree which makes it work. Alas at the same engine and clock speeds on the 7970, diakgcn gives me 699 MHash while my customised kernel gives me 717 MHash. But now that it's working, he may be able to tweak it further...

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

Tried it, much slower.

Did you use the code from the latest commits, here on Windows it's definitely faster with -v 2.

-I 9 -k diakgcn -d 0 -v 1 -w 256: ~524 MH/s
-I 9 -k diakgcn -d 0 -v 2 -w 256: ~539 MH/s

Indeed it is faster now, and with -v 2, it is fastest allow cgminer to choose worksize which is ends up being 128 - it queries the "preferred worksize" and divides that by number of vectors.

You are but 1 Mhash off my current poclbm kernel with that Diakgcn 716.5 versus ck-poclbm 717.5

Sounds not too bad . I will try -w 128 and compare results on my machine ... will report back, which one is faster for me at default clocks and on Win7 x64. I'm happy now!

Dia

[-ck]

You are but 1 Mhash off my current poclbm kernel with that Diakgcn 716.5 versus ck-poclbm 717.5

Sounds not too bad . I will try -w 128 and compare results on my machine ... will report back, which one is faster for me at default clocks and on Win7 x64. I'm happy now!

There is something unusual about it running diakgcn and the hashrate appears to be more unstable, rising and falling more so it takes a while to get a reasonable grasp for what the hashrate really is. Since you're running 2 vectors, it effectively makes the hashrate update half as often as running my poclbm kernel since I use no vectors. Either way, the hashrates are really close.