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

[-ck]

linux/win/osx/mip/r-pi 3.6.1

+ RK3066 (ug802 etc android linux stick versions...)

I have been running for a week with 3.5 without errors on UG802 mkII with very low overhead under 2.5% CPU 

I am going to make UG802 my main mining platform because it only chews around 6 W and also serves multiple other purposes like web/development & backup server.

New RK3188 is on the way and might give this newest version a shot too.

Wondering should I upgrade to latest because 3.5 seems robust as a rock on rk3066. I'll put some beer pizza money on the way when my wallet updates. Thanks to BFL don't expect to get drunk overfed though.

Great work!

Probably wait. There will likely be a 3.6.2 just around the corner, though so far 3.6.1 is kicking goals on linux.

[-ck]

Won't really help. The debug version only does something if it crashes.

Oh.

Thought you have some other trickery in there :/

I wish. The debug builds in there are based on 3.6.1 currently so they will likely have the memory leak bug inherent in the included libusb. That said, sometimes strangely issues go away on debug builds due to a bug showing up only with optimisations enabled (debug builds have no compiler optimisations).

[viperzero]

Probably wait. There will likely be a 3.6.2 just around the corner, though so far 3.6.1 is kicking goals on linux.

Thanks for info. I am very happy overall with ministick arm xubuntu + Cgminer combo performance. Finally bitcoind catched the blockchain and BTC on the way. Seemed I also accidentally revealed CPU-hog from my previous post, xfce rotating screensaver referring nonexistent content 

[kano]

Why's my API output garbled???
(3.6.1 windows binary)

...

Does java API summary get the same result?

Edit: or to see the JSON version: java API "{\"command\":\"summary\"}"

[kano]

I've been using the cgminer API to get statistics about my mining devices.


One thing I can't seem to find is the current hashrate (or 5sec average hashrate). I see an average hashrate that appears to be since the machines was started but I don't see the current hashrate.

If this statistic is not available, how can I calculate it from what is available?

You can sum the 5s hashrate of each device from the devs reply. It's a good question though why this can't be included in the summary reply.

oh thanks! It was in "devs". I thought I had tried every command. Yeah, it would make sense if it was in "summary".

It's never been in there and I can't ever remember anyone asking for it
(though I could have forgotten )
The 5s is also pretty unreliable ...
I'll add it soonish ... when I prioritise it ...

[Askit2]

On the newest CGMiner 3.6.1 I have an issue on Linux. This problem is on a Raspberry Pi. It wasn't noticeable until I added more jalapeno's.
What happens is this. After running for a while it appears Linux runs out of USB devices. I know the problem is actually my USB devices errors.

The reason this seems like a problem is that when it runs out of devices in 22K shares or so 4 devices will not be working. It happens one at a time until it runs out completely. When it runs out the devices will be back to their initial numbering ex BAJ 7 and zombie. the only fix seems to be to quit cgminer so that it will start over. The hashrate is very low. I assume given enough other errors I would lose all 9.

Since no device was over 3% errors I would have assumed that it wouldn't get disabled as fast as it does. Most errors I notice are in response to a temp request. The reply is in process,0x(something),0x(something)(sometimes a third 0x(something) sometimes 0x00x00x00. At least that is how I remember it. I think that error was on 3.5.1. Current error looks like this

Code:

 [2013-10-16 03:33:04] BAJ 28 usb read err:(1) **UNKNOWN**
 [2013-10-16 03:33:04] BAJ28: QueJobStatus failed (err=1 amt=0)
 [2013-10-16 03:33:04] BAJ 28 failure, disabling!

I am not running the newest raspbian. I use one from 2/13. It holds up longer while mining and less frequently locks up the UI.

I have a different problem on Windows. Using a USB 2 or USB 3 hub the error rate is low. Using usb 1  hub I get devices that have accepted in the single digits like 9 to 300+ errors. I will likely pick up a USB 2.0 hub tomorrow. I see this a lot. I don't think its an error though.

Code:

USB BAJ read 2 bugger buffering 2 extra bytes

[P_Shep]

Won't really help. The debug version only does something if it crashes.

Oh.

Thought you have some other trickery in there :/

I wish. The debug builds in there are based on 3.6.1 currently so they will likely have the memory leak bug inherent in the included libusb. That said, sometimes strangely issues go away on debug builds due to a bug showing up only with optimisations enabled (debug builds have no compiler optimisations).

yeah, stopped working with a stream of mem errors again. actually -11, not -7
giving 3.5.1 another bash now.

[P_Shep]

Why's my API output garbled???
(3.6.1 windows binary)

...

Does java API summary get the same result?

Edit: or to see the JSON version: java API "{\"command\":\"summary\"}"

comes out fine both formats there.

[kano]

Why's my API output garbled???
(3.6.1 windows binary)

...

Does java API summary get the same result?

Edit: or to see the JSON version: java API "{\"command\":\"summary\"}"

comes out fine both formats there.

That means the problem is the code you are using to read the API, not the API.
e.g. a php, json,python or whatever you are using update issue?

[-ck]

On the newest CGMiner 3.6.1 I have an issue on Linux. This problem is on a Raspberry Pi. It wasn't noticeable until I added more jalapeno's.
What happens is this. After running for a while it appears Linux runs out of USB devices. I know the problem is actually my USB devices errors.

The reason this seems like a problem is that when it runs out of devices in 22K shares or so 4 devices will not be working. It happens one at a time until it runs out completely. When it runs out the devices will be back to their initial numbering ex BAJ 7 and zombie. the only fix seems to be to quit cgminer so that it will start over. The hashrate is very low. I assume given enough other errors I would lose all 9.

Since no device was over 3% errors I would have assumed that it wouldn't get disabled as fast as it does. Most errors I notice are in response to a temp request. The reply is in process,0x(something),0x(something)(sometimes a third 0x(something) sometimes 0x00x00x00. At least that is how I remember it. I think that error was on 3.5.1. Current error looks like this

Code:

 [2013-10-16 03:33:04] BAJ 28 usb read err:(1) **UNKNOWN**
 [2013-10-16 03:33:04] BAJ28: QueJobStatus failed (err=1 amt=0)
 [2013-10-16 03:33:04] BAJ 28 failure, disabling!

I am not running the newest raspbian. I use one from 2/13. It holds up longer while mining and less frequently locks up the UI.

I have a different problem on Windows. Using a USB 2 or USB 3 hub the error rate is low. Using usb 1  hub I get devices that have accepted in the single digits like 9 to 300+ errors. I will likely pick up a USB 2.0 hub tomorrow. I see this a lot. I don't think its an error though.

Code:

USB BAJ read 2 bugger buffering 2 extra bytes

On the former issue, you've probably run out of semaphores due to the limit being lower on an RPi. Can't remember offhand how to change them but they require a few sysctl options.

On the latter, that's not a bug but just verbose information you can ignore mostly.

[P_Shep]

Why's my API output garbled???
(3.6.1 windows binary)

...

Does java API summary get the same result?

Edit: or to see the JSON version: java API "{\"command\":\"summary\"}"

comes out fine both formats there.

That means the problem is the code you are using to read the API, not the API.
e.g. a php, json,python or whatever you are using update issue?

Yeah, seems to be the php json_decode() function has stopped working. Bizzare.

[-ck]

New version: 3.6.2, 17th October 2013

New release, 2 new library versions. Finally gave up and moved to libusbx which works less bad on windows with the asynchronous code cgminer uses. Also a new jansson in tree full build.

Human readable changelog:

- New version of jansson has some minor bugfixes, but more importantly now is built properly from within the build tree such that changes to configuration will rebuild it. Alas this makes ./configure now take even longer.
- Change from libusb-1.0.16-rc10 to libusbx-1.0.17. libusb on windows with asynchronous transfers had memory leaks galore and eventually would fail. libusbx does not have this problem, but some people are reporting write timeout issues with it on prolonged use. Linux has no such issues.
- Updates to the way usb work is "scheduled" which might help decrease the risk of timeouts on windows.
- Fixes to the shutdown routine that would get stuck waiting for usb transfers that would never be able to complete.
- Changed the driver model in icarus devices to a slightly lower overhead newer code.
- BF1s weren't showing any WU when hashing, this has been fixed.
- Some earlier BFL SC minirigs were not being properly detected due to inconsistencies in the firmware responses.
- Workarounds to the ./autogen stage of building when people build from git. Note this still does not fully work on macosx but 'autoreconf -fi' should be enough to have the same effect for now.


Full changelog:

- Remove unused components of jansson
- Remove unused parts of libusb
- Work around older libtoolize that fails without top ltmain.sh not being
present during autogen
- Fix open coded use of autoreconf in autogen
- Update jansson to only build parts we require and suited to our build
environment.
- Initial import of jansson-2.5
- Prevent further USB transfers from occurring once the shutdown signal has been
sent to prevent transfers getting stuck and libusb failing to shut down.
- Make the USB polling thread poll every second to potentially aid longer
timeout transfers.
- Set device_diff on work in get_work to not be missed with drivers that use
get_work directly.
- Convert icarus driver to hash_driver_work model.
- bflsc - also allow ' 0' in DEVICES IN CHAIN
- bflsc - allow a 0 in DEVICES IN CHAIN
- Add needed EXTRA_DIST for libusbx.
- Update libusbx configure.ac changes.
- Revert libusb Makefile changes from going to libusbx.
- Fix trivial libusbx warnings.
- Convert libusb-1.0.16-rc10 to libusbx-1.0.17

[Aurum]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

[P_Shep]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

Works for me.

[jamesg]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

Pro tip: Don't use Windoze for mining.  

[os2sam]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

Pro tip: Don't use Windoze for mining.  

What else is there?

[Joshwaa]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

Pro tip: Don't use Windoze for mining.  

What else is there?

Was that just sarcasm from sam? Your getting the hang of it!

[Karin]

I've tried on my Mac build environments and while I can compile and launch cgminer just fine, as well as GPU mine, when attempting to use a USB-based Block Erupter I get the following message and cgminer subsequently quits.

Code:

Failed pipe errno=24 in usbutils.c init_usb_transfer():2215

It looks as though it is perhaps able to do a brief moment (before the first poll?(?)) of hashing, as sometimes I get an accepted share out from it and sometimes not, as shown on the "Summary of runtime statistics" output after cgminer quits.

The last successful version for me on Mac is 3.5.1.  I've tested 3.6.1 and 3.6.2 and both generate the error.  cgminer is built entirely from the included source, no other libs used.  Using "--usb-dump 0" and "--verbose" provides no additional details.  Please let me know if I can help further!

[TR4L]

Just an FYI to ckolivas and kano.  I was trying to mine with 3.6.1 but it wouldn't allow me to run scrypt. I thought I was doing something wrong until I tried 2.11.4 and 3.1.1 and it worked.  Didn't change anything (copied and pasted my .conf files).  I'm running Ubuntu 12.04 LTS, I tried both:  "kernel" : "scrypt", and "scrypt" : true,  and neither worked. 

[LordTheron]

Hello,

I've updated cgminer to the latest one and now none of my bfl miners work. I get usb errors on all of them.  I'm running it on windows 7. Works fine on 3.4.3.. Any idea what may be wrong?