OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[d3m0n1q_733rz]

I noticed a bug in the CPU miner which was not in the previous versions. If i set the scantime to very high(above 60) eventually the cpu miner runs out of nonces and shit start to happen.

Is that a technical term?

A kid goes to the doctor and says to the doctor, "Hey Doc, I get a little light headed when I've been hanging upside down from the monkey bars for too long."  The doctor replies, "Then don't hang upside down from the monkey bars for so long."
There's a message here.

Honestly, why would anyone use a scantime of over a minute?  Over 30 seconds doesn't really make a lot of sense in my opinion.  15 seconds is better.  Longpolling is best.  Perhaps an error saying 'Error: User is wasting time computing blocks that were solved 30 seconds ago' might suffice?

[1714508913]

1714508913

[1714508913]

1714508913

[dikidera]

Perhaps you did not read that i said CPU miner. For the CPU miner to scan ALL the 4 billion nonces, even 10 minutes are not enough

[-ck]

I'm disappointed to report,losing like 20mh on 6850. Maybe CGMINER is not configured optimally? This is what i'm using as of the moment. -w 256 -g 7 --intensity 9

7 theads per gpu is really not going to help you. Stick with the default of 2. Plus try some other values, like not setting -w or set it to 128 or set intensity to no higher than 8.

[-ck]

This is just a reminder

Hello,

It appears that you use post instead of get when doing Long Polling. That is contradictory to the unofficial spec and really annoying when trying to debug software LP failures.

See https://deepbit.net/longpolling.php

-C00w

That's good to know, thanks. I didn't implement any of the original communications parts that cgminer grew out of, so I had no idea. I'll look into correcting that.

Searched out more discussions on other threads and it was decided this was incorrect. I'm leaving it as is with POST after taking it under advisement from other people since I have no actual opinion on the matter.

[-ck]

Quick bugfix release version 1.2.6:

Source
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.6-1.tar.bz2

(windows build soon hopefully)

- Put a current system status line beneath the total work status line
- Fix a counting error that would prevent cgminer from correctly detecting
situations where getwork was failing - this would cause stalls sometimes
unrecoverably.
- Limit the maximum number of requests that can be put into the queue which
otherwise could get arbitrarily long during a network outage and increase rejects.
- Only count getworks that are real queue requests.
- Allow queued to be zero again since you can now see the queued versus staged value and tune it better. This can also decrease stales.


New status line has the following:
TQ: 2  ST: 2  LS: 0  SS: 0  DW: 0  LW: 0  LO: 0  RF: 0  I: 2

from README:
TQ is Total Queued work items.
ST is STaged work items (ready to use).
LS is Longpoll Staged work items (mandatory new work)
DW is Discarded Work items (work from block no longer valid to work on)
LW is Locally generated Work items (during slow server providing work)
LO is Local generation Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)
I is current Intensity (changes in dynamic mode).

If you find the STaged value is often at zero despite your TQ being high then your server may be slow at providing work and you can use this to tune the number of work items in the queue with -Q. It should always be great than 0 if TQ is greater than 0.

This version is slightly faster on average thanks to not slowing down as often during the getworks

[kripz]

This is just a reminder

Hello,

It appears that you use post instead of get when doing Long Polling. That is contradictory to the unofficial spec and really annoying when trying to debug software LP failures.

See https://deepbit.net/longpolling.php

-C00w

That's good to know, thanks. I didn't implement any of the original communications parts that cgminer grew out of, so I had no idea. I'll look into correcting that.

Searched out more discussions on other threads and it was decided this was incorrect. I'm leaving it as is with POST after taking it under advisement from other people since I have no actual opinion on the matter.

You can both read up here and make a judgement:

http://forum.bitcoin.org/index.php?topic=1721.msg350636#msg350636
http://forum.bitcoin.org/index.php?topic=1721.msg353888#msg353888
http://forum.bitcoin.org/index.php?topic=1721.msg358529#msg358529

ATM there's no right or wrong (imo), either way, like the first post said, it works.

[-ck]

New windows build:
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.6-win32.zip

[-ck]

Updated git tree:

Made the kernel code ever so slightly smaller and faster. It does not appear to be significantly faster unless you squint real hard when looking at the hash rates. Anyway, it's there because it's a good thing [tm]. You'll need to do ./autogen.sh again with this change to the tree if building from git.

More stuff planned when time allows.

[twmz]

I tested the latest git code (excluding the very recent kernel tweak) with a simulated internet conncetion failure:

1. I unplugged my internet for 10 minutes and cleared the DNS cache on my miner and on my proxy server.

2. Shortly after the internet connection went down, cgminer reported that the pool was slow and it started doing generating local work.

3. Shortly after that, there was a message about a submit timing out and being cached.

4. Then I waited 10 minutes.  The miner kept mining (at least hashrates on the display stayed high) the entire time.

5. I plugged the internet back in. 

6. There was a flurry of messages that went by very fast.  I assume these were all the cached share submissions.  I didn't see the ones at the start, but the last set were all rejected/stale (which is expected since there was definitly a new block on the network while I was disconnected).

7. After the flurry, cgminer returned to mining as normal without needing to be restarted (and reported it was resuming communications with the server).

So it appears to work better now than when I had my 4 hour internet outage.   At least as far as I can tell in a 10 minute test (and I can't bring myself to test longer than that).

[-ck]

@ewal: Thanks very much for that test.

I will likely be adding a timeout where it can only do locally generated work for 20 minutes since 10 minutes is the average duration it takes for a new block to appear on the network. Best to not keep mining forever with a real network outage.

[twmz]

6. There was a flurry of messages that went by very fast.  I assume these were all the cached share submissions.  I didn't see the ones at the start, but the last set were all rejected/stale (which is expected since there was definitly a new block on the network while I was disconnected).

I can confirm now that at least some of the flurry of submissions were valid.  I can see on my pool stats page that my hashrate dropped while the internet connection was down, but then shot up to 50% higher than my actual hashrate as soon as it returned.  Since they calculate my hashrate based on accepted shares, I believe this means that I send a hugh backlog of valid shares right when the network returned and that made my 5-minute average hashrate look larger than it actually is.

[-ck]

That's even better news since it confirms the validity of cgminer's ability to continue doing useful work in the network outage. Thanks.

[error]

I get a ton of messages that look like this:

Code:

[2011-07-15 07:36:36] JSON-RPC call failed: {
   "message": "Deepbit.lib.InfoException: Wrong data: checkWork: this nonce already completedpostWork user:XXXXXXXXXX worker: XXXXXX ip:XXXXXXX d
ata=00000001f781eaf6bec739630c886694a7fe9707717795b0debee5470000026a00000000bd1084c92487046be3d5cfdee3ae7ed69ac16d588111f5a796d9bcfdcd23a0ee4e1fed491a0abbcf20f97809000000800000
000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
   "code": -1
}

If I kill cgminer and restart, the problem goes away, so likely not a poolside problem ...

Why is that, I wonder ?

Looks like a stale share. No idea why it's coming out like that, though.

[Paul4games]

ckolivas i still get that error when i'm starting cgminer, any idea on  how to fix it?

[-ck]

Every time i try to run it on my pc(under windows XP SP3 x32) i just get the following error:
http://img195.imageshack.us/img195/1565/screenshot0dq.png

Install the ati amd sdk:
http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx

[ffwd]

win32 v1.2.6 still has problem with combined gpu+cpu mining and with cpu mining.

radeon 5550 + core i3 (should be 60+Mh/s + ~8Mh/s - both overclocked)

"-g 0 -t 4" - cpu threads keep getting restarted every 60 seconds and don't complete any work.
as someone suggested in the previous topic, it would be much more efficient to make all cpu threads work on a single share because otherwise they complete no work at all.

"-g 2 -t 4" - gpu threads are for some reason hogged by cpu and both cpu and gpu don't complete any work.
checked with gpu-z - gpu load stays at 0

Code:

 cgminer version 1.2.6 - Started: [2011-07-15 16:55:35]
--------------------------------------------------------------------------------
 [(5s):114.6  (avg):230.8 Mh/s] [Q:20  A:0  R:0  HW:0  E:0%  U:0.00/m]

 TQ: 1  ST: 1  LS: 0  SS: 0  DW: 3  LW: 0  LO: 0  RF: 0  I: 0
--------------------------------------------------------------------------------
 GPU 0: [1.7 Mh/s] [Q:4  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 0: [229.1 Mh/s] [Q:12  A:0  R:0  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------

[2011-07-15 16:57:08] Attempting to restart thread 2, idle for more than 60 seconds

[2011-07-15 16:57:08] Thread 2 restarted
[2011-07-15 16:57:10] Attempting to restart thread 3, idle for more than 60 seconds

[2011-07-15 16:57:10] Thread 3 restarted
[2011-07-15 16:57:12] Attempting to restart thread 4, idle for more than 60 seconds

[2011-07-15 16:57:12] Thread 4 restarted
[2011-07-15 16:57:14] Attempting to restart thread 5, idle for more than 60 seconds

[2011-07-15 16:57:14] Thread 5 restarted
[2011-07-15 16:57:27] LONGPOLL detected new block on network, flushing work queue

also, intensity on dynamic setting stays 0-1 no matter how long i leave the pc running with all other apps closed. are there any specific conditions for increasing the intensity dynamically?

[Luke-Jr]

Feature request: Support for X-Roll-Ntime (with expire extension and noncerange

This can allow clusters of many CPUs/GPUs to process the same work up to ~4 GH/s.

[-ck]

Updated git tree:

- Disable restarting of CPU mining threads pending further investigation.
- Update longpoll messages.
- Add new block data to status line.
- Fix opencl tests for osx.
- Only do local generation of work if the work item is not stale itself.
- Check for stale work within the mining threads and grab new work if
positive.
- Test for idle network conditions and prevent threads from being restarted
by the watchdog thread under those circumstances.
- Make sure that local work generation does not continue indefinitely by
stopping it after 10 minutes.
- Tweak the kernel to have a shorter path using a 4k buffer and a mask on the
nonce value instead of a compare and loop for a shorter code path.
- Allow queue of zero and make that default again now that we can track how
work is being queued versus staged. This can decrease reject rates.
- Queue precisely the number of mining threads as longpoll_staged after a
new block to not generate local work.

[-ck]

Feature request: Support for X-Roll-Ntime (with expire extension and noncerange

This can allow clusters of many CPUs/GPUs to process the same work up to ~4 GH/s.

x-roll-ntime is supported, but indirectly. The "local generation of work" cgminer does is rolling ntime, and is only done when network connectivity cannot keep up with demand for work. I'm not sure how much I'll be expanding on this feature in the future. I'd be surprised if cgminer couldn't keep massive hashes busy already given how the work is gathered for the worker threads at the moment.

[Luke-Jr]

Feature request: Support for X-Roll-Ntime (with expire extension and noncerange

This can allow clusters of many CPUs/GPUs to process the same work up to ~4 GH/s.

x-roll-ntime is supported, but indirectly. The "local generation of work" cgminer does is rolling ntime, and is only done when network connectivity cannot keep up with demand for work. I'm not sure how much I'll be expanding on this feature in the future. I'd be surprised if cgminer couldn't keep massive hashes busy already given how the work is gathered for the worker threads at the moment.

If a miner only has 10 MH/s, I don't want to waste 4 GH/s worth of work (a full nonce range) on them. Using noncerange allows me to chop that up into pieces and share a single work among 256 different 10 MH/s miners. I don't know how it would affect the CPU mining algorithms, but IIRC having to "finish off" a nonce range on a GPU caused some slowdown, so the poclbm branch with support rolls ntime aggressively to avoid it.