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

[-ck]

If we can get you FPGAs, would you be willing to support those in cgminer?

But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.

[Inaba]

Ok, I'm confused.  I just updated two separate machines:

git pull
make clean
ATISTREAMSDKROOT="/opt/AMD-APP-SDK-v2.4-lnx32/"  CFLAGS="-O2 -Wall -march=native" ./configure --enable-bitforce --bindir="/opt/miners/cgminer" --prefix="/opt/miners/cgminer"
make

Both machines are basically the same... here's what I get as a resulting binary:

Machine 1:

./cgminer --version
cgminer 2.3.4

Machine 2:
./cgminer --version
cgminer 2.3.3


Machine 1 fetch head:

effdbaf2062e54ba220974a9ab364a4f94088d9e        not-for-merge   branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e                branch 'master' of https://github.com/ckolivas/cgminer

Machine 2 fetch head:

effdbaf2062e54ba220974a9ab364a4f94088d9e        not-for-merge   branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e                branch 'master' of https://github.com/ckolivas/cgminer


I am confused...  Anyone have any idea what's up?

[Luke-Jr]

I am confused...  Anyone have any idea what's up?

You "forgot" to re-run autogen. For some reason, cgminer's Makefile doesn't do it.

[Luke-Jr]

If we can get you FPGAs, would you be willing to support those in cgminer?

But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.

The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality?

[Inaba]

Silly me!  I don't normally run autogen when recompiling.  Guess I'll make that habit for cgminer. 

Thanks!

[bulanula]

By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.

I agree with your views.

I don't have any FPGA and don't plan on ever having one.

Maybe start FPGAminer project but let us concentrate on GPUs for now because a majority of miners are using them right now.

FPGA is just a minority ...

[nelisky]

I agree with your views.

I don't have any FPGA and don't plan on ever having one.

Maybe start FPGAminer project but let us concentrate on GPUs for now because a majority of miners are using them right now.

FPGA is just a minority ...

Minority or not, I like cgminer so much I'm supporting ztex there myself. There has been some extra work for ckolivas as I adapt to cgminer's coding style but it is more or less easy to keep most changes separate fromt he main cgminer code. I do think ckolivas' time is best spent making cgminer even better and more stable rather than implementing fpgas there, seeing he is very good in the gpu support, as it is in his personal interest anyway

I think cgminer as a gpu + fpga miner is unbeatable, and I'll do all I can to keep it that way. We can always fork it, but I think as FPGAs become more mainstream it is good for the community as a whole if it stays in the same place.

[Chefnet]

and don't forget the dd-wrt support with it :-)

[nelisky]

and don't forget the dd-wrt support with it :-)

So how does dd-wrt relate to openwrt (which I'm currently using on a tp-link router)?

[Inaba]

Well, you could withdraw support from cgminer... but I think the better course of action is to modularize all of the processor types and abstract them from the cgminer core.

You can then concentrate on developing the cgminer core and the gpu module and others can concentrate on the FPGA, ASIC, etc... modules.  Tear all of the built in code that's in there so far and put it in a separate module for each type of device.  Then call those modules from cgminer to do their thing, have them return the proper data and let the cgminer core handle sending the results/requesting the getworks from the server and displaying the results to the screen.  

[Luke-Jr]

Well, you could withdraw support from cgminer... but I think the better course of action is to modularize all of the processor types and abstract them from the cgminer core.

Yes, that's what I did when I added FPGA support originally. The code is still in the same tree, however.

[-ck]

If we can get you FPGAs, would you be willing to support those in cgminer?

But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.

The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality?

Duly ignored.

[ShadesOfMarble]

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?

[kano]

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?

Yes.
And the pull request I have in at the moment adds Ztex (and the frequency) to the API PGA output
(frequency on the end of course)

[nelisky]

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?

Yes. There are a few things missing still:

- support for quad boards (1.15y)
- suspend
- high speed bitstream upload
- hotplug
- firmware upload (to support hot upgrade and the new bogus firmware feature)
- Support for the latest firmware (120417, bitstream 15d4) - This is already done but waiting on inclusion on the main repository

All of the above will be addressed as time permits. You can use the latest firmware if you compile cgminer yourself, grab it here -> https://github.com/nelisky/cgminer/tree/ztex-120417

There is a lot more I want to do but I've been mining with ztex 1.15x boards on cgminer for roughly one month now and it works great

[bulanula]

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?

Yes. There are a few things missing still:

- support for quad boards (1.15y)
- suspend
- high speed bitstream upload
- hotplug
- firmware upload (to support hot upgrade and the new bogus firmware feature)
- Support for the latest firmware (120417, bitstream 15d4) - This is already done but waiting on inclusion on the main repository

All of the above will be addressed as time permits. You can use the latest firmware if you compile cgminer yourself, grab it here -> https://github.com/nelisky/cgminer/tree/ztex-120417

There is a lot more I want to do but I've been mining with ztex 1.15x boards on cgminer for roughly one month now and it works great

Great stuff !

Just let me know when I can flash my GPU BIOSes without using RBE and using only cgminer.

Also let me know when I can attach cgminer to my grill to cook me some eggs as well !

Too many features in cgminer will not be beneficial for anyone. cgminer is good for one thing : mining.

If you start also allowing it to flash FPGA bitstream and firmware then why not expand it to a household alarm monitor as well etc.

Look at BFL and their "easyminer" software. That is what every FPGA dev should develop instead of piggybacking onto cgminer with puny donations like 10 BTC.

[TheHarbinger]

To many people fighting about what should, or should not be included.  Fighting about what the display should look like, fighting about what information should be displayed and what shouldn't.  This is getting to be a pain in the ass.

ckolivas, it's your baby, do what you want with it.  If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins.  Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000?  Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.

[DeathAndTaxes]

ckolivas, it's your baby, do what you want with it.  If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins.  Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000?  Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.

THIS.

[DeathAndTaxes]

If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0?

If submit-stale = true and  SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.

B is less of a problem but it results in bogus stats.  If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++).  If SS is also being incremented then the same share is being counted twice.

The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0.  It is a low % (say 0.5%) but it should always be 0 right?

On edit:  so I looked at all my rigs.  It seems only "newer" cgminer has SS > 0.
I have some rigs still on cgminer 2.1.2 (BAMT 0.4) they all properly show SS = 0 (one has been running 60 days w/ SS = 0).
I have some rigs on cgminer 2.3.1f (BAMT 0.5) they all have SS > 0.

[bulanula]

If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0.

If submit-stale = true and  SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.

B is less of a problem but it results in bogus stats.  If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++).  If SS is also being incremented then the same share is being counted twice.

The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0.  It is a low % (say 0.5%) but it should always be 0 right?

I have submit stale also on also.

About 700 000 shares total submitted and SS still 0 like it should be.

Strange ...