Topic: [BOUNTY 5BTC] cgminer: add getwork proxy functionality - page 2. (Read 8989 times)

I am working with Linux.

Just tried with a fresh clone of the GIT repository and it worked.

Step-by-Step:
1. ensure you have the required libs installed

2. clone the GIT repository

3. prepare and build

If this fails for you, and you have a different system, please post a bug report at https://github.com/luke-jr/bfgminer/issues

我也遇到了这个问题 ubuntu server ，恳请知道 如何解决？

 CC     bfgminer-httpsrv.o
In file included from httpsrv.c:15:0:
/usr/include/microhttpd.h:497:3: error: unknown type name ‘intptr_t’
/usr/include/microhttpd.h:830:5: error: unknown type name ‘uint64_t’
/usr/include/microhttpd.h:868:46: error: unknown type name ‘uint64_t’
/usr/include/microhttpd.h:893:55: error: unknown type name ‘va_list’
/usr/include/microhttpd.h:1085:57: error: unknown type name ‘uint64_t’
/usr/include/microhttpd.h:1087:57: error: unknown type name ‘MHD_ContentReaderCallback’
/usr/include/microhttpd.h:1197:54: error: unknown type name ‘MHD_PostDataIterator’
make[2]: *** [bfgminer-httpsrv.o] Error 1
make[2]: Leaving directory `/root/bfgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/bfgminer'
make: *** [all] Error 2

thx
yes I have done all pre-reqs

Hard to say what's the issue without knowing your system, but the compiler not knowing standard integer types looks more like a build environment issue than a bfgminer related problem.

Are you aware of the build process required to follow (pre-reqs, autogen, configure, make)? If not, be sure to read the READMEs.


On a side note: there is lots of activity with bfgminer currently as preparation for the upcoming release. As a result, the HEAD in fact does not compile right now, so better wait until the release.

Update: ASICMINER BE blades now fully supported by bfgminer

The problem with the blades observed earlier was caused by the blades requiring a minimum size of the response packets and was fixed with the latest commits to bfgminer. With that, you can operate your blade pointing to a bfgminer instance ran with
and enjoy all the unbeatable pool management and job scheduling features provided by bfg/cgminer.


The GW server feature is built on top of Libmicrohttpd. On Debian based Linux systems install it with
and rebuild bfgminer from GIT sources.

BE blades (or GW clients generally) are identified by their username. If you have more than one blade and configure individual usernames, each will have its own statistics. If otherwise all have the same name, they will show up as one SGW device with cumulative statistics.


Happy Mining!

Yes, exactly.

I am currently looking at it, but it is a PITA to go through protocol traces of JSON-over-HTTP-over-TCP traffic

can i ask if one of those issues with blades are low speed ? im getting like 2.8gh/s from one blade. On stratum proxy at same PC it works ok (max speed)

Luke-Jr implemented the getwork server / proxy functionality, which is now upstream in BFGminer master branch. Bounty paid.

Proxy works as specified and was tested with multiple cascading instances of BFGminer. There are some specific issues with the BE blade open, which will be addressed separately (since they require access to a blade).


Thanks a lot!

Looks good!

So you have an Avalon unit pointing to BFGminer and serving as GW proxy? Then it is basically done

I'd need to check if the AM BE blades' GW implementation is working similarly well, so please let me know when the branch is ready for testing.

Thanks for your time and efforts.

I've got the basic concept working as a new driver for BFGMiner:
Each username creates a new SGW virtual device, and hashrate is measured by shares.
In this case, I have my main dev miner running on SGW 0, and a lucky CPU miner on SGW 1.

I was hoping for feedback of type: "Yeah, that's something I always wanted to do - and now I can get even some coins for it!"

Maybe after the recent exchange rate drop, 5 coins for 5 days of work is not enough as compensation.

But anyhow, I have one develper already looking at it, hope it can be contributed soon to the community.

You scoped it well. There is nothing to feedback.

200+ views, zero feedback

Is this too challenging, or am I missing something?

Developers, miners and geeks,

I need to have a getwork proxy functionality added to cgminer and am willing to pay 5BTC for its development.


Overview
Last year I had 5 computers distributed all over my flat running cgminer to run different types of mining rig. Since each instance operated its own set of pools and work items, I thought it would be a nice feature to have only one of them operating as proxy, i.e. it on one side connects to pools and handles work items and on the other side allow other cgminer instances to connect and get served.

At that time I asked Con how feasible such a feature would be. His response was that it is doable, but since I was the only one requesting it, maybe not worth the work. With the subsequent feature advances in cgminer, I was able to reduce the number of instances to two and gradually refrained from my idea.

Until recently, when it became hot again: I started operating Asicminer BE blades that are interfaced over Ethernet and use getwork as work API. The best way to operate them is to use a Stratum proxy. While generally doable, I miss lots of cgminer features (most relevant: pool backup / recovery, stability, scalability). With that, I realize that the proxy functionality I had in mind before to cascade multiple cgminer instances would also be useful to support BE blades.

I am familiar with cgminer myself and have already a concept of how it could be realized (similar to hotplug_thread()). If I had 5 days of free time in a row, I'd do it myself - but obviously in today's interesting Bitcoin times I don't have it. Therefore I am offering a 5 BTC bounty to the skilled and motivated developer capable to develop that proxy functionality.

Requirements
From a functional point, the requirements should be clear by the title. I need cgminer to be able to

• act as a getwork proxy at a configurable port
• allow getwork based miners to connect (example: other cgminer instances, BE blades)
• keep track of the getwork clients (identified by username)

Initial testing can be accomplished by connecting multiple cgminer instances to the proxy. If required, I can provide wireshark traces of the communication between blades and Stratum proxy; also I will do qualification testing and performance evaluation with a larger scale BE blades setup myself.

Beside the functional requirements, I am asking for

• a cgminer compliant open source license to be used
• the coding style to be kept consistent (wish: Linux kernel coding style)
• sufficient code quality to get integrated into cgminer upstream

Alternative: stand alone proxy
If it makes development and testing easier for you, you are free to derive a getwork proxy component from existing cgminer. That is, this component would only use the pool and work management from cgminer, but not support mining devices itself (which btw. equals a hotplug-enabled cgminer with no active devices). cgminer's main source file is not modular enough to really support such an approach, just noting it here for completeness.

Process
Before you start hacking into your keyboard, please contact me for further details via email (visible from my forum profile).


Thanks,
zefir