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

[os2sam]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

[Nemo1024]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

Well, in my SW development practice this is called a "regression" as it broke prior existing behaviour. Good enough reason for me to call it a bug.

[ak49er]

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

I call bullshit on pretty much everything in this post.  But a fix may not be the highest priority so at least a note as to the behavior would be useful.

[juhakall]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

Well, in my SW development practice this is called a "regression" as it broke prior existing behaviour. Good enough reason for me to call it a bug.

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

[-ck]

It's not that big a deal, I only just heard of it and I'll fix it next version. Let the discussion go.

[os2sam]

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

I call bullshit on pretty much everything in this post.  But a fix may not be the highest priority so at least a note as to the behavior would be useful.

OK, fine,  I'm just expressing my opinion a bit and attempting to apply common sense.

It would just seem to make sense to me to tell the the mining software what type of mining I want it to do before telling it how I want it to mine that specific coin.

The previous posters remark about regression is very valid too, it seems to me.
Later,
Sam

[Nemo1024]

It's not that big a deal, I only just heard of it and I'll fix it next version. Let the discussion go.

I am not blaming anyone or trying to make a fuss, just reporting/confirming a bug.
CGMiner is the program for mining for me and I like to see it at top level.
Which reminds me, I don't believe I donated before. A small thank you something sent to 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ 

[crazyearner]

First problem found in  --avalon-freq <arg> Set frequency range for avalon-auto, single value or range

with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?

[Krak]

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

Code:

"kernel" : "scrypt"

[Xian01]

Heads up, http://ck.kolivas.org/apps/cgminer appears to be inaccessible.

[juhakall]

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

Code:

"kernel" : "scrypt"

This didn't help, and seems redundant. I've never had to specify a kernel for scrypt, only one exists anyway. I'll just wait for the sanity check code to be fixed.

[Krak]

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

Code:

"kernel" : "scrypt"

This didn't help, and seems redundant. I've never had to specify a kernel for scrypt, only one exists anyway. I'll just wait for the sanity check code to be fixed.

It's not redundant if you use that instead of --scrypt on the command line. I was just telling you how to put it into the config file.

[juhakall]

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

Code:

"kernel" : "scrypt"

This didn't help, and seems redundant. I've never had to specify a kernel for scrypt, only one exists anyway. I'll just wait for the sanity check code to be fixed.

It's not redundant if you use that instead of --scrypt on the command line. I was just telling you how to put it into the config file.

I did put that in the config file (in addition to the "scrypt" : true that was already there, above the intensity line), and cgminer's new sanity check still didn't detect I was using scrypt. It's clearly tied to the "scrypt" setting, which just isn't picked up from a config file yet . The setting itself works fine, enabling scrypt mode, but the sanity check code doesn't detect it's there. It also fails to detect scrypt mode if -I is specified on the command line before --scrypt. Neither of these bugs existed before 3.3.2.

Code:

"scrypt" : true,
"kernel" : "scrypt",
"gpu-engine" : "690,550,650,690",
"gpu-fan" : "80,100,100,100",
"gpu-memclock" : "930,720,790,930",
"gpu-threads" : "1",
"gpu-vddc" : "0.95",
"intensity" : "17",
"thread-concurrency" : "8192"

The above config settings still won't allow high intensities, if --scrypt is not used in the command line. I can't see what that kernel setting is supposed to do with scrypt, since the default kernel is the only one that can/will be used.

I'm confident ckolivas can fix this easily. I was actually surprised the GPU mining code is still being modified.

[Bitcoin_Silver_Supply]

My long-delayed BFL Little Single just arrived and I excitedly opened it up only to find a plethora of errors when trying to mine it with CGMiner. It currently recognizes the device as both "BFL0" and "BFL4" in error messages. Error messages range from "Comms error" to "Error: send work reports" to "Garbled response probably throttling, clearing buffer" and more. The temperature of the device is often listed at 28 degrees, but it is never shown mining (while my GPUs are)

I initially had an issue with driver recognition (Win7) which was ultimately solved by doing a windows search for drivers fix... Any fellow BFL "customers" (venture capital investors) have any tips?

[rocks]

I've looked through the FAQ and SCRYPT-README file, but could not find an answer to this.

If I run the following with version 3.3.2, the following error comes back:

Code:

cgminer --scrypt
cgminer: --scrypt: unrecognized option 

Every thread I found from Googling says to recompile the source in linux and enable scrypt. However I am using windows and can not rebuild.

Does anyone know where to find a cgminer binary for windows with scrypt enabled? I would have thought it would be included in the standard build.

[Krak]

I did put that in the config file (in addition to the "scrypt" : true that was already there, above the intensity line), and cgminer's new sanity check still didn't detect I was using scrypt. It's clearly tied to the "scrypt" setting, which just isn't picked up from a config file yet . The setting itself works fine, enabling scrypt mode, but the sanity check code doesn't detect it's there. It also fails to detect scrypt mode if -I is specified on the command line before --scrypt. Neither of these bugs existed before 3.3.2.

Code:

"scrypt" : true,
"kernel" : "scrypt",
"gpu-engine" : "690,550,650,690",
"gpu-fan" : "80,100,100,100",
"gpu-memclock" : "930,720,790,930",
"gpu-threads" : "1",
"gpu-vddc" : "0.95",
"intensity" : "17",
"thread-concurrency" : "8192"

The above config settings still won't allow high intensities, if --scrypt is not used in the command line. I can't see what that kernel setting is supposed to do with scrypt, since the default kernel is the only one that can/will be used.

I'm confident ckolivas can fix this easily. I was actually surprised the GPU mining code is still being modified.

When you use the --scrypt flag, you're essentially telling cgminer to use the scrypt kernel. Assuming the intensity issue gets fixed, you can just use "kernel" : "scrypt" instead.

[rav3n_pl]

I've looked through the FAQ and SCRYPT-README file, but could not find an answer to this.

If I run the following with version 3.3.2, the following error comes back:

Code:

cgminer --scrypt
cgminer: --scrypt: unrecognized option 

Every thread I found from Googling says to recompile the source in linux and enable scrypt. However I am using windows and can not rebuild.

Does anyone know where to find a cgminer binary for windows with scrypt enabled? I would have thought it would be included in the standard build.

Try my skydrive.

[kano]

My long-delayed BFL Little Single just arrived and I excitedly opened it up only to find a plethora of errors when trying to mine it with CGMiner. It currently recognizes the device as both "BFL0" and "BFL4" in error messages. Error messages range from "Comms error" to "Error: send work reports" to "Garbled response probably throttling, clearing buffer" and more. The temperature of the device is often listed at 28 degrees, but it is never shown mining (while my GPUs are)

I initially had an issue with driver recognition (Win7) which was ultimately solved by doing a windows search for drivers fix... Any fellow BFL "customers" (venture capital investors) have any tips?

1) Use latest cgminer
2) You cannot use cgminer before 3.3.1
3) (you've probably already done this) Zadig as mentioned in README, ASIC-README and FPGA-README
Then report back if it's still not working

[kano]

I've looked through the FAQ and SCRYPT-README file, but could not find an answer to this.

If I run the following with version 3.3.2, the following error comes back:

Code:

cgminer --scrypt
cgminer: --scrypt: unrecognized option 

Every thread I found from Googling says to recompile the source in linux and enable scrypt. However I am using windows and can not rebuild.

Does anyone know where to find a cgminer binary for windows with scrypt enabled? I would have thought it would be included in the standard build.

Well, 3.3.0 is in my cgminer-binaries (as listed in the first post)
https://github.com/kanoi/cgminer-binaries

I just added 3.3.1 in there now also.

I added 3.3.2 yesterday, however, the 3.3.2 in my cgminer-binaries doesn't have the updated windows zip file unfortunately ...

[ak49er]

Having trouble downloading 3.3.2.  Can't get to the main site as the connection times out, and GitHub isn't giving me a download option but instead trying to open the file in the browser.  Not had this trouble before.  Any ideas?