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

[supa]

A built in nice would be nice (badumtish!) for both CPU and GPU.  nice as in scheduling - I want this thread at 40% and this thread at 60% sort of thing.  For both multi-pool participation as well as for non-dedicated miners and/or power peaks.  Another example: if I pay more power during the day, I would like to run at 25% during the day at 100% at night.

The time/date scheduling can be done manually by the user, but the process scheduling would have to be a core part of the application.

Summarized output is what bugs me on a lot of miners.  There's a request somewhere for a poclbm mod.  Almost every miner will just spam the screen with "accepted", "stale", "MHs", blah blah blah.  It would be nice to silence all of that and get a -
[CPU Thread 0 - 2.3MHs, 25% priority, 300 accepted, 25 stale, user: supa, pool: us.eligius.st]
[GPU Thread 0 - 300MHs, 100% priority, 15000 accepted, 100 stale, user: supa, pool: eu.eligius.st]

Summary on keypress or at some update interval (3 minutes?).

Finally, and this is just my personal preference and easy to script if no one else wants it, I would like a simple HTTP interface of stats.  You could quite literally just accept connections on some port (2890?) and send "<html><head>Miner</head><body>300 MHs</body></html>"

If you're using Java, maybe future Tomcat integration?

[NetTecture]

Professional management

Being windows based this would mean:

* Installation via MSI, so I can push it out to machines.
* Windows Service, so it does not require me to start.
* WMI based control, events in event log, statistics via profiler.

Basically a miner I can install and run on a computer that i dont sit in front of with windows without going to hacks like VNC

[LegitBit]

Usage settings would definitely be nice, similar to GUIminer's -s tag. That way you can still use the card while mining at a lower rate.

Also I am willing to test if you feel like kicking it my way. I've got Win 7 64 and a 32 bit station at my disposal with 5830's and a 5770.

[supa]

Usage settings would definitely be nice, similar to GUIminer's -s tag. That way you can still use the card while mining at a lower rate.

Ah, thanks, I couldn't quite find the words to put it as eloquently as you did.  All I could think of was "scheduling."

Something else that came up in another thread - on exit (signal, ctrl-C, etc) could you implement a "soft shutdown" that guarantees any pending blocks are reported ASAP?  I'm not sure how feasible that is for portability or if it would even be helpful, but.... it's worth a mention.

[johncarl]

Great input guys, Im really encouraged by these suggestions.

Honestly, my inital beta will not include a majority of these suggestions, but I certainly want to put some of them into future stages.. and possibly leverage you guys to help.

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

Props for identifying that malicious code and outing that guy

Something else that came up in another thread - on exit (signal, ctrl-C, etc) could you implement a "soft shutdown" that guarantees any pending blocks are reported ASAP?  I'm not sure how feasible that is for portability or if it would even be helpful, but.... it's worth a mention.

Really good idea... I think I may be able to add that for the beta.

[PcChip]

So will you be able to get decent efficiency by using Java?  I suppose it won't hurt the OpenCL Performance, but trying to do a CPU miner would be a waste of time (unless you can just call ufasoft's miner from your program)

Also - to the person requesting lower performance for non-dedicated machines (for using windows, and/or playing games), simply run a lower aggression (3 for 48xx series cards, 4 for 58xx series cards) and you can play DirectX Games in the background with minimal interruption.  I believe the CUDA miner has a similar flag (-f 60 maybe?)

[johncarl]

So will you be able to get decent efficiency by using Java?  I suppose it won't hurt the OpenCL Performance, but trying to do a CPU miner would be a waste of time (unless you can just call ufasoft's miner from your program)

Yes, performance is decent.  There already is a java Miner out there called Diablo if you want to see for yourself.

Even the fastest CPU miners would not hold a candle to a gpu miner, and are arguably a waste of energy, so the one I am including is just a proof of concept.

[LegitBit]

Also - to the person requesting lower performance for non-dedicated machines (for using windows, and/or playing games), simply run a lower aggression (3 for 48xx series cards, 4 for 58xx series cards) and you can play DirectX Games in the background with minimal interruption.  I believe the CUDA miner has a similar flag (-f 60 maybe?)

That often still causes crashes. The -s tag-like funtion also serves to lower temperatures as well.

[johncarl]

Ive posted my code on github:

https://github.com/johncarl81/MeteorMiner

I will post the binary artifact soon, possibly on sourceforge to distribute for the beta.

If you feel adventurous and want to build from source, go right ahead.  Please PM me with questions / issues.

[johncarl]

I sent out messages to the people who have volunteered.  Please let me know if you have any trouble getting to the binary or source and if you have any questions.

Thanks again for your help.

[innervisi0nn]

I sent out messages to the people who have volunteered.  Please let me know if you have any trouble getting to the binary or source and if you have any questions.

Thanks again for your help.

I'd love to beta test with 1800 megahash/s send it my way!

[m3ta]

Ive posted my code on github:

https://github.com/johncarl81/MeteorMiner

I will post the binary artifact soon, possibly on sourceforge to distribute for the beta.

If you feel adventurous and want to build from source, go right ahead.  Please PM me with questions / issues.

That's a 404, Houston.
Project dead already? That was fast.

[fascistmuffin]

Would java even be a good language for a miner since it's an interpreted one (basically executing everything twice)? Would this cause lower hash rates since code will be ran inefficiently?

Note: I hate java and may be a little biased against it. C# for life.

[johncarl]

That's a 404, Houston.
Project dead already? That was fast.

Sorry guys, took my code down for a variety of reasons but I am considering re-posting it.

Would java even be a good language for a miner since it's an interpreted one (basically executing everything twice)? Would this cause lower hash rates since code will be ran inefficiently?

Note: I hate java and may be a little biased against it. C# for life.

Yeah, its a fine solution in this spot.  Check out the Diablo miner if you don't believe it.  Java 4-ever http://www.youtube.com/watch?v=vL1riGEwkFo

If you think the C# scene is being underrepresented here, why don't you create your own C# miner?

[CanaryInTheMine]

Count me in for beta testing!