Topic: COMPLETED: Request for an RPC capable fork of cgminer (155 BTC pledged and paid) - page 8. (Read 19357 times)

Looking at the first post, I guess all I need to add is:
* Start/stop/restart individual GPUs (on restart recheck config file for any changes)

But I have no idea what you mean by "(on restart recheck config file for any changes)"


As for this:
* Report any failures (a min of card down & pool not responding)

Well my output reports the CPU/GPU/POOL status but "pool not responding" seems a bit strange?
What could you actually do with that? cgminer deals with that itself.

Since the API isn't a constant connection, rather a request + reply - I'm not sure what the point of that would be.
I guess I could add a buffer in cgminer to keep ERROR messages and return the list since the last time?

Good work kano!

I am working on my Python warpper for cgminer, too. Initial version will be upload later.

It is a RESTful application which will accept JSON format as control / query.

I'll make it support all the miners, like poclbm, phoenix... etc.

https://github.com/kanoi/cgminer

API v0.1

Includes a sample api-example.php

6 files added/changed from current ckolivas master:

main.c, miner.h, AUTHORS, api.c, api-example.php, Makefile.am

(also has the updated linux-usb-cgminer)

OK so this obviously isn't final (though it does work fine for me)

Anyone who can build their own cgminer and is interested could you have a look?

It currently has 3 API commands:
apiversion - returns a version string "0.1"
dev - returns a status string of all the devices (CPU and or GPU)
pool - returns a status string of all the pools

The included PHP file (api-example.php) simply converts the returned string into a data structure
Very simple and very easy in PHP the way I've done it.

No I'm not expecting people to give me bitcoins yet ...

The 3 main questions I have are:
1) what other API commands do people want
2) what parameters should I add to cgminer: --api-port = 4028, --api-address = 127.0.0.1, --api-access = 192.168.5.* and anything else?
the numbers shown are of course examples
(I haven't added any parameters yet)
3) what socket I/O do people want: by this I mean: default port and access restriction.
It currently runs on port 4028 and only listens on 127.0.0.1 - for security reasons of course.

Edit: it does no mutex locking access to the cpu/gpu/pool info since it would appear that is OK
(the current code doesn't appear to do that either)
ckolivas - does that sound correct to you?

Edit2: minor change - it wasn't closing the connection if an invalid command was sent

Edit3: added 'quit' and 'summary'

Thanking you very much. Just for the record, I just checked and the sum total of hashes from all --donation are currently running at 100 Mhash. It usually hovers between 100-200. Note that I intentionally made the percentage err on the conservative side, and it will virtually always be less than what you set it to since I didn't want complaints.

I'll match this...10 for the project and another 5 if it will be mainline.  Has anyone set up an escrow wallet of some sort?


I increased my donation %.  That's just crazy, cgminer is worth more than that.

Obviously I am not referring to this thread regarding comments about Satoshi.
Anyone but a fool can see that no one mentioned Satoshi in it before my comment ...

I believe the bottleneck on pools is bitcoind internal code not the JSON RPC. I do agree JSON is very heavy but for the amounts of data we are dealing with here it is a non-issue.  Personally I wouldn't use JSON but then again I am a windows developer so for interprocess communication my first thoughts are going to be sockets, memory mapped files, or named pipes.

Really the entire bitcoind needs to be built from ground up for high performance.  Using a real multi-user database, multi-core transaction engine, and some sort of higher throughput I/O interface like sockets.  Honestly does anyone think if Amazon accepted Bitcoin they would use the existing bitcoind to process transactions?  The community could use a high performance bitcoind.


Why?  How many I/O do you think need to be made against a single miner instance.  I mean even polling for updated stats once per second is not going to be a bottleneck.  Things like error reporting, changing clocks, and restarting instances are going to happen so infrequently to be even less of a non-issue.


Nobody said that (except you).  The bounty isn't limited to JSON.  However just doing something different for the sake of different is dubious at best.

As far as Satoshi decision.  He likely never saw the rise of mining pools.  At the time he wrote it miners were getting maybe 1 MH/s on current hardware.  Even at 1 GH/s you only need 1 getwork every 4 seconds.  Block changes are only every 600 seconds.  How many transactions per second is a merchant going to need 1 tps = 86,400 orders per day.

He likely didn't have any philosophical attachment to JSON.  He likely chose it for the same reason millions of developers choose it every year.  It is ease to implement and it was capable of the performance required of it.

Honestly if you made a socket based bitcoind you likely could collect quite a bounty from pool operators.  As that I/O pressure is not going to go away.

Is the hardware ID exposed by AMD SDK?  I don't believe it is but I only glanced over AMD SDK and example source code.

Hi!

 I would love to support this... I can give 5 BTCs now.

 And I have a suggestion:

 1- Identify a GPU by its "device ID" (possible?);
 2- Configuration of each GPU based on its ID;
 3- A different "pool / login / worker" per device (fixed by its ID).

 This way, no matter if a GPU is GPU0 or GPU1, the ID will be the same, so its own configurations...

 This can be usefull if we change a GPU slot or add/remove GPUs from a machine.

 It can works more or less like Linux file system UUID, with it, no matter if the device is sda or sdb, the FS UUID will be always the same and the file system will be mounted without any problem if you change the disk connection.

Best,
Thiago

agree +1.

add 15BTC by me if it will be mainline.

... or just use the -T option and pipe it into something ...

Hi Kano, yes i do think more people would use cgminer including myself if it had some type of programming interface to interact with the miner for stats. If you would like to use something other than json/rpc calls, make your case and program it.

I'm asking for this so cgminer can have monitoring tools added to it.

The JSON RPC is also the reason why bitcoin, pools and even ltc have such problems dealing with what amounts to not a lot of data.

LOL time is irrelevant, if I wanted to write it I'd just write it using sockets like I've written many interfaces before.
For web sites it's simple to use sockets between C and PHP so I'm sure it must be simple for ANY other language.
The JSON RPC is written on TOP of sockets I guess usually using CURL since having to write a full HTTP implementation is a pain beyond belief.
CURL/HTTP is a way over complicated interface to use to pass simple data and nothing is gained by using it.

If someone else wants to write it then I guess JSON RPC is what will be used and it will suck badly like the rest of the JSON RPC interfaces spread throughout Bitcoin.

I get and see a lot of responses from people saying how "Satoshi said so thus that's how it should be"
This is another example of it.
He may have been good at maths while he was alive but he certainly sucked at choosing, designing and coding programming interfaces.

Thanks btw 

The bounty certainly is attractive, but it can't make me find the time to do it, and I have no experience with that sort of code. Then again, I also had no experience with bitcoin mining, opencl code, overclocking, curses.... so anything's possible. My willingness to dedicate time is the hardest thing to win over right now. When I did cgminer I had a personal sabbatical with time off work and used the project as part of my need for programming expression. I have not the time now, so I'm not sure if there is much that would make me want to. Bear in mind that even 100 BTC is less than 300 bucks and think how much real contract work pays. I like taking BTC as a concept, and encouraging BTC trade through doing so, but I'm not earning any real money at these prices.

Why does "slow" matter for an app like this? Do you need to send thousands of commands to your miners at once?

JSON RPC is also incredibly easy to implement in just about every language and platform, local or remote.  Socket api's are not as standardized across lots of projects.

What would you propose we use instead of JSON RPC? Now would be the time considering no code has been written yet.

You seriously think that the people who don't use it yet will suddenly change their mind because of this ... or that a lot of people don't already use it?

The JSON RPC must have been designed by people who can't write software.
It's slow due to the ridiculous HTTP overhead it has and it's design looks like someone who wants to talk to a program, not provide information over an API.
Considering how simple it it to create a socket interface I wonder about the naivety of those who chose it for bitcoin.

Since you are in the thread, would you be willing to do the work? If not, what would it take to entice you enough? 

IMHO if this work is done, cgminer will be able to spread like a weed and become the default miner throughout the land.

I'd be happy to pull any code that is done in a satisfactory generalised manner into the main branch.