|
No wait, it's still not right. Everyone hang on while I fix it properly...
|
|
|
|
Important updated tree: I didn't see the problem. But when I ran it again w/o -D, I saw it after 63. Which got me thinking, when I reported this problem the first time a few days ago I know it was when I had a network hiccup. So I forced a hiccup (ifdown, sleep 5, ifup), but that didn't do it. So, I'm not sure what's up.
Okay that got me thinking and I did some more instrumenting. I seem to have had a logic failure in the queueing of locally generated work, which may have caused this issue! It was also preventing local work generation ever occurring. Please update to the latest tree. |
|
|
|
Updated tree:
Implemented never idle logic. During periods of network or server problems it takes existing work and generates more work from that till the server starts responding properly or fast enough. This means that hash rates should -never- drop now with cgminer.
This is it in action:
[Accepted] [GPU 2] [435.0 Mh/s] [Q:111 A:21 R:0 HW:0 E:19% U:22.20/m]
[2011-07-09 10:26:01] Server not providing work fast enough, generating work locally
[Accepted] [GPU 3] [429.4 Mh/s] [Q:135 A:21 R:1 HW:0 E:16% U:18.13/m]
[2011-07-09 10:26:53] Resumed retrieving work from server
If your network is down for extensive periods eventually this will generate more rejected blocks, but for transient blips this makes a massive difference.
Can you explain this further? So my card just hashes to keep its hash rate up? Why is this needed? I think i'd rater save power than generate rejected blocks. Until the next block is solved, which happens every ten minutes on average, there is a valid way to take existing work from your pool, modify it and make it new work for your machine. The shares generated from solving that work are actually valid if returned to the server before the next block is solved. Thus it is not just consuming power, it is actually generating valid shares by deriving new work off the work received from the pool. |
|
|
|
If you're getting this fairly often: New block detected, possible missed longpoll, flushing work queue Does that mean you should reduce the scan time? If it's not too often, is it okay to just leave it be? I'm on slush's pool, which I think doesn't support longpolling, so seeing the message doesn't surprise me. That's a harmless message that you need do nothing about. It means the automated new block detection which I implemented for cgminer is detecting the block before longpoll is telling it there's a new block. It also means that longpoll is activated, but auto detection is beating it. If longpoll was disabled it would have just said "New block detected, flushing work queue". |
|
|
|
With the current tree, under Linux, SDK 2.4, 6950 card, as soon as I hit 100 accepted blocks it stops getting new work. Any ideas?
That sounds very wrong. Can you do it while running with -D and store the log please? All of my miners are in the thousands of accepted shares. |
|
|
|
|
Updated source.
I cleaned up the output to make it clear what's going on instead of spitting out the meaningless network errors:
When it can not submit work:
[2011-07-09 17:05:11] Upstream communication failure, caching submissions
and it will continue to mine unhindered (either with fresh work it can retrieve or locally generated work) until:
[2011-07-09 17:05:26] Upstream communication resumed, submitting work
and then all the work finished in that time will be pushed upstream. If the work is no longer valid because a new block has since appeared, cgminer knows this since it can detect a block change itself, and will not submit a whole lot of rejects and will instead say:
[2011-07-10 01:19:20] Stale work detected, discarding
This may happen immediately after a longpoll as well, and is harmless, but minimises your reject count.
I've also updated the efficiency and utility values printed to be per-device when reporting on share submissions:
[Accepted] [GPU 1] [411.0 Mh/s] [Q:425 A:410 R:17 HW:0 E:96% U:5.67/m]
[Rejected] [GPU 0] [411.1 Mh/s] [Q:425 A:384 R:24 HW:0 E:90% U:5.31/m]
[Accepted] [GPU 1] [411.1 Mh/s] [Q:426 A:411 R:17 HW:0 E:96% U:5.68/m]
[Accepted] [GPU 0] [410.9 Mh/s] [Q:426 A:385 R:24 HW:0 E:90% U:5.32/m]
[(5s):1696.1 (avg):1643.1 Mh/s] [Q:1704 A:1538 R:81 HW:0 E:90% U:21.25/m]
The status line will continue to be a grand total with overall efficiency and utility.
|
|
|
|
|
Updated tree:
Implemented never idle logic. During periods of network or server problems it takes existing work and generates more work from that till the server starts responding properly or fast enough. This means that hash rates should -never- drop now with cgminer.
This is it in action:
[Accepted] [GPU 2] [435.0 Mh/s] [Q:111 A:21 R:0 HW:0 E:19% U:22.20/m]
[2011-07-09 10:26:01] Server not providing work fast enough, generating work locally
[Accepted] [GPU 3] [429.4 Mh/s] [Q:135 A:21 R:1 HW:0 E:16% U:18.13/m]
[2011-07-09 10:26:53] Resumed retrieving work from server
If your network is down for extensive periods eventually this will generate more rejected blocks, but for transient blips this makes a massive difference.
|
|
|
|
|
Updated tree.
I've included mf's changes (thanks) which add the efficiency and utility columns to the output. Since the output got very busy I've abbreviated it to look like the following (new columns are efficiency and utility):
[(5s):186.5 (avg):204.5 Mh/s] [Q:84 A:83 R:9 HW:0 E:99% U:2.75/m]
I've also added code to put new work into a staging area first where the latest work is examined to see if it belongs to the same block or not. The utility of this is to cope at times when longpoll becomes unreliable, slow or is not supported/working. This minimises the chance of working on stale work under those circumstances and will produce a message like this:
[Accepted] [GPU 0] [192.0 Mh/s] [Q:60 A:50 R:6 HW:0 E:83% U:2.45/m]
[2011-07-07 14:52:01] New block detected, possible missed longpoll, flushing work queue
[Accepted] [GPU 0] [191.8 Mh/s] [Q:64 A:51 R:6 HW:0 E:80% U:2.35/m]
|
|
|
|
|
Yes, I'm more than happy to take code from elsewhere. Just be aware the code is still in heavy flux so make sure you pull before making any changes.
|
|
|
|
[2011-07-06 09:26:27] [188.20 | 188.33 Mhash/s] [1484 Accepted] [21 Rejected] [0 HW errors]
[2011-07-06 09:26:27] [thread 1: 67108864 hashes, 41359356 khash/sec]
[2011-07-06 09:26:27] [thread 0: 50331648 hashes, 31027223 khash/sec]
[2011-07-06 09:26:28] LONGPOLL detected new block
[2011-07-06 09:26:30] getwork thread 1
[2011-07-06 09:26:30] work retrieval failed, exiting gpu mining thread 0
[2011-07-06 09:26:30] [thread 1: 50331648 hashes, 22013848 khash/sec]
[2011-07-06 09:26:30] Failed to tq_push work in workio_get_work
[2011-07-06 09:26:30] Received kill message
[2011-07-06 09:26:30] workio thread dead, exiting.
What happened here? For some reason it was unable to retrieve any work and that's a fatal error, so it aborted cgminer entirely. I've updated the tree to retry getting work up to the configured amount of times (infinite by default) now. |
|
|
|
|
Updated tree:
Reworked the screen update to have a non-scrolling status line and make the stderr log optional.
Updated assembly for 64 bit cpu mining - d3m0n1q thanks a lot. Updated with newer assembly. It seems to be worth 5-10% improvement.
Getting close now to a release. Need to find a way to include the kernel files in distdir and install.
|
|
|
|
Maybe im dreaming, would it be possible to detect a dropped/slow gpu and restart that thread?
Not that this has happened but have happened with the other single instance mine on all gpu hashers.
That shouldn't happen. This miner goes to great lengths to keep the mining threads busy at all times in the face of terrible network connectivity. Unless the pool is down for extended periods it should do what you want already. |
|
|
|
|
Thanks very much. Updated the tree. Please try again.
|
|
|
|
Hey, have you added in the SSE2_x64_atom update yet?
No. Is it stable/working ok? Link? |
|
|
|
Still not possible to build without OpenCL:
In file included from main.c:30:
miner.h:15:19: error: CL/cl.h: No such file or directory
In file included from main.c:30:
miner.h:215: error: expected specifier-qualifier-list before ‘cl_uint’
main.c: In function ‘miner_thread’:
main.c:869: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:880: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:890: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:903: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:913: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:920: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:941: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:943: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:949: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:952: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:963: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:967: error: ‘dev_blk_ctx’ has no member named ‘nonce’
main.c:974: error: ‘dev_blk_ctx’ has no member named ‘nonce’
Did you do ./autogen.sh followed by configure first? If so, what was the output please? |
|
|
|
Is it possible to make it compile without AMD APP SDK? To run it as a pure CPU miner on a machine without any GPU.
Updated tree: It should build now without opencl as a cpuminer only. The help message should say what it is compiled for after it's built. |
|
|
|
|
Updated tree:
Fixed parameter parsing. Now short parameters should work, and it wont crash with invalid parameters.
|
|
|
|
|
Show Posts
