Pages:
Author

Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 21. (Read 1958260 times)

hero member
Activity: 838
Merit: 507
Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?

It is certainly possible, but it would be a bit pointless in my opinion. If a server provides a getblocktemplate method but no submitblock method, then it is violating the official specifications.
PSL
member
Activity: 166
Merit: 10
When cpuminer tries to submit GBT block, block is rejected with 404 error.
Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?
hero member
Activity: 838
Merit: 507
When cpuminer tries to submit GBT block, block is rejected with 404 error.
Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.
PSL
member
Activity: 166
Merit: 10
I am sorry to write this but GBT submit doesn't work. I haven't found any new block from the time I run cpuminer 2.4. When I use "--no-gbt", blocks are found and accepted...

I use powercoin (https://github.com/Powercoin/Powercoin) to test it. Powercoin is dead coin with very low difficulty, good to test solo mining. Powercoin code was not updated for a while so it could be a source of problem but I assume code is good enough to replicate this problem.

When cpuminer tries to submit GBT block, block is rejected with 404 error.
Code:
[2014-05-24 10:42:20] HTTP request failed: The requested URL returned error: 404
[2014-05-24 10:42:20] submit_upstream_work json_rpc_call failed
I tried to mine with "--coinbase-addr=xx" and "--coinbase-addr=xx --coinbase-sig=yy" and blocks are rejected in both cases.

When I mine with "--no-gbt", blocks are accepted
Code:
[2014-05-24 11:02:52] accepted: 1/1 (100.00%), 4.83 khash/s (yay!!!)

Example of "rejected" GBT block:
Code:
[2014-05-24 10:57:55] JSON protocol request:
{"method": "submitblock", "params": ["01000000e65ab64270079fbca476b71bfce63f647b
9fd6ad518606cac7fc1399f0b1602f8f6bd269a664a8b6b0c0db263ee954192316678c33d0c1f9a0
0ee00f1842204f317b805350d9011ea0000de5010100000001000000000000000000000000000000
0000000000000000000000000000000000ffffffff140305c9020f3564656162353063062f503253
482fffffffff0100286bee000000001976a914f650f1ee4beb5f988696abddb3150a9f4bfdb93288
ac00000000"], "id":1}

* Re-using existing connection! (#0) with host powerminer
* Connected to powerminer (54.87.211.179) port 9863 (#0)
* Server auth using Basic with user 'PWC'
> POST / HTTP/1.1
Authorization: Basic TU0uUFdDOjlKUVh1VFVjNmVrNzRGV2EyeUVYN1JIYzg1ckhEV0M3Wkp3bWpCdjdwU3Ni
Host: powerminer:9863
Accept-Encoding: deflate, gzip
Content-Type: application/json
Content-Length: 423
User-Agent: cpuminer/2.4
X-Mining-Extensions: midstate

* The requested URL returned error: 404
* Closing connection #0
hero member
Activity: 838
Merit: 507
I think a simple append of the same line that goes to standard output (e.g. timestamp accepted: X/X (XX.XX%), XX.XX khash/s (yay!!!)) to a separate file will be perfect (at least for what I'm trying to keep track). Any other information related to the specific share could be a bonus for some.
If that's all you need then you could simply grep the output stream or the file where you store the log.
newbie
Activity: 28
Merit: 0
I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.
True, will look into something like that. It will probably be Java, my C skills are beyond rusty.

That's what tee is for. Or you could tail -f the file where the output is stored.
Thanks, will look into it.

This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).
I think a simple append of the same line that goes to standard output (e.g. timestamp accepted: X/X (XX.XX%), XX.XX khash/s (yay!!!)) to a separate file will be perfect (at least for what I'm trying to keep track). Any other information related to the specific share could be a bonus for some.

Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.

(By the way, I just learned that there's a name for the kind of user interface that cgminer sports: TUI, i.e. Textual User Interface.)
Fair enough. You got your tidbit of information for today :-).

Thanks again. And I wish I would have stayed current with my C programming, would love to peek on the code and help a little.

FM
hero member
Activity: 838
Merit: 507
Re API, I think it could be quite useful when you want to manage several PCs remotely. I currently use a combination of proxy (to switch pools), scripts (to restart the miner with # of threads = 50% of cores when someone is going to use that computer) and manual log review to monitor the status. An API that could let you check the status, switch pools and # of threads would be ideal for that.
I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.

Re logging I'm using the 2 >> logfile.log (Windows) at the end of the line to log to a file. This creates the log file but does not output anything to screen.
That's what tee is for. Or you could tail -f the file where the output is stored.

Also a --sharelog option allows you to output the accepted shares on a different file for easier reviewing.
This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).

By dynamic screen I didn't mean a GUI. I'm not sure if you can call what the other miners have a "graphical interface", but I was thinking more like the options to manage pools and processors without having to restart the miner with different parameters. An API could solve this issues too.
Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.

(By the way, I just learned that there's a name for the kind of user interface that cgminer sports: TUI, i.e. Textual User Interface.)
newbie
Activity: 28
Merit: 0
It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.
The hashing code hasn't changed since version 2.3.2, as you can see for yourself from the commit history. Any hash rate variation you might see is purely accidental.
Ok, thanks for the clarification. Maybe I got too exited :-).

Quote
Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).
I'm not sure what you mean by "logging", given that cpuminer has always produced a log.
Regarding APIs and integrated graphical interfaces, they will probably never happen, as I don't think they conform to the KISS philosophy.

I agree with KISS. But that means not adding things when they are not needed. Of course, what's needed varies a lot from person to person. Let me clarify what I meant in my previous post.

Re API, I think it could be quite useful when you want to manage several PCs remotely. I currently use a combination of proxy (to switch pools), scripts (to restart the miner with # of threads = 50% of cores when someone is going to use that computer) and manual log review to monitor the status. An API that could let you check the status, switch pools and # of threads would be ideal for that.

Re logging I'm using the 2 >> logfile.log (Windows) at the end of the line to log to a file. This creates the log file but does not output anything to screen. A -L option like BFGMiner allows you to write to a log file while still seeing the output on the screen, which is sometimes useful. Also a --sharelog option allows you to output the accepted shares on a different file for easier reviewing.

By dynamic screen I didn't mean a GUI. I'm not sure if you can call what the other miners have a "graphical interface", but I was thinking more like the options to manage pools and processors without having to restart the miner with different parameters. An API could solve this issues too.

Maybe, once I mine some coins, I can bribe you include some of these :-).

BTW, thanks for this great miner!


FM

hero member
Activity: 838
Merit: 507
For me, looks to be, the pool is not picking up 2.4 shares.

pooler-cpuminer-2.2.3-win64 works fine.
Quote
[2014-05-22 08:33:03] Stratum detected new block

I see no difference between the log you just posted above and the one you posted before. The message "Stratum detected new block" was changed to "Stratum requested work restart" in version 2.4, as that's a more correct description of what is happening.
Neither of the two logs you've posted so far shows any accepted share.
hero member
Activity: 838
Merit: 507
Code:
Stratum requested work restart

Why?

Because your pool's server sent you new work and asked you to start working on it immediately.
This is usually normal and completely harmless. If you think that a work restart means that your past hashing is now "lost" then you are committing a fallacy, as there is no "progress" when you mine.
hero member
Activity: 838
Merit: 507
It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.
The hashing code hasn't changed since version 2.3.2, as you can see for yourself from the commit history. Any hash rate variation you might see is purely accidental.

Quote
Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).
I'm not sure what you mean by "logging", given that cpuminer has always produced a log.
Regarding APIs and integrated graphical interfaces, they will probably never happen, as I don't think they conform to the KISS philosophy.
newbie
Activity: 28
Merit: 0
It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.

Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).

FM
member
Activity: 70
Merit: 10
hero member
Activity: 838
Merit: 507
What signature is used in the case when it is not specified at cpuminer command line (--coinbase-sig parameter is missing)?
No particular signature is included in the coinbase if you don't specify one. Just the block height as per BIP 34.
PSL
member
Activity: 166
Merit: 10
I have the last point related to signatures that I miss. What signature is used in the case when it is not specified at cpuminer command line (--coinbase-sig parameter is missing)?
hero member
Activity: 838
Merit: 507
Anyway, is it technically possible, to add a parameter that will work like signature but will be used only by miner and will not be published in the block-chain as signature?
No, it is not possible.

Quote
Block-chain, it is huge data structure replicated to millions of disks and every useless ballast there consumes significant disk space...
This is not "ballast". It is something necessary, and actually very small when you consider the size of a block.
The same mechanism is used by poolservers to distribute different work to miners, and even by the old getwork method to ensure that every requested work be unique. And all the extra nonces have always ended up in the block chain.

The truth is, if your signature is short, your coinbases will be smaller than those produced by getwork. Thus, if you are concerned about block size, using a single-byte signature is definitely the best solution (assuming you don't have more than 256 miners).
PSL
member
Activity: 166
Merit: 10
I don't see the problem. The "signature" can be any string you like. For example, if you have three miners, you can use signatures "1", "2" and "3". Signatures don't have to be globally unique, they just need to be different for all miners using the same payout address and mining at the same time.

OK, I don't like the idea to publish ballast that is not important but I can mine with parameters like these:
Code:
--coinbase-addr=$CBADDRESS --coinbase-sig=$(hostname | sha256sum | cut -c1-64)

Anyway, is it technically possible to add a parameter that will work like signature but will be used only by miner and will not be published in the block-chain as signature? Block-chain, it is huge data structure replicated to millions of disks and every useless ballast there consumes significant disk space...
hero member
Activity: 838
Merit: 507
If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.
Thank you for confirmation. That is bad news... I have a problem with a signature, it will be put to blockchain and everyone can see it. Is there other possibility to mine with the same address but without creating public message in the blockchain? Could be this addressed with new parameter that will work like signature but it will not be stored to blockchain? It will be just a local ID for mining client...
I don't see the problem. The "signature" can be any string you like. For example, if you have three miners, you can use signatures "1", "2" and "3". Signatures don't have to be globally unique, they just need to be different for all miners using the same payout address and mining at the same time.
PSL
member
Activity: 166
Merit: 10
Quote
I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, then parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?
Yes. If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.

Thank you for confirmation. That is bad news... I have a problem with a signature, it will be put to blockchain and everyone can see it. Is there other possibility to mine with the same address but without creating public message in the blockchain? Could be this addressed with new parameter that will work like signature but it will not be stored to blockchain? It will be just a local ID for mining client, I can use client hostname or IP address or something like that...
hero member
Activity: 838
Merit: 507
I found that for solo mining with cpuminer V2.4 I have to extend command line with parameter --no-gbt or --coinbase-addr otherwhise it will not connect to the "coin server".
That is correct. If you pass --no-gbt the miner will use the legacy getwork method, so all the block building is handled by the server. If on the other hand you want to use getblocktemplate for solo mining, then you have to provide a payout address.

Quote
I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, then parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?
Yes. If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.
Pages:
Jump to: