Bitcoin Forum
December 11, 2016, 12:17:31 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 [372] 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4828260 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 07, 2012, 11:21:08 PM
 #7421

if you could, it'd be extremely helpful to add a flag to the program to simply ignore the memory size checking and create the pad on the GPU anyway (for some reason, cgminer is only reporting that my video cards have 512mb of memory when they have 3gb.  I don't know why this is)

It will set it to whatever you choose regardless if it can instead of what it detects as the maximum.

The reported size is just the reported max size allocatable by opencl, it is NOT the gpu ramsize. I already said that it will try to set it to what you set it to. It fails, and we are back to my original response - I have no idea why it fails, but that is the response to the command asking for that much memory.

Is that something you need to get and store with clGetDeviceInfo?  Are you sure that that's not just the max default allocatable size for OpenCL?

From http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf#page=52 :
Quote
CL_INVALID_BUFFER_SIZE returned if size is 0 or is greater than
CL_DEVICE_MAX_MEM_ALLOC_SIZE value specified in table 4.3 for all devices in
context.

CL_DEVICE_MAX_MEM_ALLOC_SIZE specifications
Quote
CL_DEVICE_MAX_MEM_ALLOC_SIZE (cl_ulong) Max size of memory object allocation in bytes.  The minimum value is max (1/4th of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024)
ulong is a huge integer, it should be able to be set higher than 512MB

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
1481458651
Hero Member
*
Offline Offline

Posts: 1481458651

View Profile Personal Message (Offline)

Ignore
1481458651
Reply with quote  #2

1481458651
Report to moderator
1481458651
Hero Member
*
Offline Offline

Posts: 1481458651

View Profile Personal Message (Offline)

Ignore
1481458651
Reply with quote  #2

1481458651
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 07, 2012, 11:28:04 PM
 #7422

if you could, it'd be extremely helpful to add a flag to the program to simply ignore the memory size checking and create the pad on the GPU anyway (for some reason, cgminer is only reporting that my video cards have 512mb of memory when they have 3gb.  I don't know why this is)

It will set it to whatever you choose regardless if it can instead of what it detects as the maximum.

The reported size is just the reported max size allocatable by opencl, it is NOT the gpu ramsize. I already said that it will try to set it to what you set it to. It fails, and we are back to my original response - I have no idea why it fails, but that is the response to the command asking for that much memory.

Is that something you need to get and store with clGetDeviceInfo?  Are you sure that that's not just the max default allocatable size for OpenCL?

From http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf#page=52 :
Quote
CL_INVALID_BUFFER_SIZE returned if size is 0 or is greater than
CL_DEVICE_MAX_MEM_ALLOC_SIZE value specified in table 4.3 for all devices in
context.

CL_DEVICE_MAX_MEM_ALLOC_SIZE specifications
Quote
CL_DEVICE_MAX_MEM_ALLOC_SIZE (cl_ulong) Max size of memory object allocation in bytes.  The minimum value is max (1/4th of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024)
ulong is a huge integer, it should be able to be set higher than 512MB
That has nothing to do with what I said. It's not like I'm making the number up, it reads it back from the device. It does NOT mean the amount of memory the device has. You have read the docs correctly and that is the value reported back for that max alloc size by your device.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 08, 2012, 12:28:39 AM
 #7423

That has nothing to do with what I said. It's not like I'm making the number up, it reads it back from the device. It does NOT mean the amount of memory the device has. You have read the docs correctly and that is the value reported back for that max alloc size by your device.

Okay, I had a look at reaper's source code to see if something different is being done then.  The initialization is almost the same, however reaper first declares padbuffer8 using this command:
Code:
cl_mem padbuffer8
Other than that it's almost verbatim.  Does the usage of a memory object allow you to override the limitations imposed by the buffer size?
Also, why does my 7950 have the same buffer size restrictions as my 7770?

There are also a number of calls to clSetKernelArg in reaper that I'm not sure what they're doing (or if they're already included elsewhere in cgminer).

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 12:39:27 AM
 #7424

That has nothing to do with what I said. It's not like I'm making the number up, it reads it back from the device. It does NOT mean the amount of memory the device has. You have read the docs correctly and that is the value reported back for that max alloc size by your device.

Okay, I had a look at reaper's source code to see if something different is being done then.  The initialization is almost the same, however reaper first declares padbuffer8 using this command:
Code:
cl_mem padbuffer8
Other than that it's almost verbatim.  Does the usage of a memory object allow you to override the limitations imposed by the buffer size?
Also, why does my 7950 have the same buffer size restrictions as my 7770?

There are also a number of calls to clSetKernelArg in reaper that I'm not sure what they're doing (or if they're already included elsewhere in cgminer).

Code:
./ocl.h:        cl_mem padbuffer8;

Yes it's all the same... as I said the only thing different is it does not check the return codes from the opencl calls. Once again I have to ask you, are you actually getting more shares returned by raper. Please don't assume that because the hashrate displays higher that that is evidence.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 08, 2012, 12:42:33 AM
 #7425

Yes it's all the same... as I said the only thing different is it does not check the return codes from the opencl calls. Once again I have to ask you, are you actually getting more shares returned by raper. Please don't assume that because the hashrate displays higher that that is evidence.

Okay.  I'll run it for exactly 5 minutes with both programs and report back the number of shares I get.  I'm going to have to run cgminer with suboptimal settings (thread_concurrency = 8000, intensity = 13) because otherwise I'll get all hardware errors.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Mobius
Hero Member
*****
Offline Offline

Activity: 957



View Profile
October 08, 2012, 12:48:10 AM
 #7426

Yes it's all the same... as I said the only thing different is it does not check the return codes from the opencl calls. Once again I have to ask you, are you actually getting more shares returned by raper. Please don't assume that because the hashrate displays higher that that is evidence.

Okay.  I'll run it for exactly 5 minutes with both programs and report back the number of shares I get.  I'm going to have to run cgminer with suboptimal settings (thread_concurrency = 8000, intensity = 13) because otherwise I'll get all hardware errors.

Use the reported # shares at the pool
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 12:56:15 AM
 #7427

Yes it's all the same... as I said the only thing different is it does not check the return codes from the opencl calls. Once again I have to ask you, are you actually getting more shares returned by raper. Please don't assume that because the hashrate displays higher that that is evidence.

Okay.  I'll run it for exactly 5 minutes with both programs and report back the number of shares I get.  I'm going to have to run cgminer with suboptimal settings (thread_concurrency = 8000, intensity = 13) because otherwise I'll get all hardware errors.
at least make it a multiple of the shaders count, not 8000

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 08, 2012, 12:56:53 AM
 #7428

Reaper (thread_concurrency=24000, v=1, w=64, lookup_gap=2, I=20): 449 shares accepted
cgminer (thread_concurrency=8000, v=1, w=64, lookup_gap=2, I=13): 232 shares accepted

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 08, 2012, 01:04:53 AM
 #7429

at least make it a multiple of the shaders count, not 8000

okay;

cgminer (thread_concurrency=7168, v=1, w=64, lookup_gap=2, I=13): 230 shares accepted

I spent one hell of a long time tweaking the 7xxx cards (~6 hours) with reaper and found the following:
- there is an optimal thread concurrency equal to approximately 64 * bits_bus_width
- above or below slightly this thread concurrency produces approximately the same results so long as the number is a multiple of 64; 8000 seems optimal for my 7770 while 24000 seems optimal for my 7950s
- using too small of a thread concurrency results in hardware errors with high intensities, so low intensities of ~13 must be used instead, the lower the thread concurrency, the lower the intensity allowable before hardware errors occur
- worksize, vectors, and sharethreads have little impact on performance

i'm really, really leaning towards larger buffer sizes being required for the 7xxx series in order to hash effectively.

I'm going back to mining with reaper now.  I wouldn't bitch about this but reaper seems to suddenly kill the buffer of one of my cards after 12 or so hours and has to be restarted (the memory usage just disappears and the hash rate goes down to 10kh/s), which is a pain in my ass.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 01:09:38 AM
 #7430

at least make it a multiple of the shaders count, not 8000

okay;

cgminer (thread_concurrency=7168, v=1, w=64, lookup_gap=2, I=13): 230 shares accepted

I spent one hell of a long time tweaking the 7xxx cards (~6 hours) with reaper and found the following:
- there is an optimal thread concurrency equal to approximately 64 * bits_bus_width
- above or below slightly this thread concurrency produces approximately the same results so long as the number is a multiple of 64; 8000 seems optimal for my 7770 while 24000 seems optimal for my 7950s
- using too small of a thread concurrency results in hardware errors with high intensities, so low intensities of ~13 must be used instead, the lower the thread concurrency, the lower the intensity allowable before hardware errors occur
- worksize, vectors, and sharethreads have little impact on performance

i'm really, really leaning towards larger buffer sizes being required for the 7xxx series in order to hash effectively.

I'm going back to mining with reaper now.  I wouldn't bitch about this but reaper seems to suddenly kill the buffer of one of my cards after 12 or so hours and has to be restarted (the memory usage just disappears and the hash rate goes down to 10kh/s), which is a pain in my ass.
Yes I think you are better off with reaper because it just ignores the errors. Sometimes that works, and as you have seen, eventually it fails. I can't afford to have cgminer do that kind of random thing though. Sorry I can't help you any further with scrypt on cgminer.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
October 08, 2012, 04:51:30 AM
 #7431

okay, i'll just write a python script to restart it again every two hours i guess.

Code:
import os, subprocess, time

while True:
      print("Starting reaper...")
      p = subprocess.Popen("C:\\Users\\my-pc\\Desktop\\reaper\\reaper.exe")
      time.sleep(7200)
      print("Terminating reaper...")
      p.terminate()
      time.sleep(10)

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
wind
Full Member
***
Offline Offline

Activity: 125


View Profile
October 08, 2012, 07:30:50 AM
 #7432

Last time this happened it was a packaging error on my part. I'll reupload shortly. I've reuploaded it.
ckolivas I've just downloaded the last zipped source from your git but the problem is Sad
Code:
OpenCL...............: NOT FOUND. GPU mining support DISABLED

BTC : 1LhadV94a3GqFSFg7eDZiQqERSt78w4fKA
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 07:35:27 AM
 #7433

Last time this happened it was a packaging error on my part. I'll reupload shortly. I've reuploaded it.
ckolivas I've just downloaded the last zipped source from your git but the problem is Sad
Code:
OpenCL...............: NOT FOUND. GPU mining support DISABLED
That's a different one and a problem with your installation lacking the AMD APP SDK, or you lack including the directories (with -I) you have the sdk installed into.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
wind
Full Member
***
Offline Offline

Activity: 125


View Profile
October 08, 2012, 07:42:33 AM
 #7434

That's a different one and a problem with your installation lacking the AMD APP SDK, or you lack including the directories (with -I) you have the sdk installed into.
But why 2.7.5 is compiling well without troubles?
Just Installed APPSDK 2.7 and done all by instruction
Code:
**************************************************************************************
* Install AMD APP SDK, latest version (only if you want GPU mining)                  *
**************************************************************************************
Note: You do not need to install the AMD APP SDK if you are only using Nvidia GPU's
Go to this url for the latest AMD APP SDK:
 http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx
Go to this url for legacy AMD APP SDK's:
 http://developer.amd.com/sdks/AMDAPPSDK/downloads/pages/AMDAPPSDKDownloadArchive.aspx
Download and install whichever version you like best.
Copy the folders in \Program Files (x86)\AMD APP\include to \MinGW\include
Copy \Program Files (x86)\AMD APP\lib\x86\libOpenCL.a to \MinGW\lib
Note: If you are on a 32 bit version of windows "Program Files (x86)" will be
"Program Files".
Note2: If you update your APP SDK later you might want to recopy the above files
THE SAME ERROR
Code:
Configuration Options Summary:

  curses.TUI...........: FOUND: pdcurses
  OpenCL...............: NOT FOUND. GPU mining support DISABLED
configure: error: No mining configured in

BTC : 1LhadV94a3GqFSFg7eDZiQqERSt78w4fKA
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 12:14:25 PM
 #7435

New version - 2.8.1, 8th October 2012

Minor bug hotfix release.

Human readable changelog

Will properly detect when stratum pools are out now.

Full changelog

- Use the stratum url as the rpc url advertised if we switch to it.
- Count an invalid nonce count as a hardware error on opencl.
- Count each stratum work item as local work.
- Cope with one stratum pool being the only active pool when it dies by sleeping
for 5 seconds before retrying to get work from it instead of getting work
indefinitely.
- Detect stratum outage based on either select timing out or receiving an empty
buffer and properly re-establish connection by disabling the stratum_active
flag, coping with empty buffers in parse_stratum.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 08, 2012, 01:13:27 PM
 #7436

cut/paste ...

2.8.1
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.8.1a
https://github.com/kanoi/cgminer/downloads
(it also works on Fedora 16 and 17)

I've deleted the 2.8.0a since 2.8.1 has stratum bug fixes for 2.8.0

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my BFL or my '2xGPU+2xIcarus' (for 10 minutes so far Smiley) on normal pools

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
dlasher
Sr. Member
****
Offline Offline

Activity: 468



View Profile WWW
October 08, 2012, 09:31:35 PM
 #7437

How do you add a stratum only pool?

Quote
Input server details.
URL:
stratum+tcp://X.X.X.X:3333/
Username:
miner-name
Password:
miner-pass
 [2012-10-08 14:27:13] Pool 5 slow/down or URL or credentials invalid
<snip>
5: Enabled Dead Priority 5: http://stratum+tcp://X.X.X.X:3333/  User:miner-name

Not what I typed..



-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 09:59:53 PM
 #7438

How do you add a stratum only pool?

Quote
Input server details.
URL:
stratum+tcp://X.X.X.X:3333/
Username:
miner-name
Password:
miner-pass
 [2012-10-08 14:27:13] Pool 5 slow/down or URL or credentials invalid
<snip>
5: Enabled Dead Priority 5: http://stratum+tcp://X.X.X.X:3333/  User:miner-name

Not what I typed..




cgminer will add http:// if it can't connect to whatever url you gave it. Yes it does look like it shouldn't have done it in this case Tongue The stratum+tcp:// is optional and it will always try stratum on that port first. If it did that then perhaps there was something wrong with the url/port put in or the pool was not responsive at the time.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
dlasher
Sr. Member
****
Offline Offline

Activity: 468



View Profile WWW
October 08, 2012, 11:32:52 PM
 #7439

cgminer will add http:// if it can't connect to whatever url you gave it. Yes it does look like it shouldn't have done it in this case Tongue The stratum+tcp:// is optional and it will always try stratum on that port first. If it did that then perhaps there was something wrong with the url/port put in or the pool was not responsive at the time.

perhaps an additional field for "pool-type" with "stratum, http, both" as options, to allow the user the option to control, including following the x-stratum header?

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 08, 2012, 11:34:29 PM
 #7440

cgminer will add http:// if it can't connect to whatever url you gave it. Yes it does look like it shouldn't have done it in this case Tongue The stratum+tcp:// is optional and it will always try stratum on that port first. If it did that then perhaps there was something wrong with the url/port put in or the pool was not responsive at the time.

perhaps an additional field for "pool-type" with "stratum, http, both" as options, to allow the user the option to control, including following the x-stratum header?


Can you think of a reason you wouldn't want to use stratum mining?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 [372] 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!