I saw another interesting glitch. I disabled, then removed pool 4, leaving pools 0, 1, 2, and 3, with priorities to match, and my next share was submitted to, pool 5. There hadn't been a pool 5 at all, so that was really weird, then it seemed to stop submitting good shares, so I quit and started over. Obviously there's probably not enough information here to even point toward the problem, but on the off chance that an event like that could lead to an epiphany, I would post about it. Regarding the git version, I'm not incredibly familiar with git and didn't have a lot of time to figure it out again. Moreover, I was still waiting to see if the problem I saw within 15 minutes of adding pool 4 the first time happened again, and it didn't all day, since I was done with that pool, I just happened to stumble upon this. In case this info is helpful, I'm still on a really old sdk, and I compiled with --enable-scrypt, which obviously won't function (as someone pointed out after I asked, and I may have previously known and forgotten). Point is, I don't know if these non-scrypt bugs are hanging out in the scrypt modifications or not, but maybe they could be? The only reason I'm not still on 2.4.(whatever the highest was) is because I was having high CPU usage in linux after pool problems, and finally decided to try to end them, 2.6.(whatever the highest was) still had that, and so did 2.7.0 and 2.7.1. I probably need to find stable pool or just quit mining since all I have is a 5830.
No, once a pool is removed, because there may still be work "in flight" it still keeps a reference to the old pool around till those work items are complete. After a couple of minutes no more shares will be submitted to it. Thanks tho. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 512. (Read 5805728 times)
August 22, 2012, 06:48:34 PM
August 22, 2012, 06:42:37 PM
I saw another interesting glitch. I disabled, then removed pool 4, leaving pools 0, 1, 2, and 3, with priorities to match, and my next share was submitted to, pool 5. There hadn't been a pool 5 at all, so that was really weird, then it seemed to stop submitting good shares, so I quit and started over. Obviously there's probably not enough information here to even point toward the problem, but on the off chance that an event like that could lead to an epiphany, I would post about it. Regarding the git version, I'm not incredibly familiar with git and didn't have a lot of time to figure it out again. Moreover, I was still waiting to see if the problem I saw within 15 minutes of adding pool 4 the first time happened again, and it didn't all day, since I was done with that pool, I just happened to stumble upon this. In case this info is helpful, I'm still on a really old sdk, and I compiled with --enable-scrypt, which obviously won't function (as someone pointed out after I asked, and I may have previously known and forgotten). Point is, I don't know if these non-scrypt bugs are hanging out in the scrypt modifications or not, but maybe they could be? The only reason I'm not still on 2.4.(whatever the highest was) is because I was having high CPU usage in linux after pool problems, and finally decided to try to end them, 2.6.(whatever the highest was) still had that, and so did 2.7.0 and 2.7.1. I probably need to find stable pool or just quit mining since all I have is a 5830.
August 22, 2012, 05:57:52 PM
So I upgraded to 2.7.1 and I've been getting cgminer quiting after about an hour. It doesn't crash, it just closes itself.
I had this too, on 3 different rigs both Linux & Windows. With an invalid pool 0 it closes immediately after starting. On Linux I'm using latest git now, let's see if that helps.
August 22, 2012, 05:50:40 PM
Alas that was the bug I was trying to fix going from 2.7.0 to 2.7.1. If anyone's on git and want to give the latest git master a try there's one tiny change which might help, but it's a long shot.
Well as usual no one puts their hand up, so here's a windows binary to test instead for those having the refusing to stay on one pool problem:http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
August 22, 2012, 01:51:30 PM
So I upgraded to 2.7.1 and I've been getting cgminer quiting after about an hour. It doesn't crash, it just closes itself.
August 22, 2012, 12:29:21 PM
hope someone can help with this problem.
this is my first time using cgminer. i have managed to get it working with one one of my gpu's. however when i have a second gpu plugged in i get some strange results. I can only have 2 gpu at a time due to space and heat.
i have one 5870 working fine in all configurations.
one 5770 only operates at about 50% of potential performance. circa 90-120MHs
one 5870 that fan goes ape shit and BSODs
i can run all these card fine with GUIminer. however i have some asic and fpga on order and wanted to get used to cgminer.
any suggestions.
this is my first time using cgminer. i have managed to get it working with one one of my gpu's. however when i have a second gpu plugged in i get some strange results. I can only have 2 gpu at a time due to space and heat.
i have one 5870 working fine in all configurations.
one 5770 only operates at about 50% of potential performance. circa 90-120MHs
one 5870 that fan goes ape shit and BSODs
i can run all these card fine with GUIminer. however i have some asic and fpga on order and wanted to get used to cgminer.
any suggestions.
August 22, 2012, 11:22:10 AM
winsows 7 x64
driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
Most unusual. That is a fatal error because there are too many threads running or the system has run out of ram. This bug falls into the "I have no idea" category.driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
Code:
[2012-08-22 08:41:14] Failed to create get_work_thread
August 22, 2012, 08:33:16 AM
Alas that was the bug I was trying to fix going from 2.7.0 to 2.7.1. If anyone's on git and want to give the latest git master a try there's one tiny change which might help, but it's a long shot.
August 22, 2012, 08:28:00 AM
My bonuspool account went apeshit exactly like that for a little while a few hours ago. I switched a couple parts around in my rigs so I wasn't sure if it was a hardware issue, but it seems to have gone away.
I don't think it's bonuspool. The common element was that we both had a pool go down. I use Eclipse and mtred, and when Eclipse went down this morning, I manually added mtred because it wasn't in the config at the time. Later on, I realized Eclipse had come up and was up for awhile, but the miner was doing -exactly- what Morblias was saying: except that I switched it myself, and it was failing to switch back. Actually, I didn't even switch it - I just added mtred manually while it was running, and it went over to mtred on it's own. Of course at first I expected the errors it was giving... because the pool was down. I even checked using ping.eu's port checker function and 8337 on eclipse was closed for all Eclipse servers. Later on when I knew the pool was up, the miner was doing exactly the same thing. Sitting on mtred, and saying Eclipse was down. I even checked again with ping.eu to make sure, and indeed Eclipse was up. So I just closed the miner, repoened it, and voila, connection to Eclipse.
I think this is pretty solid evidence
ETA: I am using 2.7.1, I think the two quotes above are too, I just realized none of them indicate it in this post.
August 22, 2012, 06:51:16 AM
I'm having a problem with dynamic intensity with 2.7.1 on Windows XP:
When I start cgminer with dynamic intensity it generally operates around intensity 3 or 4 depending on what I'm doing on the PC. Last night I changed the intensity from dynamic to 8 (by typing "g, i, 8" in cgminer) and found the PC almost unresponsive this morning with an intensity of 13. I expected it to still be at 8.
Not at all expected behaviour. When I start cgminer with dynamic intensity it generally operates around intensity 3 or 4 depending on what I'm doing on the PC. Last night I changed the intensity from dynamic to 8 (by typing "g, i, 8" in cgminer) and found the PC almost unresponsive this morning with an intensity of 13. I expected it to still be at 8.
August 22, 2012, 06:19:30 AM
I am most certainly not going to give one more second's thought to scrypt.
Don't mean to make you think of it, but, what the heck is "scrypt" anyway?
Sam
Why is that?
Ok, thanks for the answer
August 22, 2012, 05:32:48 AM
I am most certainly not going to give one more second's thought to scrypt.
Don't mean to make you think of it, but, what the heck is "scrypt" anyway?
Sam
Why is that?
August 22, 2012, 05:28:04 AM
New version - 2.7.1, 21st August 2012
Hopefully the gpu-map feature is working for more adl devices than opencl.
Seems to work now, thanks!Hopefully the gpu-map feature is working for more adl devices than opencl.
August 22, 2012, 05:14:36 AM
I am most certainly not going to give one more second's thought to scrypt.
Don't mean to make you think of it, but, what the heck is "scrypt" anyway?
Sam
Why is that?
August 22, 2012, 05:13:45 AM
I'm having a problem with dynamic intensity with 2.7.1 on Windows XP:
When I start cgminer with dynamic intensity it generally operates around intensity 3 or 4 depending on what I'm doing on the PC. Last night I changed the intensity from dynamic to 8 (by typing "g, i, 8" in cgminer) and found the PC almost unresponsive this morning with an intensity of 13. I expected it to still be at 8.
When I start cgminer with dynamic intensity it generally operates around intensity 3 or 4 depending on what I'm doing on the PC. Last night I changed the intensity from dynamic to 8 (by typing "g, i, 8" in cgminer) and found the PC almost unresponsive this morning with an intensity of 13. I expected it to still be at 8.
August 22, 2012, 05:08:50 AM
2GB of system RAM, and is running flags " -g 1 -v 1 -w 256 -I 10 " i run two HD7950
August 22, 2012, 04:49:53 AM
winsows 7 x64
driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
Most unusual. That is a fatal error because there are too many threads running or the system has run out of ram. This bug falls into the "I have no idea" category. driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
Code:
[2012-08-22 08:41:14] Failed to create get_work_thread
August 22, 2012, 03:22:48 AM
winsows 7 x64
driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
and cgminer crash.
i will go back to 2.7.0
driver 12.8
SDK 2.7
cgminer 2.7.1
after few hours run appear error :
Code:
[2012-08-22 08:39:59] Accepted 43ccdc0e.9f4a0881 GPU 1 pool 0
[2012-08-22 08:40:02] Accepted 56eb716f.b4d7f8c4 GPU 1 pool 0
[2012-08-22 08:40:04] Accepted 9f5505de.e0a3aeb7 GPU 1 pool 0
[2012-08-22 08:40:14] Pool 0 not providing work fast enough
[2012-08-22 08:40:51] Pool 0 communication failure, caching submissions
[2012-08-22 08:40:51] Share became stale while retrying submit, discarding
[2012-08-22 08:40:56] Share became stale while retrying submit, discarding
[2012-08-22 08:41:00] Share became stale while retrying submit, discarding
[2012-08-22 08:41:14] Pool 0 http://pool.ABCPool.co:8332 not responding!
[2012-08-22 08:41:14] Switching to http://mine3.btcguild.com:8332
[2012-08-22 08:41:14] Long-polling activated for http://mine3.btcguild.com:8332/LP/
[2012-08-22 08:41:14] Failed to create get_work_thread
[2012-08-22 08:41:14]
Summary of runtime statistics:
[2012-08-22 08:41:14] Started at [2012-08-21 21:21:42]
[2012-08-22 08:41:14] Runtime: 11 hrs : 19 mins : 29 secs
[2012-08-22 08:41:14] Average hashrate: 1146.9 Megahash/s
[2012-08-22 08:41:14] Solved blocks: 0
[2012-08-22 08:41:14] Queued work requests: 11182
[2012-08-22 08:41:14] Share submissions: 10516
[2012-08-22 08:41:14] Accepted shares: 10480
[2012-08-22 08:41:14] Rejected shares: 36
[2012-08-22 08:41:14] Reject ratio: 0.3%
[2012-08-22 08:41:14] Hardware errors: 0
[2012-08-22 08:41:14] Efficiency (accepted / queued): 94%
[2012-08-22 08:41:14] Utility (accepted shares / min): 15.42/min
[2012-08-22 08:41:14] Work Utility (diff1 shares solved / min): 15.48/min
[2012-08-22 08:41:14] Discarded work due to new blocks: 156
[2012-08-22 08:41:14] Stale submissions discarded due to new blocks: 3
[2012-08-22 08:41:14] Unable to get work from server occasions: 78
[2012-08-22 08:41:14] Work items generated locally: 0
[2012-08-22 08:41:14] Submitting work remotely delay occasions: 1
[2012-08-22 08:41:14] New blocks detected on network: 65
[2012-08-22 08:41:14] Pool: http://pool.ABCPool.co:8332
[2012-08-22 08:41:14] Queued work requests: 11180
[2012-08-22 08:41:14] Share submissions: 10516
[2012-08-22 08:41:14] Accepted shares: 10480
[2012-08-22 08:41:14] Rejected shares: 36
[2012-08-22 08:41:14] Reject ratio: 0.3%
[2012-08-22 08:41:14] Efficiency (accepted / queued): 94%
[2012-08-22 08:41:14] Discarded work due to new blocks: 154
[2012-08-22 08:41:14] Stale submissions discarded due to new blocks: 3
[2012-08-22 08:41:14] Unable to get work from server occasions: 78
[2012-08-22 08:41:14] Submitting work remotely delay occasions: 1
[2012-08-22 08:41:14] Pool: http://mine3.btcguild.com:8332
[2012-08-22 08:41:14] Queued work requests: 1
[2012-08-22 08:41:14] Share submissions: 0
[2012-08-22 08:41:14] Accepted shares: 0
[2012-08-22 08:41:14] Rejected shares: 0
[2012-08-22 08:41:14] Efficiency (accepted / queued): 0%
[2012-08-22 08:41:14] Discarded work due to new blocks: 1
[2012-08-22 08:41:14] Stale submissions discarded due to new blocks: 0
[2012-08-22 08:41:14] Unable to get work from server occasions: 0
[2012-08-22 08:41:14] Submitting work remotely delay occasions: 0
[2012-08-22 08:41:14] Pool: http://pit.deepbit.net:8332
[2012-08-22 08:41:14] Queued work requests: 1
[2012-08-22 08:41:14] Share submissions: 0
[2012-08-22 08:41:14] Accepted shares: 0
[2012-08-22 08:41:14] Rejected shares: 0
[2012-08-22 08:41:14] Efficiency (accepted / queued): 0%
[2012-08-22 08:41:14] Discarded work due to new blocks: 1
[2012-08-22 08:41:14] Stale submissions discarded due to new blocks: 0
[2012-08-22 08:41:14] Unable to get work from server occasions: 0
[2012-08-22 08:41:14] Submitting work remotely delay occasions: 0
[2012-08-22 08:41:14] Summary of per device statistics:
[2012-08-22 08:41:14] GPU0 | (5s):551.9 (avg):547.8 Mh/s | A:5049 R:15 HW:0 U:7.4/m I:10
[2012-08-22 08:41:14] GPU1 | (5s):602.9 (avg):599.1 Mh/s | A:5431 R:21 HW:0 U:8.0/m I:10
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] API failed (Socket Error: (10004) Interrupted system call) - API will not be available
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
[2012-08-22 08:41:14] Failed to tq_push in queue_request
and cgminer crash.
i will go back to 2.7.0
August 22, 2012, 02:43:59 AM
Failover only: does this override the default setting which is failover using backup pools when primary pool is lagging?
in other words if i use this parameter will it stay on one pool even if the pool is slow and not accepting shares at my full speed hashrate i could be sending them?
and default it would utilize another pool for some shares that the first pool isn't fast enough to select?
Yep, pretty much. in other words if i use this parameter will it stay on one pool even if the pool is slow and not accepting shares at my full speed hashrate i could be sending them?
and default it would utilize another pool for some shares that the first pool isn't fast enough to select?
August 22, 2012, 02:34:00 AM
Failover only: does this override the default setting which is failover using backup pools when primary pool is lagging?
in other words if i use this parameter will it stay on one pool even if the pool is slow and not accepting shares at my full speed hashrate i could be sending them?
and default it would utilize another pool for some shares that the first pool isn't fast enough to select?
in other words if i use this parameter will it stay on one pool even if the pool is slow and not accepting shares at my full speed hashrate i could be sending them?
and default it would utilize another pool for some shares that the first pool isn't fast enough to select?
Jump to: