Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 593. (Read 5805546 times)

I fully expect that, and Luke-jr's pace of development of FPGA code is faster than I merge it, and I have turned down some of his code which he refused to accept, which is precisely why he has forked it now. So it's easy to see what will happen.

I think people will decide whose is better))

In all honesty I'm sorry to see this, and long term I envision these projects will diverge too much for there to be code going to and from each of them. It may well be that cgminer becomes the dead project and I'll stop maintaining it. Good luck. I know the FPGA miners out there will be happier with you at the helm.

BFGMiner is forked, starting with 2.3.4. Comments etc welcome, but let's not clutter up the CGMiner thread.

Yes. I'll give it a try

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.

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

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.

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

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.

oh, growing pains of open source...

Luke, your idea of true plugins is what this project should gravitate to, you know, miner plugins in separate so/dll libraries, separate config sections for each, one plugin watchdog thread for each pool of plugin miner threads.  IMHO, GPU should go there too.  Core would handle pool and work queue, plugins would put results back to core, core pushes them to pool.  Statistics stay in core etc.

Con wrote his code to achieve one goal.  Write the best, fastest gpu miner, with best statistics and control of all miners out there.  And he achieved his goal.

Fighting with him or Kano about architecture is not going to get you far.  I think the better approach would be for you to start a new
project, call it "modular cgminer" or something like that,  and put your ideas to paper.  Don't wait for Con or Kano for approval.   If they don't want to follow, you lead. Who says it has to be want they want, or if this thing has to stay being written in C.  Use C++ for the rest, keep core in C if you like.  You'll be surprised how fast you'll find similarly minded programmers to help you.  You can derive your work under GNU license, put Con's name on core's code and move on...

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.

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?

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.

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

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).

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

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.

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

Would a properly maintained cgminer fork be sufficient?

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]

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

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 )

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".

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?

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.