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

[The00Dustin]

It does in Linux, and that's what I'm mainly using

Fair enough.  For some reason, I was thinking you were specifically discussing Windows.  Either I crossed this conversation with another one in the same thread or I confused the -S designations for Windows vs Linux (I don't own any BFL product to help keep this straight in my head, and I was only trying to help).

[1714966535]

1714966535

[1714966535]

1714966535

[BitMinerN8]

Just upgraded to cgminer 2.5.0 on BAMT 0.5, so far so good with 5 BFLs, 1 GPU.

[farfie]

I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.

Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught

[P_Shep]

I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.

Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught

I don't think it means anything.
AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.

I typically get 10-15% discards.

[farfie]

I don't think it means anything.
AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.

I typically get 10-15% discards.

Yes, I believe I spoke too soon. After closer inspection, it seems upon detection of a new block, it dumps everything under - I'm guessing - ST to DW. Just getting rid of old work that has not been processed yet for a block that matters none anymore.

For some reason it seems as though one of the miners always takes about 5 or 6 seconds longer to realize there's a new block. Maybe because of the lack of long poll, the prompt with higher hash speed will always notice first because it needs to send something to realize it's not longer relevant. This would suggest that if you have to use multiple computers to host your gpu's/devices, you should try to spread hash speed as evenly as possible. For solo mining of course, where with long poll this wouldn't matter. At least this is my guess. Not related to CGMiner I know, but I wanted to put it anyway

[dave3]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

[-ck]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

Thanks for the feedback. That was one of the improvements mentioned that I finally got sick of the arguments over and coded up the solution myself. Glad it works for you 

[Luke-Jr]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

[-ck]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD

[Luke-Jr]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD

Speaking the truth by calling out false claims is not FUD.

[crazyates]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD

This was my face when I read that: 

[-ck]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD

Speaking the truth by calling out false claims is not FUD.

You now have the dubious honour of being the first ever person on this forum I've ignored.

[rav3n_pl]

OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?

[DiabloD3]

After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).

That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.

GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD

Speaking the truth by calling out false claims is not FUD.

You now have the dubious honour of being the first ever person on this forum I've ignored.

Surprised it took so long.

[GenTarkin]

I couldnt easily find this anywhere, but whats the proper json format for the new "restricted access" feature? vs full access for remote API accessing of cgminer?

[-ck]

OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?

Being a windows driver bug, there really is nothing I can do about it apart from suggesting trying a different driver version. I'm surprised you hit this bug so quickly after 2.5.0 though since most people find it hitting after a week of running.

[rav3n_pl]

OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?

Being a windows driver bug, there really is nothing I can do about it apart from suggesting trying a different driver version. I'm surprised you hit this bug so quickly after 2.5.0 though since most people find it hitting after a week of running.

Mayeb add some async watchdog that will detect stuck miner (lock over 1 minute), ignore ADL for a while using safe settings (fan on 99%) then try restart it?

[TechCF]

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:

• installed Xcode via App Store
• sudo port install pkgconfig curl +ssl
• ./configure --enable-cpumining
• sudo make install

The error I get when trying with --enable-bitforce is:

Code:

  CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

EDIT: Btw: You must use -w 64 because of the OSX OpenCL bug. And, if you have two adapters, it seems that the weaker one is device 1, and the discrete is 0. E.g. in the mid-2009 MBP: Device 0 is the 9600M and device 1 is the 9400M.

[kano]

I couldnt easily find this anywhere, but whats the proper json format for the new "restricted access" feature? vs full access for remote API accessing of cgminer?

I'm not really sure exactly what you mean by your question - but the API-README contains all the info about the API ...

Edit: If you mean the command line parameters then they are in README for the basic command definitions and more details in API-README

[kano]

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

  CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
 grep B115200 /usr/include/*
 grep B115200 /usr/include/*/*
 grep CBAUD /usr/include/*
 grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.