I`m mining LTC on my P2pool node. Binary downloaded form #1 post.
Linux or Windows. I'm not going to be able to help you, but hopefully having all of this information already here will be beneficial to Con/Kano sholud they get to this issue. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 515. (Read 5805728 times)
August 20, 2012, 09:31:33 AM
August 20, 2012, 09:22:52 AM
I`m mining LTC on my P2pool node. Binary downloaded form #1 post.
Edit: Yes, ofc i mean Q not A
Edit: Yes, ofc i mean Q not A
August 20, 2012, 08:42:40 AM
2.7 is not counting getworks properly:After every new block and longpool A sould incerase.
I assume you mean Q, and that does look odd, but my Q is much higher, which may mean my pool doesn't support nrolltime. That said, m Q starts at 4 (gets work from the main pool and 3 backups). That is even with --failover-only specified. Are you mining with only one pool? If not, did you compile, or download a binary? Code:
cgminer version 2.7.0 - Started: [2012-08-20 14:30:15]
--------------------------------------------------------------------------------
(5s):16.5 (avg):14.4 Kh/s | Q:1 A:750 R:47 HW:0 E:75000% U:20.7/m
TQ: 0 ST: 2 SS: 0 DW: 1 NB: 10 LW: 450 GF: 0 RF: 0 WU: 22.0
Connected to http://rav3n.dtdns.net:9327 with LP as user toy.gpu
Block: d4168a8f77630bea179cbdd61dde162a... Started: [15:06:26]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 66.5C 85% | 14.4/ 14.4Kh/s | A:751 R:47 HW:1 U:20.72/m I:10
--------------------------------------------------------------------------------
[2012-08-20 15:06:25] Accepted 431632d4.dd42f9df GPU 0
[2012-08-20 15:06:25] Accepted f37d0edb.290d0d52 GPU 0
[2012-08-20 15:06:26] LONGPOLL from pool 0 detected new block
[2012-08-20 15:06:27] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:29] Accepted 6f40a714.8354c7a0 GPU 0
[2012-08-20 15:06:30] Accepted 2c0bf299.1591375f GPU 0
[2012-08-20 15:06:30] Accepted a2b07c82.28faaba6 GPU 0
[2012-08-20 15:06:30] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:35] Accepted 8fe2907d.0c4422b2 GPU 0
[2012-08-20 15:06:37] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:38] Accepted 0373a844.56d60ca2 GPU 0
[2012-08-20 15:06:39] Accepted 3f2bbd00.b33561ed GPU 0
[2012-08-20 15:06:46] Accepted b97e91c0.ec9b8b93 GPU 0
August 20, 2012, 08:09:57 AM
2.7 is not counting getworks properly:
After every new block and longpool Q should incerase.
(Edited typo)
Code:
cgminer version 2.7.0 - Started: [2012-08-20 14:30:15]
--------------------------------------------------------------------------------
(5s):16.5 (avg):14.4 Kh/s | Q:1 A:750 R:47 HW:0 E:75000% U:20.7/m
TQ: 0 ST: 2 SS: 0 DW: 1 NB: 10 LW: 450 GF: 0 RF: 0 WU: 22.0
Connected to http://rav3n.dtdns.net:9327 with LP as user toy.gpu
Block: d4168a8f77630bea179cbdd61dde162a... Started: [15:06:26]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 66.5C 85% | 14.4/ 14.4Kh/s | A:751 R:47 HW:1 U:20.72/m I:10
--------------------------------------------------------------------------------
[2012-08-20 15:06:25] Accepted 431632d4.dd42f9df GPU 0
[2012-08-20 15:06:25] Accepted f37d0edb.290d0d52 GPU 0
[2012-08-20 15:06:26] LONGPOLL from pool 0 detected new block
[2012-08-20 15:06:27] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:29] Accepted 6f40a714.8354c7a0 GPU 0
[2012-08-20 15:06:30] Accepted 2c0bf299.1591375f GPU 0
[2012-08-20 15:06:30] Accepted a2b07c82.28faaba6 GPU 0
[2012-08-20 15:06:30] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:35] Accepted 8fe2907d.0c4422b2 GPU 0
[2012-08-20 15:06:37] LONGPOLL from pool 0 requested work restart
[2012-08-20 15:06:38] Accepted 0373a844.56d60ca2 GPU 0
[2012-08-20 15:06:39] Accepted 3f2bbd00.b33561ed GPU 0
[2012-08-20 15:06:46] Accepted b97e91c0.ec9b8b93 GPU 0
(Edited typo)
August 19, 2012, 05:48:54 PM
Nicely done Con, I'm averaging over 5100% efficiency
August 19, 2012, 04:59:54 PM
My E: went from ~175% to 1200% after about 10k shares. Is that what you were expecting?
My efficiency is through the roof with this new version.
miner with one GPU after 13k shares: 5316%
miner with three GPUs after 40k shares: 50336%
miner with four GPUs after 56k shares: 4516%
the 2nd one looks funny to me, but it's what cgminer is reporting.
M
August 19, 2012, 04:57:09 PM
Git log tells me there was some problem with the patch I submitted. Can you (or someone) clarify where the problem was?
August 19, 2012, 02:26:30 PM
Hi!
Testing version 2.6.4 on Ubuntu 12.04, found a (minor) bug, but I think it could be an older one. Yesterday I configured my system to use the onboard GPU (3300) for display and the PCIe card (5770) for mining only. Unfortunately, ADL and CL GPU mapping does not seem to work.
---Testing version 2.6.4 on Ubuntu 12.04, found a (minor) bug, but I think it could be an older one. Yesterday I configured my system to use the onboard GPU (3300) for display and the PCIe card (5770) for mining only. Unfortunately, ADL and CL GPU mapping does not seem to work.
Nite69
WalletId: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Hi!
Unfortunately, this problem reappears on 2.7.0. I think the problem is on line (see the patch)
Code:
gpus[gpu].virtual_gpu = vadapters[gpu].virtual_gpu;
Git log tells me there was some problem with the patch I submitted. Can you (or someone) clarify where the problem was?
---
Nite69
WalletId: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
August 19, 2012, 12:14:05 PM
My E: went from ~175% to 1200% after about 10k shares. Is that what you were expecting?
My efficiency is through the roof with this new version.
miner with one GPU after 13k shares: 5316%
miner with three GPUs after 40k shares: 50336%
miner with four GPUs after 56k shares: 4516%
the 2nd one looks funny to me, but it's what cgminer is reporting.
M
August 19, 2012, 11:56:49 AM
My E: went from ~175% to 1200% after about 10k shares. Is that what you were expecting?
August 19, 2012, 11:03:46 AM
On second thought, there may be a bug here... will investigate tomorrow.
I suppose I'll start integrity checking some of my equipment. The route from this single to my bitcoind is windows client -> router -> switch -> windows host. I am thinking the switch is perhaps seeing the end of its days if it does not result as a bug. But I never really noticed any performance problems with anything... I could perhaps try downloading something that would max my bandwidth on the bitcoind machine, or comparing speedtest results between it and my machine that's not behind the switch.
Sorry, not related to cgminer, but my fingers are moving on their own...
August 19, 2012, 10:53:27 AM
On second thought, there may be a bug here... will investigate tomorrow.
August 19, 2012, 10:21:05 AM
I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.
I am so confused, haha.
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.I am so confused, haha.
I just tried enabling solo mining on my machine and initially it leaked some shares to the backup pools and then again when there was a new block, but then it settles down and mines solo till the next block and repeats the cycle.
This seems like normal behavior to me. This machine uses two GPU's at about 510Mhs.
Sam
August 19, 2012, 10:15:19 AM
Please email me the old binaries [email protected] (one at a time or email will reject them), thanks!
I have almost all the Windoze binaries from 2.0 to current. Do you want all of them? Let me know I would be happy to email them to you.
Thanks,
Sam
August 19, 2012, 10:11:44 AM
I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.
I am so confused, haha.
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.I am so confused, haha.
I just tried enabling solo mining on my machine and initially it leaked some shares to the backup pools and then again when there was a new block, but then it settles down and mines solo till the next block and repeats the cycle.
This seems like normal behavior to me. This machine uses two GPU's at about 510Mhs.
Sam
August 19, 2012, 09:33:55 AM
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.
I see...But, and I hate to pester, that raises so many questions in my head. Wouldn't doing that mean my machines are definitely not working anywhere near what they're supposed to be? And then, if bitcoind is really THAT slow, I don't see how solo mining was ever worth it.. here's a picture of solo mining with one bfl single for ~30 minutes. This was the only device solo mining on the network at the time:
http://i.imgur.com/tRgwI.png
More than half of the work is going toward pool 2 (pool 1 is down, probably a coincidence). I mean, is it only not complaining that pool 0 is too slow because it can grab work from pool 2? Or is it designed to not put those kinds of errors when soloing? Pretty sure I've seen them before when solo, on an NB or something..
Here we have soloing now with --failover-only, ~45 minutes, everything else the same (even pool 1 is still down
) :http://i.imgur.com/kYkXO.png
Sorry about the disparity in uptime, but the last prompt makes me believe that bitcoind is only fast enough to provide half of what the single can handle. Temps are also the same, so it's safe to assume the single is being worked pretty closely to the last prompt as well. Everything is the same.. not sure if that matters but it seems to matter.
But if I'm misunderstanding all of this, which is fine; what is the "limit" of bitcoind in GH/s? Will solo'ing on one of those new ASIC mini-rigs basically be a no-go? I appreciate learning about this as it interests me greatly.
August 19, 2012, 08:29:42 AM
I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.
I am so confused, haha.
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope. I am so confused, haha.
August 19, 2012, 08:27:11 AM
I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.
I am so confused, haha.
I am so confused, haha.
August 19, 2012, 07:31:47 AM
Con, I hope quoting this so you can see it doesn't come off wrong:
Thanks, much appreciate the useful filtering, and thanks luke-jr for your debugging. I looked into the "Switch User" hang reported originally in CGMiner.
It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.
Thanks,
Luke
The issue doesn't affect me, and presumably Kano has already seen it and could even be dealing with it, but I figure better safe than sorry, and this particular post seems both civil and useful enough to be worthy of your time.It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.
Thanks,
Luke
August 19, 2012, 05:44:32 AM
Con, I hope quoting this so you can see it doesn't come off wrong:
I looked into the "Switch User" hang reported originally in CGMiner.
It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.
Thanks,
Luke
The issue doesn't affect me, and presumably Kano has already seen it and could even be dealing with it, but I figure better safe than sorry, and this particular post seems both civil and useful enough to be worthy of your time. It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.
Thanks,
Luke
Jump to: