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.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 165. (Read 5805527 times)
November 29, 2013, 10:37:39 PM
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.
November 29, 2013, 06:22:19 PM
This is the next set of tests please
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
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.
November 29, 2013, 06:07:46 PM
November 29, 2013, 05:52:26 PM
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.
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.
November 29, 2013, 05:45:49 PM
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?
http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe
November 29, 2013, 05:33:35 PM
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 :/
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
November 29, 2013, 05:07:00 PM
...
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.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.. :-)
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
November 29, 2013, 04:39:28 PM
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 :/
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 :/
November 29, 2013, 01:47:22 PM
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.
"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.. :-)
November 29, 2013, 01:24:20 PM
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?
November 29, 2013, 07:01:11 AM
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
http://ck.kolivas.org/apps/cgminer/temp/cgminer-900t.exe
November 29, 2013, 06:49:07 AM
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
November 29, 2013, 06:41:55 AM
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
November 28, 2013, 09:40:18 PM
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.
"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.
November 28, 2013, 09:39:12 PM
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:
results in this:
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. 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?
November 28, 2013, 09:21:43 PM
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:
results in this:
after which cgminer quits and drops back to the prompt. Any ideas?
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?
November 28, 2013, 09:11:20 PM
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
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...
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.
November 28, 2013, 02:56:11 PM
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
November 28, 2013, 10:37:19 AM
I'm trying to use JSON API with the following command sent over RPC:
{"command":"pools"}
I'm getting .."status":"E","When":11/28/2013 07:18:45","Code":14","Msg":"Invalid command","Description":"cgminer 3.8.3"...
API works however with regular text request/response and the same call is working fine for cgminer 3.8.1
Did something changed? or is it a bug?
Looks like a bug with fixing the memory leaks of json usage in the API, thanks, will investigate. {"command":"pools"}
I'm getting .."status":"E","When":11/28/2013 07:18:45","Code":14","Msg":"Invalid command","Description":"cgminer 3.8.3"...
API works however with regular text request/response and the same call is working fine for cgminer 3.8.1
Did something changed? or is it a bug?
November 28, 2013, 10:10:16 AM
CG miner isn't displaying any text for me I am on windows 8.1 only way for it to display text is to do -T in the startup parameters without that the windows is completely blank.
Jump to: