Topic: cgminer - CPU/GPU miner in C for linux/windows - page 3. (Read 81916 times)

Seems to be alternating between "Long poll received" and "New block detected" messages now; first the poll message, then the other, sometimes with a second or less between the messages. Here's a sample:


I'm on commit 4bb13bda68fca91a8f96ec3c17cf6f99ecf70342

Edit: before 6:46 I was only getting this message: "LONGPOLL detected new block, flushing work queue", now I'm not getting it at all.

Still having problems, seeing if they'll happen with -D now.

EDIT: -D and 411 requests, 352 accepts and the only odd thing is I start doing work before I have completed a getwork and these cause "HW" errors:

Trying to get the failure again without -D

EDIT2:
That was quick.  Any ideas on how to debug this?

EDIT3: Ah-ha!  Finally: http://pastebin.com/vRQFkmRs

Updated tree:

You can now choose which device(s) to start cgminer on:

--device|-d   Select device to use, (Use repeat -d for multiple devices, default: all)

New windows build of version 1.1.1

http://ck.kolivas.org/apps/cgminer-1.1.1-win32.zip

Updated tree:

Now I've fixed it for real, and incremented the version number and tag to v1.1.1 so people know which is the current good version. Everyone should upgrade.

No wait, it's still not right. Everyone hang on while I fix it properly...

Important updated tree:


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.

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.

OK, I let it go with -D for almost 200 accepted and aside from some odd looking output:

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.

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.

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".

If you're getting this fairly often:
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 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.

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?

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.

Awesome feature

New windows build with latest no-idle logic included.
http://ck.kolivas.org/apps/cgminer-ycros-2011-07-09.zip

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.

Question:  Which is more optimum?
or

Oddly enough, I'm seeing higher optimization using the first set of code which is part of my modifications to the sse2_64_atom code.