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

[stridergt]

I am using minepeon (cgminer3.6.4) with a Jalapeno and observing that DAcc (Difficulty Accepted) is 60-85% when mining with the eligius pool and 100-105% when mining with BTCguild. (both pools had min difficulty set to auto, but even when I changed BTCguild to 8+GH/s, the difference in percentage roughly stayed the same)
Can someone elaborate a bit on the Dacc calculation and the difference I am observing between the two pools, does it affect my share contribution accordingly???
I checked github, but I was a bit lost. I also asked at the minepeon forum but the dev just parsed the DAcc value and could not elaborate on the calculation method.

Thank you in advance

Have I asked in the wrong thread? :-)
Please advise if so...

DA is the value in 1diff of all shares accepted.
If you submit 10 50diff shares and all are accepted then DA would be 500

I've no idea what you mean those % numbers are.

https://dl.dropboxusercontent.com/u/109686709/minepeonstats.jpg

The percentage is DAcc / Diff1 as seen in the screenshot, so Diff1 are all shares counted in difficulty1.

Maybe Disc(arded) isn't displayed in difficulty1 so DAcc + DRej + (sum of Disc * difficulty) = Diff1

Am I getting this right? Which means that I had much lower stale percentage depending on the pool.

[1714202797]

1714202797

[1714202797]

1714202797

[1714202797]

1714202797

[1714202797]

1714202797

[drewage]

Trying to run a bifury using the cgminer binary inside the unofficial OS X release.  The bifury shows up as /dev/cu.usbmodemfa131 and /dev/tty.usbmodemfa131.
Starting cgminer using these options:

Code:

./cgminer -d bxf:/dev/tty.usbmodemfa131 -o stratum.btcguild.com:3333 -u xxxx -p xxxx

results in this:

Code:

[2013-11-28 20:12:58] Started cgminer 3.8.3
[2013-11-28 20:12:58] bitfury detect (250:6) failed to initialize (incorrect device?)
[2013-11-28 20:13:00] Command line options set a device that doesn't exist

after which cgminer quits and drops back to the prompt.  Any ideas?

[-ck]

Trying to run a bifury using the cgminer binary inside the unofficial OS X release.  The bifury shows up as /dev/cu.usbmodemfa131 and /dev/tty.usbmodemfa131.
Starting cgminer using these options:

Code:

./cgminer -d bxf:/dev/tty.usbmodemfa131 -o stratum.btcguild.com:3333 -u xxxx -p xxxx

results in this:

Code:

[2013-11-28 20:12:58] Started cgminer 3.8.3
[2013-11-28 20:12:58] bitfury detect (250:6) failed to initialize (incorrect device?)
[2013-11-28 20:13:00] Command line options set a device that doesn't exist

after which cgminer quits and drops back to the prompt.  Any ideas?

Need to unload the driver that osx installs. Instructions in the readme. There is no -d command like that in cgminer.

[kano]

https://dl.dropboxusercontent.com/u/109686709/minepeonstats.jpg

The percentage is DAcc / Diff1 as seen in the screenshot, so Diff1 are all shares counted in difficulty1.

Maybe Disc(arded) isn't displayed in difficulty1 so DAcc + DRej + (sum of Disc * difficulty) = Diff1

Am I getting this right? Which means that I had much lower stale percentage depending on the pool.

No. You've pretty much got everything wrong.

"Discarded" counts for nothing in the amount of work you are doing.
It's simply work you could have used but didn't use due to an LP.
Ignore it.

"DAcc / Diff1" is random and pretty much meaningless.

As per the FAQ:

Code:

Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number
of difficulty shares accepted does not usually exactly equal the amount of work
done to find them. If you are mining at 8 difficulty, then you would expect on
average to find one 8 difficulty share, per 8 single difficulty shares found.
However, the number is actually random and converges over time, it is an average,
not an exact value, thus you may find more or less than the expected average.

Multiplying ANYTHING by "Difficulty" is wrong.
Work difficulty can (and usually does) change.

[drewage]

Need to unload the driver that osx installs. Instructions in the readme. There is no -d command like that in cgminer.

Unloaded the drivers, 4 of them now.  Cgminer started and ran for ~3mins before quitting.

Code:

--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BXF 0: 52.3C         | 3.178G/3.189Gh/s | A:96 R:8 HW:0 WU: 47.9Abort trap: 6
--------------------------------------------------------------------------------


 [2013-11-29 05:36:56] Accepted 09e0c656 Diff 26/2 BXF 0
 [2013-11-29 05:36:58] Accepted d36a26fd Diff 310/2 BXF 0
 [2013-11-29 05:37:00] Accepted 11e59e40 Diff 14/2 BXF 0
 [2013-11-29 05:37:00] Accepted 2109293b Diff 8/2 BXF 0
 [2013-11-29 05:37:01] Accepted 4d4e337a Diff 3/2 BXF 0
 [2013-11-29 05:37:01] Accepted 7a846645 Diff 2/2 BXF 0
 [2013-11-29 05:37:01] Accepted 4bbd2386 Diff 3/2 BXF 0
 [2013-11-29 05:37:01] Accepted 3ede7686 Diff 4/2 BXF 0
 [2013-11-29 05:37:03] BXF 0 BXFWork usb write err:(-1) LIBUSB_ERROR_IO
 [2013-11-29 05:37:03] BXF 0: Error -1 sending BXFWork sent 0 of 161

[-ck]

Need to unload the driver that osx installs. Instructions in the readme. There is no -d command like that in cgminer.

Unloaded the drivers, 4 of them now.  Cgminer started and ran for ~3mins before quitting.

Code:

--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BXF 0: 52.3C         | 3.178G/3.189Gh/s | A:96 R:8 HW:0 WU: 47.9Abort trap: 6
--------------------------------------------------------------------------------


 [2013-11-29 05:36:56] Accepted 09e0c656 Diff 26/2 BXF 0
 [2013-11-29 05:36:58] Accepted d36a26fd Diff 310/2 BXF 0
 [2013-11-29 05:37:00] Accepted 11e59e40 Diff 14/2 BXF 0
 [2013-11-29 05:37:00] Accepted 2109293b Diff 8/2 BXF 0
 [2013-11-29 05:37:01] Accepted 4d4e337a Diff 3/2 BXF 0
 [2013-11-29 05:37:01] Accepted 7a846645 Diff 2/2 BXF 0
 [2013-11-29 05:37:01] Accepted 4bbd2386 Diff 3/2 BXF 0
 [2013-11-29 05:37:01] Accepted 3ede7686 Diff 4/2 BXF 0
 [2013-11-29 05:37:03] BXF 0 BXFWork usb write err:(-1) LIBUSB_ERROR_IO
 [2013-11-29 05:37:03] BXF 0: Error -1 sending BXFWork sent 0 of 161

Good progress. IO errors are problematic and suggest a hardware issue, but the latest git code is able to recover from them a little more gracefully.

[-ck]

Thanks for that. No you were getting the timer overruns previously as well. I saw them on your successful logging when you put it up so even when it's "fine" it's not entirely fine, it's just that it sort of recovers.

Next!
http://ck.kolivas.org/apps/cgminer/temp/cgminer-w00t.exe

EDIT: And one greater than 9000:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-9001.exe

OK, tests done. Usual aside: Previous run of 3.5.1 stopped after 18 hours. No faults.

Test of cgminer-w00t started at 12:50. After about 5 minutes one LED (AMU 16) came on solid but no zombie was reported in the screen display.  I turned on debug and let it run for a few minutes, then I intended to re-plug the offending AMU and continue, but unfortunately I accidentally hit the power button on the hub and turned the whole thing off. D'oh! Test stopped at that point.  I'll run it again if you need more information.

Test of cgminer-9001 started at 13:01.  It ran for over 5 hours before a zombie (AMU27) appeared.  Turned on debug and let it run a bit more, then stopped the test at 18:45.  This one was looking quite promising until the fault popped up. Pity.

Logfiles are here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-w00t.txt
  https://dl.dropboxusercontent.com/u/44240170/logfile-9001.txt

And.... Back to 3.5.1

Very good. Now try this combining both and more please:

http://ck.kolivas.org/apps/cgminer/temp/cgminer-900t.exe

[jmc1517]

Very good. Now try this combining both and more please:

http://ck.kolivas.org/apps/cgminer/temp/cgminer-900t.exe

Stopped cgminer 35.1. after about 23 hours. No faults again

Tried cgminer-900t but it doesn't detect my devices. I get the following:

 [2013-11-29 17:13:30] Started cgminer 3.8.3
 [2013-11-29 17:13:30] Loaded configuration file cgminer.conf
 [2013-11-29 17:13:35] No devices detected!
 [2013-11-29 17:13:35] Waiting for USB hotplug devices or press q to quit
 [2013-11-29 17:13:35] Too many values passed to set temp cutoff

I did try it (I think) also with 3.5.1 already running and it gives me some messages "devices already in use."  So Something seems slightly confused.  I am loading my original 3.5.1 config file.  Is there something in that which would confuse it?  Sorry don't have time to investigate further now, but I'll come back and check it out a bit more thoroughly later if you think it may be my setup which needs tweeking for this build -- but then again, why should it?

[stridergt]

https://dl.dropboxusercontent.com/u/109686709/minepeonstats.jpg

The percentage is DAcc / Diff1 as seen in the screenshot, so Diff1 are all shares counted in difficulty1.

Maybe Disc(arded) isn't displayed in difficulty1 so DAcc + DRej + (sum of Disc * difficulty) = Diff1

Am I getting this right? Which means that I had much lower stale percentage depending on the pool.

No. You've pretty much got everything wrong.

"Discarded" counts for nothing in the amount of work you are doing.
It's simply work you could have used but didn't use due to an LP.
Ignore it.

"DAcc / Diff1" is random and pretty much meaningless.

As per the FAQ:

Code:

Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number
of difficulty shares accepted does not usually exactly equal the amount of work
done to find them. If you are mining at 8 difficulty, then you would expect on
average to find one 8 difficulty share, per 8 single difficulty shares found.
However, the number is actually random and converges over time, it is an average,
not an exact value, thus you may find more or less than the expected average.

Multiplying ANYTHING by "Difficulty" is wrong.
Work difficulty can (and usually does) change.

LP=longpoll?
"This request is not answered by server until it wishes to expire current block data, and new data is ready. The answer is the same as getwork on the main connection. Upon receiving this answer, miner should drop current calculation in progress, discard its result, and start working on received data and make a new request to a long polling URI."

I think you misunderstood me DAcc + DRej + (sum of Disc * difficulty) = Diff1
With the parenthesis I meant a quantity "DDisc", like DAcc and DRej , so the sum of these three converging parameters would eventually converge to Diff1
In this light would DAcc / Diff1, as a ratio between the convergent quantities, give after some period of time an indication of the quality of the pool?

PS Maybe the luck of the pool could skew results but if there is some consistency in detecting a difference between the ratios of two  pools -all else equal- for a long time period, it could mean a better pool setup/efficiency/uptime, but I am beginning to get lost in all these.. :-)

[hanti]

cgminer doesnt want switch back to pool 0..
just keep spaming every 30 sec Pool 0 xxxxx stable for 5 mins

pool 0 is working normally from a long time much more than 5mins :/

[kano]

...
LP=longpoll?
"This request is not answered by server until it wishes to expire current block data, and new data is ready. The answer is the same as getwork on the main connection. Upon receiving this answer, miner should drop current calculation in progress, discard its result, and start working on received data and make a new request to a long polling URI."

I think you misunderstood me DAcc + DRej + (sum of Disc * difficulty) = Diff1
With the parenthesis I meant a quantity "DDisc", like DAcc and DRej , so the sum of these three converging parameters would eventually converge to Diff1
In this light would DAcc / Diff1, as a ratio between the convergent quantities, give after some period of time an indication of the quality of the pool?

PS Maybe the luck of the pool could skew results but if there is some consistency in detecting a difference between the ratios of two  pools -all else equal- for a long time period, it could mean a better pool setup/efficiency/uptime, but I am beginning to get lost in all these.. :-)

No to the above.

I have already said it in my last post so I am wasting my time repeating it but ...

Discarded is meaningless. Yes it is. Ignore it. OK?

Luck is ... luck.

Here, take a course to learn a bit about statistics.
Some important terms: sample, population, probability, variance.

No I don't give courses in statistics - I failed a statistics course at university ... twice

[hanti]

cgminer doesnt want switch back to pool 0..
just keep spaming every 30 sec Pool 0 xxxxx stable for 5 mins

pool 0 is working normally from a long time much more than 5mins :/

after 1h still mining at pool 1 i had to restart cgminer and now its mining at pool 0 as it should

[-ck]

Very good. Now try this combining both and more please:

http://ck.kolivas.org/apps/cgminer/temp/cgminer-900t.exe

Stopped cgminer 35.1. after about 23 hours. No faults again

Tried cgminer-900t but it doesn't detect my devices. I get the following:

 [2013-11-29 17:13:30] Started cgminer 3.8.3
 [2013-11-29 17:13:30] Loaded configuration file cgminer.conf
 [2013-11-29 17:13:35] No devices detected!
 [2013-11-29 17:13:35] Waiting for USB hotplug devices or press q to quit
 [2013-11-29 17:13:35] Too many values passed to set temp cutoff

I did try it (I think) also with 3.5.1 already running and it gives me some messages "devices already in use."  So Something seems slightly confused.  I am loading my original 3.5.1 config file.  Is there something in that which would confuse it?  Sorry don't have time to investigate further now, but I'll come back and check it out a bit more thoroughly later if you think it may be my setup which needs tweeking for this build -- but then again, why should it?

Nah I probably just screwed something up. Try this instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe

[aigeezer]

For some reason my notifications for this thread stopped several days ago, so I've been running a version of 3.8.2 for about 12.5 days! It has done well, with occasional zombies that were always fixed with a replug. List now shows AMU89-95, 99, 100, 102, 103, 105 and 106 so there has been lots of reallocation along the way. Similar for my other machine, although the test has been a few days shorter.

I'll try to get back into the game with a 3.8.3 test shortly. Welcome back, jmc1517 - you're way ahead of me with Win7 testing now.

[-ck]

This is the next set of tests please

http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe

then
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cb5k.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t5cb5.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t20cb5.exe

[aigeezer]

This is the next set of tests please

http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe

then
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cb5k.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t5cb5.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t20cb5.exe

I hear and obey.   

Trying tok now (within 3.8.3 directory) after 1+ hours of uneventful vanilla 3.8.3 run.

[drewage]

Good progress. IO errors are problematic and suggest a hardware issue, but the latest git code is able to recover from them a little more gracefully.

Compiled the latest on Ubuntu 12.04 32bit on old macmini.  Seems to have all the kids playing together, at least they have been for the last two hours.

[crazyates]

Hi there. I'm playing with the --sched-stop command. I'm not using the --sched-start command, and I want it to quit at a certain time.

I entered in a time into my .bat file (--sched-stop 00:20) and it doesn't seem to work. It mines, and then when it reaches 12:20am it says this:

[2013-11-30 00:20:00] Pausing execution as per stop time 00:20 scheduled
[2013-11-30 00:20:00] Terminating execution as planned

But it never actually closes. It just sits there, and I can hear the fans on my Singles continue to ramp up.

Then I closed the window manually, and re-ran my bat file. It never starts mining, saying the above two lines, but with whatever the current timestamp was. Example: I used (--sched-stop 00:20), but opened the .bat at 00:23, and it still says

[2013-11-30 00:23:27] Pausing execution as per stop time 00:20 scheduled
[2013-11-30 00:23:27] Terminating execution as planned

Win 8.1 64 bit, CGMiner 3.8.3, 3 SC Singles, 1 Little Single, and 2 AMUs.

I tried it without the AMUs, and it worked fine. One AMU on a USB 3.0 hub, and it works. One AMU on a USB 2.0 port, and it works. Both AMUs plugged in, and it fails. Consistently.

I have no problems just removing the AMUs; the AMUs aren't really earning my anything anyways, but I figured I'd report this in case it helped you identify whatever was not working.

[-ck]

Hi there. I'm playing with the --sched-stop command. I'm not using the --sched-start command, and I want it to quit at a certain time.

It's not meant to shut down cgminer. It's meant to be given a start and stop time for when it should be mining during the day and when it should be idle.

[crazyates]

--sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time)
--sched-stop <arg>  Set a time of day in HH:MM to stop mining (will quit without a start time)

Hi there. I'm playing with the --sched-stop command. I'm not using the --sched-start command, and I want it to quit at a certain time.

It's not meant to shut down cgminer. It's meant to be given a start and stop time for when it should be mining during the day and when it should be idle.

I'm not using it to start and stop cgminer, I'm using it to quit at a certain time every day. It does exactly this when I don't have any AMUs plugged in, but seems to hang when I have multiple AMUs.