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

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 07:04:32 PM

Quote from: Wolf0 on March 29, 2013, 06:22:45 PM

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?

I don't know what TRC is. Try it and see?

Honestly, I don't really know how to set up a pool. I'm a programmer, but I haven't found much information out there. If you could point me to a resource, that'd be awesome.

jhd

member

Activity: 63

Merit: 10

No one for help?

dresdenreader

full member

Activity: 239

Merit: 100

Additionally, this is what I'm seeing when I run the -n command.

The first snipped is the output from 2.10.3.

Code:

 [2013-04-03 21:19:29] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2013-04-03 21:19:29] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2013-04-03 21:19:29] CL Platform 0 version: OpenCL 1.2 AMD-APP (1124.2)
 [2013-04-03 21:19:29] Platform 0 devices: 2
 [2013-04-03 21:19:29] 	0	Cayman
 [2013-04-03 21:19:29] 	1	Cayman
 [2013-04-03 21:19:29] Failed to ADL_Adapter_ID_Get. Error -1
 [2013-04-03 21:19:29] GPU 0 AMD Radeon HD 6900 Series hardware monitoring enabled
 [2013-04-03 21:19:29] GPU 1 AMD Radeon HD 6900 Series hardware monitoring enabled
 [2013-04-03 21:19:29] 2 GPU devices max detected

I ran this with the newest debug version of cgminer.exe and got the exact same results (minus the newly added USB support of course.)

dresdenreader

full member

Activity: 239

Merit: 100

Was wondering if someone could help me troubleshoot my cgminer.

As I've stated in another post, for whatever reason I am unable to mine with any version of CG Miner past 2.10.3. I'm able to mine without any issue whatsoever using 2.10.3. But starting at 2.10.4 and onward, CG Miner just stops running shortly after it probes for an alive pool.

Card Info - HIS H699F4G4M Radeon HD 6990 - http://www.newegg.com/Product/Product.aspx?Item=N82E16814161366

Driver Info - AMD Catalyst™ 13.2 Beta Driver - http://support.amd.com/us/kbarticles/Pages/amdcatalyst132betadriver.aspx

OS - Windows 8 Pro

AMD SDK Info - http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/

AMD-APP-SDK-v2.8-Windows-64.exe

AMD 6990

Only logs recovered.

Code:

 [2013-04-03 20:47:55] Started cgminer 2.11.3
 [2013-04-03 20:47:56] Probing for an alive pool

This is the command line I'm using: (same command line works perfectly with 2.10.3)

Code:

@echo off
TIMEOUT 60
cgminer.exe -o stratum+tcp://stratum.btcguild.com:3333 -u username_1 -p pass -I 9 --gpu-memclock 300 -w 128 --auto-fan --auto-gpu --temp-target 70 --temp-overheat 80 2>logtofile.txt

Lastly, I installed Dr Mingw debugger and this is the output text from cgminer when it crashes:

Code:

cgminer.exe caused an Access Violation at location 004312e6 in module cgminer.exe Reading from location 08461499.

Registers:
eax=08461495 ebx=01f90d88 ecx=ffb4cf2b edx=00000008 esi=01f72448 edi=01f90baf
eip=004312e6 esp=0028f4e0 ebp=0028f548 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
004312E6  cgminer.exe:004312E6
004333F0  cgminer.exe:004333F0
00430289  cgminer.exe:00430289
00419380  cgminer.exe:00419380
004010B9  cgminer.exe:004010B9  __mingw_CRTStartup  crt1.c:244

00401284  cgminer.exe:00401284  WinMainCRTStartup  crt1.c:274

76B98543  KERNEL32.DLL:76B98543  BaseThreadInitThunk
76F7AC69  ntdll.dll:76F7AC69  RtlInitializeExceptionChain
76F7AC3C  ntdll.dll:76F7AC3C  RtlInitializeExceptionChain

If you want I can try and provide more information if required, but this is what I'm currently experiencing.

SebastianJu

legendary

Activity: 2674

Merit: 1083

Legendary Escrow Service - Tip Jar in Profile

I have only 53MH/s for a 670M too. The Desktop 670 is with 112MH/s in the list. I tried everything but it remains there. Im not sure if it can be that its so much less only because its the notebook-gpu. But it wouldnt turn out to profit to mine with it anyway most probably.

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 06:17:32 PM

While I agree that using direct USB is probably better overall,

Then we have no argument here! You're agreeing with kano! By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?

jhd

member

Activity: 63

Merit: 10

I setup it and i have only 600mhash for 2 7950 cards. Its very poor

jhd

member

Activity: 63

Merit: 10

Hi i have a problem. I have 2 hd7950 ans i want to mine ppcoin (bitparking) but it dont work. Someone can share me settings for 7950?

SebastianJu

legendary

Activity: 2674

Merit: 1083

Legendary Escrow Service - Tip Jar in Profile

It works now... solution is on bottom...

Hello,

since my roommate has a new notebook with a NVidia GT 670M i wanted to check if its useful to mine with it now. So i set up an account at pool.itzod.ru and used the standard commands they suggested.

I tried with -I 9 but it failed everytime. The driver crashed. But under 9 it works fine at least. But i wondered by its only 14MH/s. It should be 112MH/s judging from the tables. So i checked GPU-Z and found that only the desktop-GPU is working. Optimus isnt enabling the GTX. And this gpu works with 14MH/s. I then tried forcing the use of the GTX for the cgminer.exe. But it doesnt change. Its still using the desktop-gpu but with even less MH/s. Its 1-5 only.

What can i do to force the use of the gtx 670M? And is it maybe even possible to use both gpus at the same time?

I wonder why it crashed with -I 9 when its the standard. But maybe it will work with the normal GPU with such values.

Does one have disadvantages using stratum with gpu or isnt there a disadvantage?

Thanks!

Edit: I checked out the command -n and got this result:

Quote

F:\Programme\CGMiner>cgminer.exe -n
CL Platform 0 vendor: Intel(R) Corporation

CL Platform 0 name: Intel(R) OpenCL
CL Platform 0 version: OpenCL 1.1
Platform 0 devices: 1
0 Intel(R) HD Graphics 4000
CL Platform 1 vendor: NVIDIA Corporation

CL Platform 1 name: NVIDIA CUDA
CL Platform 1 version: OpenCL 1.1 CUDA 4.2.1

Platform 1 devices: 1
0 GeForce GTX 670M
Unable to load ati adl library
1 GPU devices max detected
USB all: found 6 devices - listing known devices

No known USB devices

Intel HD Graphics 4000 is the normal GPU and GeForce GTX 670M is the fast GPU. Optimus should switch between it when speed is needed. It seems to not work.
So i tried the param -d 1 to use the second GPU but it told me there is no device.

Edit2: It works now. I used the param --gpu-platform 1 -d 0 and now the real gpu is mining...

I will test if i can mine with the other too now. But at least it runs now...

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 03:36:44 PM

USB does, yes. But not the devices in question.

If that's the case, then I suppose I see no real benefit to using libusb either.

psychok9

full member

Activity: 247

Merit: 100

Quote from: psychok9 on April 02, 2013, 11:44:46 PM

Hello guys,
I've tried today last cgminer(2.11.3win32), on my Win8x64/Radeon 5850 card/Catalyst 13.3 beta but it crash on start.

Code:

cgminer -o stratum+tcp://coinotron.com:3334 -u blabla -p blabla --scrypt --thread-concurrency 8000 -I 18 -g 1 -w 256

Can you help me?

On Ubuntu 12.10/Catalyst 2:9.000-0ubuntu3 works flawlessly.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: M3t on April 03, 2013, 01:31:35 AM

How do i --enable-cpu ?

doesn't seem to work o.0

CPU mining is not supported as per the README

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 10:14:25 AM

Quote from: Wolf0 on March 29, 2013, 10:00:15 AM

Quote from: Luke-Jr on March 29, 2013, 09:37:24 AM

Quote from: Wolf0 on March 29, 2013, 06:03:58 AM

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?

Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack.

Right...

Quote from: Wolf0 on March 29, 2013, 10:00:15 AM

And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.

Even if you implement your own TCP/IP stack on top of it?

But it's nothing like that. USB provides a lot more than serial transfers, as kano said. So it's not a reimplementation.

M3t

newbie

Activity: 42

Merit: 0

also, does it matter how many threads i have per GPU? doesn't seem to effect anything... hmm... ?

M3t

newbie

Activity: 42

Merit: 0

How do i --enable-cpu ?

doesn't seem to work o.0

lumberjack

newbie

Activity: 42

Merit: 0

Figured I'd test out scrypt mining, since I've never looked at it before today. Yes, yes, I'm late to the LTC party. Still haven't arrived.

Code:

 [2013-04-03 04:29:42] Error -11: Building Program (clBuildProgram)
 [2013-04-03 04:29:42] "/tmp/OCLpFoFQK.cl", line 762: error: identifier "LOOKUP_GAP" is undefined
        const uint ySIZE = (1024/LOOKUP_GAP+(1024%LOOKUP_GAP>0));
                                 ^

"/tmp/OCLpFoFQK.cl", line 763: error: identifier "CONCURRENT_THREADS" is
          undefined
        const uint xSIZE = CONCURRENT_THREADS;
                           ^

2 errors detected in the compilation of "/tmp/OCLpFoFQK.cl".

Internal error: clc compiler invocation failed.

Running a pair of 7970s, Catalyst 12.6 ("8.98.2" driver). Linux 2.6.32-5-amd64. cgminer 2.11.3, latest pull from git. I've tried poking different SDK versions in (2.6, 2.7, 2.8), but 2.8 makes my cards undetectable by cgminer. Have not messed with other catalyst versions yet; I need to pull an image of the USB stick before I try to break something that severely.

Searches on CONCURRENT_THREADS in this thread pointed to a post that referred to a different thread that didn't appear to contain an answer (was the rally to raise funds to get scrypt included in cgminer) and it eventually referred back to this thread. I unfortunately didn't see much on LOOKUP_GAP errors, either.

Has anyone seen this behavior before? Based on the 'undefined' errors when compiling the kernel I assume I'm missing the definitions in the headers with the CL platform, which makes me think SDK or driver version issues... the 2.7 SDK lib/x86_64 files are symlink'd into /usr/lib and the CL header directory into /usr/include. cgminer compiles fine; the problem comes at execution time and only if scrypt is selected as the kernel. (except in the case of 2.8 SDK, in which case it can't enumerate cards regardless of kernel)

EDIT: Fixed. Learned that it's not enough to set kernel:scrypt. also must set scrypt:true.

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 09:37:24 AM

Quote from: Wolf0 on March 29, 2013, 06:03:58 AM

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?

Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack. And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.

psychok9

full member

Activity: 247

Merit: 100

Hello guys,
I've tried today last cgminer(2.11.3win32), on my Win8x64/Radeon 5850 card/Catalyst 13.3 beta but it crash on start.

Code:

cgminer -o stratum+tcp://coinotron.com:3334 -u blabla -p blabla --scrypt --thread-concurrency 8000 -I 18 -g 1 -w 256

Can you help me?

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on April 02, 2013, 05:03:32 PM

Quote from: osoverflow on April 02, 2013, 04:51:26 PM

Hi! May I ask you where do I get the bflsc drivers?

https://github.com/puke-jr/barbieminer

osoverflow - careful with that, his code is known to brick Avalons, and who knows what his hacked up untested code will do to the BFL SC.
He released the BFLSC code before a working device even existed ...
Once we have one (soon) we'll complete the code and release a tested working version.
We don't like the idea of releasing untested code to brick people's hardware, so we don't do it.
This of course directly relates to what I said about the crappy clone way back when he copied cgminer almost a year ago ...
https://bitcointalk.org/index.php?topic=78192.40

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: Luke-Jr on March 29, 2013, 12:57:25 AM

Quote from: Wolf0 on March 29, 2013, 12:48:56 AM

Quote from: Luke-Jr on March 29, 2013, 12:45:37 AM

Quote from: kano on March 29, 2013, 12:30:00 AM

Quote from: Luke-Jr on March 29, 2013, 12:13:00 AM

Quote from: Wolf0 on March 28, 2013, 11:54:29 PM

That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary.

You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs).

Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...

You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying...

If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get.
On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself.

Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it.

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?

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