Namachieli



Offline



Activity: 36

Merit: 0







NewbieActivity: 36Merit: 0 [Idea] How to approach a MultiAlgo miner March 22, 2014, 05:36:33 AM #1



The Problem:

There is a serious need for a single miner that can hash multiple algorithms. There are many forks of the incumbent cgminer and we need to have a single miner that can support various algos in a stable and scalable way. (relevant xkcd



Whats in it for me?:

You will be able to take your favorite/current mining OS (Bamt, linux proper, smos, potato, windows) and replace your existing "cgminer" and easily be able to move between coins/algos/pools at a whim.

*controversy* Multipools can now take advantage of switching algo's and coins to further rape and pillage the CryptoCurrency landscape. You may or may not be in favor of this, so let try to not turn this into an argument about multipools.



There is already x project in the works so stfu:

Great! I sure hope so, but it seems like noone has quite done it to the caliber of a static cgminer deployment. The name of the game here is stability and scalability. If anyone else is already close to having this to market then this post just fades out. But if they are stuck, or worse yet, nobody has really gotten anywhere, then maybe this will turn into a great brain storming session.



The approach:

Hopefully you still care at this point, cause this is where we need a community effort!



I do not claim to have an indepth understanding of C, opencl, GPU architecture, why BCX acts like that, or ckolivas' favorite breakfast cereal... but i did compile sgminer to to do keccak one time and i thought that was pretty damn cool.



What needs to be done:

Create a single opencl instruction set that contains all algorithms in a way that they are only parsed when called by the active algo. Something like functions in php (yea i know, php is the only lang i know)

Modify Stratum to support passing a flag or parameter to the client indicating an algo change. Something the VARDIFF mechanism already in use does

Use a single config file to specify what algos are enabled on what pools, and what the devices config should look like for each algorithm. http://pastebin.com/UrgTirjr

How does that help?:

It gives us a way to cleanly replace existing forks, have a single instance of cgminer running at a time, not require GPUs to spin down/up on changes as drastically, not have to restart the whole miner process, and allow new algos to be easily added in by creating the necessary instruction set in the main .cl.



Well shit, how do we do that?:



Fucked if i know man, I told you... If i could do it myself I would. I dont even know if it can work this way.... I'm just throwing out ideas, hoping the community takes hold and something comes of it.



Discuss... First off, this is just an idea session. I dont claim this is perfect. I just want to throw these ideas out in the hopes that it sparks something. If i had the skill to code this myself, I would. This is self moderated to stymie trolling. Please bring your arguments and counter arguments, but lets be civil.There is a serious need for a single miner that can hash multiple algorithms. There are many forks of the incumbent cgminer and we need to have a single miner that can support various algos in a stable and scalable way. (relevant xkcd https://xkcd.com/927/ You will be able to take your favorite/current mining OS (Bamt, linux proper, smos, potato, windows) and replace your existing "cgminer" and easily be able to move between coins/algos/pools at a whim.Multipools can now take advantage of switching algo's and coins to further rape and pillage the CryptoCurrency landscape. You may or may not be in favor of this, so let try to not turn this into an argument about multipools.Great! I sure hope so, but it seems like noone has quite done it to the caliber of a static cgminer deployment. The name of the game here is stability and scalability. If anyone else is already close to having this to market then this post just fades out. But if they are stuck, or worse yet, nobody has really gotten anywhere, then maybe this will turn into a great brain storming session.Hopefully you still care at this point, cause this is where we need a community effort!I do not claim to have an indepth understanding of C, opencl, GPU architecture, why BCX acts like that, or ckolivas' favorite breakfast cereal... but i did compile sgminer to to do keccak one time and i thought that was pretty damn cool.It gives us a way to cleanly replace existing forks, have a single instance of cgminer running at a time, not require GPUs to spin down/up on changes as drastically, not have to restart the whole miner process, and allow new algos to be easily added in by creating the necessary instruction set in the main .cl.Fucked if i know man, I told you... If i could do it myself I would. I dont even know if it can work this way.... I'm just throwing out ideas, hoping the community takes hold and something comes of it.Discuss...