1

It seems that litecoin/scrypt support in cgminer is unstable as I've found a lot of mentions of this error in various forums and no real solutions. Some seem to be able to resolve the problem by experimenting with different versions and combinations of drivers and AMD SDK. So far I've tried much and always the same problem. Here's the output from command line:

cgminer --benchmark --scrypt --debug --verbose

 [2013-06-07 00:34:54] Started cgminer 3.2.0
 [2013-06-07 00:34:54] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2013-06-07 00:34:54] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2013-06-07 00:34:54] CL Platform 0 version: OpenCL 1.2 AMD-APP (1124.2)
 [2013-06-07 00:34:54] Platform 0 devices: 1
 [2013-06-07 00:34:54]  0   Tahiti
 [2013-06-07 00:34:54] GPU 0 iAdapterIndex 0 strUDID PCI_VEN_1002&DEV_6798&SUBSYS_254D1458&REV_00_4&176F368&0&0018A iBusNumber 2 iDeviceNumber 0 iFunctionNumber 0 iVendorID 1002 strAdapterName  AMD Radeon HD 7900 Series 
 [2013-06-07 00:34:54] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled
 [2013-06-07 00:34:54] Pushing ping to thread 0
 [2013-06-07 00:34:54] Init GPU thread 0 GPU 0 virtual GPU 0
 [2013-06-07 00:34:54] Popping work to stage thread
 [2013-06-07 00:34:54] CL Platform vendor: Advanced Micro Devices, Inc.
 [2013-06-07 00:34:54] CL Platform name: AMD Accelerated Parallel Processing
 [2013-06-07 00:34:54] CL Platform version: OpenCL 1.2 AMD-APP (1124.2)
 [2013-06-07 00:34:54] List of devices:
 [2013-06-07 00:34:54]  0   Tahiti
 [2013-06-07 00:34:54] Selected 0: Tahiti
 [2013-06-07 00:34:54] Preferred vector width reported 1
 [2013-06-07 00:34:54] Max work group size reported 256
 [2013-06-07 00:34:54] Max mem alloc size is 2951741440
 [2013-06-07 00:34:54] Selecting scrypt kernel
 [2013-06-07 00:34:54] GPU 0: selecting lookup gap of 2
 [2013-06-07 00:34:54] GPU 0: selecting thread concurrency of 22400
 [2013-06-07 00:34:54] Loaded binary image scrypt130511Tahitiglg2tc22400w256l4.bin
 [2013-06-07 00:34:54] Initialising kernel scrypt130511.cl with bitalign, 1 vectors and worksize 256
 [2013-06-07 00:34:54] Creating scrypt buffer sized 1468006400
 [2013-06-07 00:34:54] initCl() finished. Found Tahiti
 [2013-06-07 00:34:54] 1 gpu miner threads started
 [2013-06-07 00:34:54] Pool 0 not providing work fast enough
 [2013-06-07 00:34:54] API not running - API will not be available
 [2013-06-07 00:34:54] Generated benchmark work
 [2013-06-07 00:34:54] Pushing work from pool 0 to hash queue
 [2013-06-07 00:34:54] Generated benchmark work
 [2013-06-07 00:34:54] Pushing work from pool 0 to hash queue
 [2013-06-07 00:34:54] Generated benchmark work
 [2013-06-07 00:34:54] Pushing work from pool 0 to hash queue
 [2013-06-07 00:34:54] Popping ping in miner thread
 [2013-06-07 00:34:54] Popping work from get queue to get work
 [2013-06-07 00:34:54] Got work from get queue to get work for thread 0
 [2013-06-07 00:34:54] Generated benchmark work
 [2013-06-07 00:34:54] Pushing work from pool 0 to hash queue
 [2013-06-07 00:34:54] Generated target 00000000000000000000000000000000000000000000000000000000ffff0000
 [2013-06-07 00:34:55] [thread 0: 18432 hashes, 17.7 khash/sec]
 [2013-06-07 00:34:55] GPU 0 found something?
 [2013-06-07 00:34:55] OCL NONCE 33519 found in slot 0
 [2013-06-07 00:34:55] New best share: 6
 [2013-06-07 00:34:55] GPU0: invalid nonce - HW error
 [2013-06-07 00:34:55] Discarded cloned or rolled work

Any help gratefully received.

3 Answers 3

3

In my experience scrypt mining on GPUs is quite susceptible to cause HW errors and wrong nonces if the parameters are not chosen to match the GPUs the algorithm is run on. As the SCRYPT-README file of cgminer states:

The reason this is crucial is that too high an intensity can actually be disastrous with scrypt because it CAN run out of ram. High intensities start writing over the same ram and it is highly dependent on the GPU, but they can start actually DECREASING your hashrate, or even worse, start producing garbage with HW errors skyrocketing. Note that if you do NOT specify an intensity, cgminer uses dynamic mode which is designed to minimise the harm to a running desktop and performance WILL be poor. The lower limit to intensity with scrypt is usually 8 and cgminer will prevent it going too low.

The --benchmark option you specified in your command line tells cgminer to attempt to find an optimal set of parameters, so it will make a few attempts with high intensities as well, which will fail. Once you figured out a good value for the parameters you should be fine.

1

I'm having the same problem.

I have catalyst 13.4 installed. I tried going back to 12.8 and 12.4, both of them generated "cgminer stopped working" with all versions of cgminer I tried.

I went back to cgminer 2.11.2 and it worked, but performance went way down. I went back to cgminer 2.11.3 and it seems to be working with the same performance and without the nonce errors.

Going to run it overnight and make sure the pool recognises the work units.

Fred

1
  • Ok I might have a look at the source code history then. I'm compiling the very latest source, so 3.2.x.
    – redcalx
    Jun 7, 2013 at 9:47
0

I was getting the same error with cminer 3.1.1 and intensity set to 19. But after lowering the intensity to 18 the HW errors disappeared.

1
  • Same here as Giorgos, but from 14 to 13 (any intensity above 13 causes NONCE errors).
    – user5463
    Jun 7, 2013 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.