New Miner... possible functionality

[johncarl]

Ive been working on a miner and I have some questions around what people would like to see.

Would multiple cards working in tandem be attractive?  As in, multiple cards working on the same work request.  I am not sure if this would prove to be a faster way to mine, but it is an alternative to running separate miners on separate work requests per gpu.  In addition to this, I have the option of running 1 miner to handle multiple gpus in parallel.

I'm also looking to get some beta testers involved in my miner.  I'm not quite ready for a beta yet, but please ping me if you're interested.

Are there any features that are lacking in the current offering of mining software?

[Zagitta]

I think a GUI would go a long way with a lot of windows people

I don't think making all cards work in tandem is a very good idea because it probably only would result in more trouble than it's worth, much like crossfire/sli did in the beginning when both cards were working on the same frame... It's quite a different senario yes but i still doubt it would be faster :3

[trentzb]

What are you writing in? What platform are you targeting?

[martok]

Realistically, the only thing that really matters is speed. Personally, I'd love to see a good fast miner written in C/C++ but that's just because I could hack on it. Python makes my brain cramp.

[johncarl]

I think a GUI would go a long way with a lot of windows people

I don't think making all cards work in tandem is a very good idea because it probably only would result in more trouble than it's worth, much like crossfire/sli did in the beginning when both cards were working on the same frame... It's quite a different senario yes but i still doubt it would be faster :3

Agreed, a GUI would be nice.. I wonder if I could throw one on.  I know that there is a python based miner with a GUI out there.. haven't tried it though.

I wonder if I could handle the data differently than a crossfire/sli would... certainly at a higher level and simply divide the work chunks (what a gpu mines at a time) between the cards.  Potentially the overhead would be much less than fully integrating the cards together.  Unfortunately I don't have multiple GPUs, so im a little handycap writing this sort of code.  I think I may try it, as an option, but I think the default will simply give each card their own work.

What are you writing in? What platform are you targeting?

I'm writing a Java based miner.  Target platforms are Linux and Windows... Ive heard Mac/OSX doesn't support opencl very well, but I guess it's a target as well.  I use basically the same opencl kernel that poclbm, phoenix and Diablo use.

Realistically, the only thing that really matters is speed. Personally, I'd love to see a good fast miner written in C/C++ but that's just because I could hack on it. Python makes my brain cramp.

Python makes my brain hurt too ;-)

Glad to see some responses to my post.. thought no one was interested ;-)  I'm planning on posting my code on github.. you guys interested in beta testing?

[KnuttyD]

I think a GUI would go a long way with a lot of windows people

I don't think making all cards work in tandem is a very good idea because it probably only would result in more trouble than it's worth, much like crossfire/sli did in the beginning when both cards were working on the same frame... It's quite a different senario yes but i still doubt it would be faster :3

Agreed, a GUI would be nice.. I wonder if I could throw one on.  I know that there is a python based miner with a GUI out there.. haven't tried it though.

I wonder if I could handle the data differently than a crossfire/sli would... certainly at a higher level and simply divide the work chunks (what a gpu mines at a time) between the cards.  Potentially the overhead would be much less than fully integrating the cards together.  Unfortunately I don't have multiple GPUs, so im a little handycap writing this sort of code.  I think I may try it, as an option, but I think the default will simply give each card their own work.

What are you writing in? What platform are you targeting?

I'm writing a Java based miner.  Target platforms are Linux and Windows... Ive heard Mac/OSX doesn't support opencl very well, but I guess it's a target as well.  I use basically the same opencl kernel that poclbm, phoenix and Diablo use.

Realistically, the only thing that really matters is speed. Personally, I'd love to see a good fast miner written in C/C++ but that's just because I could hack on it. Python makes my brain cramp.

Python makes my brain hurt too ;-)

Glad to see some responses to my post.. thought no one was interested ;-)  I'm planning on posting my code on github.. you guys interested in beta testing?

I would love to see a C/C++ miner published!
If you need a beta tester, I can be one.

[timmmay]

I'm keen to beta test.   I have some multi GPU rigs setup which I can test out for you.  If it means finder a more efficient way to mine then all the better for us all

[dikidera]

And a -threads option to specify how many threads we want the GPU to use. It's for fine-tuning the hash output.

[Dobrodav]

Be sure, that you put anough attention to network code. Miner shouldnt loss data sended to pool.
Miner shouldnt overload pooll with requests, if it did not get answer immediatly.

[fasti]

Combining all GPU's to work like 1 big GPU would give advantage for quick rounds for sure, if there is no performance hit for combining them.

[johncarl]

Quick update:

Just about ready for this beta with some good results on my end.  I will probably be contacting people that responded in the coming days to set up some trials.

Here are the features I have included so far:

gpu and cpu mining
multiple gpu support
long poll
multiple theads per gpu
various timeout parameters: getwork timeout, error timeout
tandem mining.

There is also no perceived performance difference when mining in tandem vs mining in parallel... at least with my 1 gpu and multiple cpu miners

Ive also put some work into unit / integration testing and archetecting the application, which I think has some merit.

All that being said, I would say my mining speed is comparable with all the other top miners.

Also, I have not focused on some of the more gpu / kernel specific compilation parameters (LOOPS, BFI_INT, etc), but im sure those will be easy to add.

Again, if you're interested in beta testing, contact me.

[[Tycho]]

You may also include this.
https://deepbit.net/failover.php

[johncarl]

You may also include this.
https://deepbit.net/failover.php

That should be pretty easy to add... I'll get on that immediately.  Is this a new feature for deepbit and do the other pools implement this protocol?

[licutis]

Have you looked into adding MMP support? http://forum.bitcoin.org/?topic=5210.0

I am also interested in getting in on the beta for this. Have many boxes for the testing.

[[Tycho]]

You may also include this.
https://deepbit.net/failover.php

That should be pretty easy to add... I'll get on that immediately.  Is this a new feature for deepbit and do the other pools implement this protocol?

Currently it's a new feature, but other pools may follow too just like it happened with Long Polling.

[johncarl]

Maybe a possibility to specify a fallback pool, in case the primary pool goes down.

Thats not a bad idea too and may go hand in hand with Tycho's suggestion.  I'll see about adding that too.

[Zagitta]

You can sign me up for beta  got a 4850X2 (dual gpu card) im willing to throw at it

Also i have another suggestion: Add different logging capabilities like logging the mhash/s every x second, temperatur and fan speed logging would be nice too but it might be a hassle if you want to support Nvidia and AMD...

If you follow up on the GUI request it might be nice to add graphs for the logs that opens in a new windo aswell but the primary idea was to log them to a txt file so they could be read by a seperate program if need be

[johncarl]

You can sign me up for beta  got a 4850X2 (dual gpu card) im willing to throw at it

Also i have another suggestion: Add different logging capabilities like logging the mhash/s every x second, temperatur and fan speed logging would be nice too but it might be a hassle if you want to support Nvidia and AMD...

If you follow up on the GUI request it might be nice to add graphs for the logs that opens in a new windo aswell but the primary idea was to log them to a txt file so they could be read by a seperate program if need be

Im pretty sure temperature and fan output would be very hard to make portable across gpu / os.  I think we're going to have to use a separate monitor for those.

Thanks for the input, ill add you to the beta.

[johncarl]

Just read this post:

http://forum.bitcoin.org/index.php?topic=11723.0

I will be providing my code along with the beta, in case anyone would like to inspect for shenanigans :-).  This is one reason I gravitate towards open source.

[Zagitta]

Just read this post:

http://forum.bitcoin.org/index.php?topic=11723.0

I will be providing my code along with the beta, in case anyone would like to inspect for shenanigans :-).  This is one reason I gravitate towards open source.

Thumbs up for your effort in proving your innocense! And for not having me waste my time on decompiling more shit