Topic: New .Net Miner (now with GPU and long poll!) - page 2. (Read 8487 times)

@wasabi

I see you said you used Cloo. How did you like that? I had looked at it previously for another project, and I was curious what your impressions were.

Keep up the good work, this is an interesting project for sure!

You don't really yet. It loads and attempts to run every plugin it finds. If the .Gpu assembly is in the same folder as the .exe, it's tested, and runs.

If the .Sse assembly is there, it's tested and runs. Same with .Managed.

Step #1 for me was getting an actual working miner. Next steps are making the thing configurable, usable, etc. I had previously decorated the code with Console.WRiteLIne's for each plugin, so you could see what the hell was going on, but kind of removed them all.

ok.. late night question again: How to set what minerplugin to use - so wether it is GPU or CPU? I dont find the point where it does that..

After looking at the code last night that was my general feeling also. Getting it to compile under Mono would be more groundbreaking than backporting to NET 3.5.

I guess I find myself not too interested in pulling this off, or polluting the code enough to accomplish it. Either way, you are going to be installing this software on other machines. Can either bundle .Net 4 with it, or do something like AOT it with Mono.

I'd be more interested in making it compatible with Mono.

Exactly. Unless you steal the assembly out of the GAC, it is easier to resort to MEF rc3 for backporting.

System.ComponentModel.Composition is MEF.

Actually it should be possible to backport to NET 3.5 and into Visual Studio 2008 as the only NET 4.0 dependency ('System.Componentmodel') could be either replaced with MEF or worked around. I'll take a better look at the scope of changes later tonight.

Oh nevermind. it was late last night i tried to compile - i havent had the Platform SDK installed. Everything is working now. Looks great :0)

Mind giving me the exact message? My guess is you aren't on 64 bit Windows. Which is required. I didn't bother to write a 32 bit version of the SSE crud.

I should probably fix this and just leave SSE disabled.

Looking good, following this thread

Nice project, but i cant compile it (using VS2010) Something about the platform. Do you have any special SDKs linked?

Already did it. Before you posted +1.

+1

I uploaded a built version.

https://github.com/wasabii/BitMaker/downloads

Edit BitMaker.Console.exe.config to set your pool url.

Just added Long Poll support.

Eventually.

@wasabi, could u give us a bin and some instructions how to use it.

I'm also an obsessive commenter, so it should be possible to follow the code. =)

It's still a bit rough of course. I will say this, it is more of an "application" than any of the other miners out there. There's a number of different projects, generating different assemblies, for different components... and the miners are isolated from the main host that drives them, through interfaces and the stuff. It's an actual application, not just a single line script.

The central class is BitMaker.Miner.MinerHost. When you create an instance of this, and invoke Start, it looks up miner plugins, checks to see what resources they consume (CPU, GPUs, etc), and then runs them. If two miner plugins consume the same resource (say, there's an SSE SHA-256 hasher component, and a plain-C# managed hasher component), then it will run them both, check the hashes produced over some time period, and pick the fastest. It does this each launch. Which actually works okay. I'll probably cache this information away somewhere eventually.

BitMaker.Console is a console application that does little more than create a MinerHost and run it. It periodically queries this host for the hash rate, and displays it. Very simple. Not much more than that, yet. I hope for the miner host to eventually raise events about miners starting, stopping, hash rates changing, etc... so that the UI component (either the Console version, or a yet-to-be-produced WPF frontend) can display those as it sees appropriate.

I did this so I can debug the code using the Console version, which is easy to work with, but also host it in a Windows Service.

Right now I am working on restructuring the connections between the MinerHost and the Miner plugins. I'm adding the ability for a IMiner (the miner plugins) to indicate that it requires a Windows "console". That is, a user session that has the ability to access the graphics card. When this is set, the host will actually search the system for the active user session, with access to the GPU, and spawn the Miner in a sub process on that session, communicating back to the host. This way it will run without being logged in, or while switching users. It will basically keep running, regardless what the desktop is used for. If there's no user logged in, it will run on the WinLogon console (at the logon screen). In all cases, no UI will be shown. So, it will infiltrate user processes in order to gain access to the GPU. Thank you MS for not providing GPU access except for at the console.

All of this is designed so I can deploy it across my company's desktops, and regardless whether the user leaves their session logged off, or locked, or logged in, the GPU can be accessed.

Currently I'm running it on my office machines without using GPUs (we don't have any AMD GPUs in the office anyways), using the Windows 7 Task Scheduler, set to only run the BitMaker.Console application when the machine is idle, and to run it as Local Service. So it will do SSE hashing during idle time. It's been running quite well.

Configuration right now is in the App.config file. This obviously needs to move.