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

[DeathAndTaxes]

I have submit stale also on also.

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

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2

[bulanula]

I have submit stale also on also.

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

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2

2.3.3

I only update if I need a feature that is not available in the current release or if the new release brings improvements etc.

No need to use 2.3.4 because I don't run a ZTEX

[DeathAndTaxes]

Hmm.  Let me try 2.3.3 on one of the rigs.

[-ck]

I have submit stale also on also.

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

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2

It was fixed in 2.3.3

[DeathAndTaxes]

It [SS incrementing with submit stale on] was fixed in 2.3.3

Thanks. I can confirm 2.3.4 is working on my system as expected.

Donation coming your way.

[gyverlb]

Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare.
I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins).

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

Couldn't agree more.

[-ck]

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.

Thanks guys, much appreciated comments. As for plugins, the code is already very modular, and true "plugin" architectures written in c aren't really very practical. I will continue to develop the areas I'm most interested in, and find donations very effective at making me interested in things too The bitcoin community on the whole has been generous in that regard, and of course the incentive of a feature being implemented appears to be one of the greatest motivators for donations.

[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?

Duly ignored.

Sorry, I think people have a right to know if their donations really won't affect the status quo of regression you've adopted. I don't know any other way to interpret your response than "I want people to donate to me, but I don't want to change the status quo".

Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare.
I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins).

I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating?

[kano]

Luke - I'm pretty sure everyone (but you) understands what he means by a plugin.
In case you weren't up with current technology, here's an explanation that's not too bad:
http://en.wikipedia.org/wiki/Plug-in_%28computing%29

Edit: ... though you could sort of say that the RPC API is like a plugin
(No I'm not trying to weasel BTC out of nor do I want any BTC from gyverlb's )

[Luke-Jr]

Luke - I'm pretty sure everyone (but you) understands what he means by a plugin.
In case you weren't up with current technology, here's an explanation that's not too bad:
http://en.wikipedia.org/wiki/Plug-in_%28computing%29

Yeah, and that's exactly what I did. What's your point?

[gyverlb]

I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating?

I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves. Some ways to do so I can think of :

• an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
• a binary API that would allow a dynamic library load

A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code. This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things :

• defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)
• passing information from the hardware to the display/log layers of the code in a common way.

I don't care much if the plugin interface is a binary or source one : what matters to me is the ease of maintenance of a separate piece of code. So the interface must completely isolate the internal workings of the plugin and the ones of cgminer only allowing communication through a documented, restricted interface. The complexity (from my point of view, I might overestimate this) is that the interface must be flexible enough that it can accommodate current hardware types and even foreseeable future ones. Questions someone designing the interface could ask herself : « would the plugin interface work without any cgminer code change if I need to write a plugin for an ASIC on a PCIe card/a mining appliance communicating through HTTP ? » ... whatever she can think of.
Retrocompatibility would be nice, cgminer should allow plugins not to answer a subset of the interface (ie: some functions would be mandatory for a plugin and others optional). The actual mining process is obviously mandatory, the statistics reported in the UI/command line parameters might be optional
for example.

Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short.
The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).[/list]

[Luke-Jr]

I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves.

Yep, it does. There have been a few minor API changes since then, but I've tried to retain compatibility.

Some ways to do so I can think of :

• an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
• a binary API that would allow a dynamic library load

A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code.

Ok, it's not too easy (for end users) to add/remove drivers right now. Adding support for that is mostly trivial, though (a dlopen and a driver registration function).

This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things :

• defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)

I think this is already possible, but I haven't tried it yet.

• passing information from the hardware to the display/log layers of the code in a common way.

Yep, this is completely done already. Doing so for JSON API data is also written, but Kano refuses to merge it because he doesn't want outside code providing new stuff for the JSON API or something silly like that.

Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short.

Sure, here is the current driver interface, the original refactoring, and the first FPGA driver.

The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).

Would a properly maintained cgminer fork be sufficient?

[hi]

why do the older version like 2.0.8 run faster then the 2.3.3?  I get 20 million more hashes with same bat file using 2.0.8.

[nelisky]

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.

Thanks for the kind words. It is always great to see the community getting together towards building something that is good and useful for... you

You don't understand open source, that's ok. You do state a lot of good points but then just overdo it and go on to plain and obvious trolling. But I'll bite:

You already have opencl kernels being "pushed" to the GPUs, that's the closest equivalent to the FPGA bitstreams. The firmware is needed because the FPGA interface to its microcontroller isn't standards and changes with bitstreams, sometimes.

Household alarm monitor... yes, proper FPGA handling is too much and unneeded for mining. Why don't we remove LongPoll from cgminer? You can mine without it... not optimal, but hey.

I'm not looking at BFL easyminer for anything, this is a different (and much better imho) product.

Oh, and as for cooking eggs, you can already do that, just crack them on top of your GPUs, cgminer even shows you the optimal cooking temperature!

Reading through your comments I come to the conclusion you don't care about what other people may need from a mining software, so why not ask ckolivas to remove support for every GPU you don't use? That would simplify the code a lot! Also, what's with the "piggybacking" and the puny donations comments? Are you serious? Really?

[nelisky]

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.

Fighting about what others should do for you is stupid, but be careful with your assumptions. Plugin support is not trivial and cgminer is already very modular. You can pretty much compile it to your exact needs.

And I must agree that ckolivas writes great software, it has been a pleasure for me to work on top of it but again, careful with the assumptions. The day ckolivas decided to open source it the baby, while still his, began being parented by many other great tutors. I may not always agree with luke-jr or kano (or ckolivas for that matter ) but luke-jr did a great job improving the modularization of cgminer and creating what became the base for FPGA workers there and kano is making the API better, greater and more useful and everyone combined is finding and fixing bugs that would otherwise be much harder to track if this were a one man show.

ckolivas owns the thing, he knows the code better than anyone else and if it weren't for his great effort we would most likely not have this great piece of software. Major kudos to him!

... but don't make the mistake believing that without everyone else (coders and general community) the code would be the same.

[gyverlb]

The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).

Would a properly maintained cgminer fork be sufficient?

Nope. A fork would be unfair to you (one 40 BTC donation for maintaining a fork with such internal changes is basically a steal) and my goal is not only technical but also to help distribute the work by making it easier (documented stable interface) which may attract new contributors and by helping lift some burden from ckolivas' shoulders.

That said, I recognize your existing contribution is going in the general direction I think is good for the project. So I'll send 4BTC right now to you, 4BTC to ckolivas for including it and leave 32BTC as my pledge for a plugin interface that is integrated by ckolivas.

I'm in a donating mood right now so I'll look at the recent changesets to find other contributors to reward. If you are such a contributor don't be upset if you don't get anything : if I don't think your code is or will be used by me, I won't donate or donate a very small contribution.

[Turbor]

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

[nelisky]

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

There is nothing new on the conf file for ztex, you just need to have them running with a compatible firmware (use BTCMiner or FWLoader from ztex to load it up), which means 15d1 to 15d3 for ckolivas release and if you want 15d4 you'll have to build from source found in https://github.com/nelisky/cgminer/tree/ztex-120417

The boards are detected at cgminer start. Let me know if that doesn't work for you.

[Turbor]

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

There is nothing new on the conf file for ztex, you just need to have them running with a compatible firmware (use BTCMiner or FWLoader from ztex to load it up), which means 15d1 to 15d3 for ckolivas release and if you want 15d4 you'll have to build from source found in https://github.com/nelisky/cgminer/tree/ztex-120417

The boards are detected at cgminer start. Let me know if that doesn't work for you.

Thanks for the info. I use the newest firmware. That seems to be the reason for the errors. Looking forward for the next release.

[nelisky]

Thanks for the info. I use the newest firmware. That seems to be the reason for the errors. Looking forward for the next release.

You can also just use the previous BTCMiner (120221) and flash the 15d3 firmware which will allow you to use cgminer as released right now. There is no speed gain in 15d4 that I can see.