OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 475.

dlasher

sr. member

Activity: 467

Merit: 250

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

5: Enabled Dead Priority 5: http://stratum+tcp://X.X.X.X:3333/ User:miner-name

Not what I typed..

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

) 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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

wind

member

Activity: 125

Merit: 10

Quote from: -ck on October 08, 2012, 02:35:27 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: wind on October 08, 2012, 02:30:50 AM

Quote from: -ck on October 07, 2012, 04:18:32 PM

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.

wind

member

Activity: 125

Merit: 10

Quote from: -ck on October 07, 2012, 04:18:32 PM

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

tacotime

legendary

Activity: 1484

Merit: 1005

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)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tacotime on October 07, 2012, 08:04:53 PM

Quote from: -ck on October 07, 2012, 07:56:15 PM

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.

tacotime

legendary

Activity: 1484

Merit: 1005

Quote from: -ck on October 07, 2012, 07:56:15 PM

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.

tacotime

legendary

Activity: 1484

Merit: 1005

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tacotime on October 07, 2012, 07:42:33 PM

Quote from: -ck on October 07, 2012, 07:39:27 PM

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

Mobius

hero member

Activity: 988

Merit: 1000

Quote from: tacotime on October 07, 2012, 07:42:33 PM

Quote from: -ck on October 07, 2012, 07:39:27 PM

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

tacotime

legendary

Activity: 1484

Merit: 1005

Quote from: -ck on October 07, 2012, 07:39:27 PM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tacotime on October 07, 2012, 07:28:39 PM

Quote from: -ck on October 07, 2012, 06:28:04 PM

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.

tacotime

legendary

Activity: 1484

Merit: 1005

Quote from: -ck on October 07, 2012, 06:28:04 PM

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).

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tacotime on October 07, 2012, 06:21:08 PM

Quote from: -ck on October 07, 2012, 04:07:12 PM

Quote from: tacotime on October 07, 2012, 03:00:11 PM

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)

Quote from: -ck on October 05, 2012, 05:24:45 PM

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.

tacotime

legendary

Activity: 1484

Merit: 1005

Quote from: -ck on October 07, 2012, 04:07:12 PM

Quote from: tacotime on October 07, 2012, 03:00:11 PM

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)

Quote from: -ck on October 05, 2012, 05:24:45 PM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on October 07, 2012, 04:53:15 PM

Quote from: -ck on October 07, 2012, 04:33:07 PM

It keeps hashing for up to 2 minutes before it can tell the pool is down. How long did you leave it for?

Over 30 minutes? There's something broken in it, really. At this stage I cannot recommend people to update, because when I'll restart the pool (update or whatever), cgminer will freeze forever Sad

.

I hate sockets. They never do what you expect. Ok well it was always going to be a rough introduction.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: -ck on October 07, 2012, 04:33:07 PM

It keeps hashing for up to 2 minutes before it can tell the pool is down. How long did you leave it for?

Over 30 minutes? There's something broken in it, really. At this stage I cannot recommend people to update, because when I'll restart the pool (update or whatever), cgminer will freeze forever Sad

.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on October 07, 2012, 01:15:59 PM

I can confirm the bug, cgminer doesn't detect connection failure.

It keeps hashing for up to 2 minutes before it can tell the pool is down. How long did you leave it for?

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 475. (Read 5806057 times)