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?https://deepbit.net/failover.php
Topic: New Miner... possible functionality - page 2. (Read 17919 times)
Currently it's a new feature, but other pools may follow too just like it happened with Long Polling.
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.
I am also interested in getting in on the beta for this. Have many boxes for the testing.
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?
You may also include this.
https://deepbit.net/failover.php
https://deepbit.net/failover.php
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.
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.
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.
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.
Miner shouldnt overload pooll with requests, if it did not get answer immediatly.
And a -threads option to specify how many threads we want the GPU to use. It's for fine-tuning the hash output.
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 
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
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.
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
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?
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.
What are you writing in? What platform are you targeting?
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
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
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?
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?
Jump to: