New CPU miners request

[ParaplegicRacehorse]

Please add these miners

• cpuminer-multi
• cpuminer-opt
• verium cpu miner
• coinmagi cpu miner

AND / OR

Document how to add our own custom miners (preferably with a base template.) Documenting may encourage others to contribute their miner with pull requests, which would reduce requests for you to add miner software.

[MaynardMiner]

sugarchain is cpuminer-opt. (jayddee version), I switched it out. I tend to just use the latest developed cpuminer-opt, when available. When I first made- sugarchain was it.

cpuminer-opt is an updated version of cpuminer-multi.

verium cpu cannot be generically compiled. i.e. You have to build it directly for the system in question. That is why I have not added it. The miners I have in SWARM now should all be compiled to run on any system (march=x86_64 and no mtune)

I believe coinmagi is very old, and cpuminer-bubasik is faster for m7m.

For the most part, all of them are the same cpuminer-multi- Just forks.

You can essentially just cut/copy the sugarchain.ps1 in the miner/cpu folder, cut/copy the sugarchain.json, and then add the miner to config/update/update.json. You just need to change the paths/algos as necessary.

Example for .ps1:

    if ($(vars).cpu.mycpuminer.$ConfigType) { $Path = "$($(vars).cpu.mycpuminer.$ConfigType)" }
    else { $Path = "None" }
    if ($(vars).cpu.mycpuminer.uri) { $Uri = "$($(vars).cpu.mycpuminer.uri)" }
    else { $Uri = "None" }
    if ($(vars).cpu.mycpuminer.minername) { $MinerName = "$($(vars).cpu.mycpuminer.minername)" }
    else { $MinerName = "None" }

Change all "sugarchain" to "mycpuminer", and then make sure the .json for the miner is called "mycpuminer.json". This is just some. There are a few more references of 'sugarchain' in file.

Then in update folder for cpu:

  "mycpuminer": {
    "name": "mycpuminer",
    "type": "cpu",
    "CPU": ".\\bin\\mycpuminer-1\\cpuminer",
    "minername": "cpuminer",
    "version": "my version",
    "optional": "No",
    "uri": "link to .tar.gz"
  }

[MaynardMiner]

Just a side note- The same can be done for any sgminer or ccminer.

They all use the same API.

[MaynardMiner]

After next release I will take a look around for CPU miners, but at this point right now-

lyra2z330 in next release is going to pound all other miners. It does pretty well. I will have it in the beta testing release tonight. I am still running tests on it in alpha_testing branch.

[ParaplegicRacehorse]

Thanks for that description. I suppose you won't complain much if I scratch my head around your notes and try to build some sort of template (and make a pull request) so others can add their custom miners?

Also, why in the world would I want to run a CPU miner which is not optimized for my CPU by being compiled locally? For Windows, okay it makes sense, but not on Linux. A 2% gain can be the difference between profitable and costly.

Since the mining software all use the same API (isn't bfgminer different?), can I somehow use SWARM -- or RainbowMiner, or MultiPoolMiner, since you all have the same codebase (MultiPoolMiner's?) -- to manage my cluster of ARM SoC boards, running CPU miners? Or my SoCs running ASICs?

:)

Also, out of curiosity, how many of your changes are you pushing to MutliPoolMiner or RainbowMiner? In part, I ask because I just submitted a bunch of similar issues to RainbowMiner. Why there? Because that repo seems way ahead of MultiPoolMiner and SWARM when it comes to supported pools, algorithms, miners, and web management interface; while SWARM is best integrated into mining OSes like Hive and SMOS. And, while I like the idea of single point of management provided by HiveOS and SMOS (and miner.farm and others), I'd much rather host my own management point.

[MaynardMiner]

SWARM was originally a fork of sniffdogminer, known as project MM.Hash (because he disappeared). I made it clear, so that if he wanted to copy he could. However, sniffdog just didn't work in linux right. I ended up re-writing the entire codebase (about 4 times at this point) to make it work. I wasn't aware of multipoolminer at that time. I was aware of RainbowMiner, but they are going a completely different route on what they are doing, some things I like, some things I scratch my head on why. The biggest from what I see is (and I don't follow it that much) that RainbowMiner is an all-in-one source, which means there is little to/no integration in multiple platforms- You use RainbowMiner, and that is it. I focus more on trying to make SWARM require minimal specs (like not even requiring a display-manager, and work from only a terminal, so it can work in OS's like SMOS). I'm not saying what RainbowMiner is doing is bad- It just is different than what I am doing, we are going in two different directions. Both RainbowMiner and SWARM are at this point completely different than multipoolminer. All three use completely different methods in their core application, I would say mine is the most different. The only thing that is the same, is we all use Powershell, but both RainbowMiner and myself both dip into other codebases, such as java and c++ for more features.

SWARM does some pretty dramatically different things in its core application. The entire database is loaded differently, how it controls miners, how it establishes environments, a lot of this is so it can really be an AI, and make decisions to load/unload pools/algorithms/miners when issues arise, per user request. It also filters much more data on the pools in a very quick manner (if you set it up to do so). SWARM is basically just not a fork of these miners anymore- It's too dramatically different to push changes at this point, and keep tabs on what they are doing. Just open up the stat files in SWARM and the stat files in those miners, and you will see what I mean. I use advanced pipeline tactics to be able to generate rolling EMA for timeline pricing, and also give the ability to measure coins rather than the algorithm ports (since algorithm is an average of all coins, and 5 minutes historical, so it can be inaccurate). Both how the database is loaded and math behind it, is completely different.

SWARM has ASIC integration. I don't know about the other miners. If know what you are doing- You can directly install SWARM on an ASIC, or you can manage the ASIC remotely (recommended). SWARM will also not just do ASIC switching, but auto-coin switching for ASIC (on pools that support it).

I have tested SWARM on an ASICs with cgminer (remotely), and it works fine, and I have users using now. I have not had a user test on bfgminer, but from what I gather- The basic api methods for cgminer and bfgminer are pretty much uniform in design, so it should work.

I am not sure about building a 'template' per se, as every miner is usually very different, and some miners can be different between Unix/Windows. You may have to write new API methods, new launch methods, new environments, and maybe even more. If there was a uniform way to add miners to SWARM- trust me it would have been the first thing I wrote. If you come up with a uniform method, I would be more than enthusiastic to accept that pull request- So long as it is uniform in design, and work in both OS's.

And bare in mind- you can add your own made binaries to SWARM by just replacing the downloaded binaries in the .\bin folder. OR you can take a current miner, and just use the version update command. You may just have to add the algorithms to pool-algos.json if it does not exist, or the miner.json in question if it doesn't exist.

But what I can say- Is that SWARM is module based, and most variables are $GLOBAL in scope, meaning you can write you own module which can physically change variables in SWARM while it is running, such as adding miners to $(vars).Miners after it is generated. There is a command to add a module to SWARM.

[MaynardMiner]

Just wanted to note that I am looking into a 'template' idea, which will be incorporated into the GUI, once completed.

My goal is to make it so that proficient users can enter the miner api methods for the miner, as well as enter the launch arguments/environment variables as well. It would be too complicated for a user to understand without having an interface to do it with.

This is a longer term goal, but I am looking into it.

I haven't found any cpu miners in which their cpu kernels are different then the miners in SWARM, so I haven't added any new miners. I have been searching though, but a lot of them are just recycled miners using the same mining kernels, just tweaks in the interface.

The only miner I haven't found is one for binarium-v1. Miners exist, but cannot be generically compiled for any machine, and redistributed.

[MaynardMiner]

cpuminer-opt rplant miner was added.

I am still looking around for cpuminers that are actively maintained. I am more than happy to add miners have either the following:

1.) Can be generically compiled OR can be compiled for all instructions. 2.) Actively Maintained (A commit in the last 6 months). 3.) Does an algorithm that is on a pool supported in SWARM. 4.) No GUI/Disabled GUI.