OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 544. (Read 5805546 times)
July 07, 2012, 02:39:04 AM
July 06, 2012, 11:22:12 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.
July 06, 2012, 11:21:21 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.
July 06, 2012, 11:19:24 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented. July 06, 2012, 11:14:42 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented. July 06, 2012, 11:13:31 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented. July 06, 2012, 11:08:30 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
Thanks for the feedback. That was one of the improvements mentioned that I finally got sick of the arguments over and coded up the solution myself. Glad it works for you 
July 06, 2012, 10:47:52 PM
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
July 06, 2012, 03:54:25 PM
I don't think it means anything.
AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.
I typically get 10-15% discards.
AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.
I typically get 10-15% discards.
Yes, I believe I spoke too soon. After closer inspection, it seems upon detection of a new block, it dumps everything under - I'm guessing - ST to DW. Just getting rid of old work that has not been processed yet for a block that matters none anymore.
For some reason it seems as though one of the miners always takes about 5 or 6 seconds longer to realize there's a new block. Maybe because of the lack of long poll, the prompt with higher hash speed will always notice first because it needs to send something to realize it's not longer relevant. This would suggest that if you have to use multiple computers to host your gpu's/devices, you should try to spread hash speed as evenly as possible. For solo mining of course, where with long poll this wouldn't matter. At least this is my guess. Not related to CGMiner I know, but I wanted to put it anyway
July 06, 2012, 01:44:04 PM
I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.
Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught
Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught
I don't think it means anything.
AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.
I typically get 10-15% discards.
July 06, 2012, 01:38:07 PM
I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.
Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught
Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught
July 06, 2012, 12:49:06 PM
Just upgraded to cgminer 2.5.0 on BAMT 0.5, so far so good with 5 BFLs, 1 GPU.
July 06, 2012, 12:47:39 PM
It does in Linux, and that's what I'm mainly using
Fair enough. For some reason, I was thinking you were specifically discussing Windows. Either I crossed this conversation with another one in the same thread or I confused the -S designations for Windows vs Linux (I don't own any BFL product to help keep this straight in my head, and I was only trying to help). July 06, 2012, 12:42:17 PM
It does in Linux, and that's what I'm mainly using
July 06, 2012, 12:32:57 PM
When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.
For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).
In that case I'm thinking windows isn't closing / reopening the port properly.
Edit:
Yeah, a quick look suggests that a wait between closing and reopening may help.
July 06, 2012, 12:18:29 PM
When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.
For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).
In that case I'm thinking windows isn't closing / reopening the port properly.
Edit:
Yeah, a quick look suggests that a wait between closing and reopening may help.
July 06, 2012, 11:59:15 AM
When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.
For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).
July 06, 2012, 11:52:35 AM
... and anyone looking for an Xubuntu 11.04 compile of 2.5.0
-> cgminer-2.5.0a at the top of https://github.com/kanoi/cgminer/downloads
(I'm running this executable at the moment on both my rigs)
-> cgminer-2.5.0a at the top of https://github.com/kanoi/cgminer/downloads
(I'm running this executable at the moment on both my rigs)
July 06, 2012, 11:51:19 AM
July 06, 2012, 11:46:05 AM
Anyone else having a problem of cgminer saying their BFL is over the heat threshold when it's only at 45C and stopping work on it? 
Check your configuration file or command line doesn't have temperature parameters for GPU(s), and that zero is being used for the BFL.I found this too. My config file had 95 set for my two GPUs, then nothing more specified. by default, it should set any remaining devices to 95, but it didn't. I'm thinking it set it to 0. Anyway, I removed the conf. line and it worked fine.
Jump to: