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

[lano1106]

thanks Kano.

I think that I have spotted the commit you mention:

usbutils/icarus include more locking to usbdev access on June 25th. Almost right after 3.3.1 release date. I guess that it means the next release is coming soon.

I'm now running master-git.

I still have spurious

AMU7: Comms error (werr=-7 amt=0)

that come and leave but so far I have an uptime of half an hour and things feels better.

I'll report back tomorrow how the night went with the git version.

[1714258602]

1714258602

[1714258602]

1714258602

[1714258602]

1714258602

[STT]

install win7x64

Just do it

[kano]

thanks Kano.

I think that I have spotted the commit you mention:

usbutils/icarus include more locking to usbdev access on June 25th. Almost right after 3.3.1 release date. I guess that it means the next release is coming soon.

I'm now running master-git.

I still have spurious

AMU7: Comms error (werr=-7 amt=0)

that come and leave but so far I have an uptime of half an hour and things feels better.

I'll report back tomorrow how the night went with the git version.

-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git)
In your case it was sending work to the device.
Basically means it took too long (more than 200ms) to write to the device.
This can also be caused by device failure e.g. overheat
The code does a device reinitialise then will try again with a new work item.
i.e. I try to reset it and see if that fixes it.

Edit: ... no temperature sensors ... good design that one

[lano1106]

-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git)
In your case it was sending work to the device.
Basically means it took too long (more than 200ms) to write to the device.
This can also be caused by device failure e.g. overheat
The code does a device reinitialise then will try again with a new work item.
i.e. I try to reset it and see if that fixes it.

You definitely made a great job. I still see werr -7 from time to time but git version seems to cope way better with the situation than 3.3.1 did.

Everytime I see werr -7, after a few seconds, cgminer fallback in normal mode and all BEs are online and hashing!

[kano]

-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git)
In your case it was sending work to the device.
Basically means it took too long (more than 200ms) to write to the device.
This can also be caused by device failure e.g. overheat
The code does a device reinitialise then will try again with a new work item.
i.e. I try to reset it and see if that fixes it.

You definitely made a great job. I still see werr -7 from time to time but git version seems to cope way better with the situation than 3.3.1 did.

Everytime I see werr -7, after a few seconds, cgminer fallback in normal mode and all BEs are online and hashing!

Thanks - good to know it is getting the desired result.

[Rugien]

Why is it not possible to use socks5 proxy with stratum pool since cgminer 3.1.1?
It worked fine with 3.1.0.

[-ck]

Why is it not possible to use socks5 proxy with stratum pool since cgminer 3.1.1?
It worked fine with 3.1.0.

Check 3.1.1 changelog

[gyverlb]

I just noticed something a bit odd with cgminer on avalon and p2pool.
I compared CPU usage/load between mining on bitminter with stratum and mining on p2pool with stratum. Seemed pretty similar (with the obvious ~10min between Bitcoin blocks vs ~30s between p2pool shares).

With bitminter, cgminer uses ~12% of the CPU on the Avalon, with p2pool it uses ~65%. I forced a fixed difficulty of 64 on p2pool to try to help (the difficulty algorithm makes small changes often which could explain some additional processing) with no measurable effect. The resulting overall load is ~0.9 on p2pool and ~0.2 on Bitminter.

This is not an average with large peaks and low usage between them (that could be linked to new work every ~30s on p2pool), it's constant. Some people have reported Avalon freezes/crashes on p2pool and it might be due to a temperature problem: the poor CPU might not have been tested at a constant 60% usage. Give it an already toasty environment and add high CPU usage -> overheat.

This high CPU usage might point to some inefficiencies. I'm not yet mining full time on p2pool because preliminary results show only ~90% efficiency (which seems to imply a average ~3s latency somewhere). This latency might be a completely different problem though.

Hope it can help someone understand what is going on.

[-ck]

The p2pool blockchain data is massive and the power of the wrt703n in the avalon is pitiful. Presumably it's the extra workload of dealing with that that uses a lot more CPU. Also the latency of an Avalon sucks dicks on p2pool, throwing out about 3% of work when the block change is 30s (it used to be much worse at 10s). You can run the Avalon on a regular PC via a USB cable to not have CPU usage problems but that won't fix the latency issues, as it is a major Avalon design flaw. p2pool has improved to work with ASICs, but now the hardware needs to catch up.

[Jcw188]

Has running the "gpu max alloc percent" worked for anyone when they were having issues?  How do I do it on windows without a .bat file, can I just open a command prompt and type it in?  Thanks, I'm looking for why I only get 30 khash with a 6570 no matter the settings I try

[gyverlb]

The p2pool blockchain data is massive and the power of the wrt703n in the avalon is pitiful. Presumably it's the extra workload of dealing with that that uses a lot more CPU. Also the latency of an Avalon sucks dicks on p2pool, throwing out about 3% of work when the block change is 30s (it used to be much worse at 10s). You can run the Avalon on a regular PC via a USB cable to not have CPU usage problems but that won't fix the latency issues, as it is a major Avalon design flaw. p2pool has improved to work with ASICs, but now the hardware needs to catch up.

Thanks I suspected something like this. Time to open this beast and make place for an USB cable :-)

[bitflank]

Hey everyone. I think I'm having some trouble with failsafe, and I can't seem to shake it!

LukeJr over at eligius said that the pool was working properly, so I assume this is on my side.

Yesterday, and last night, Eligius connection was interrupted. It then reassigned difficultly and sat connected instead of rolling over to my failsafe. This doesn't *seem* to be affecting my slush or BTCguild connections, but I have seen it happen when BTCguild is down.

If anyone could give me some insight or maybe some troubleshooting options for making failsafe work. I'd be insanely and infinitely

[os2sam]

Hey everyone. I think I'm having some trouble with failsafe, and I can't seem to shake it!

LukeJr over at eligius said that the pool was working properly, so I assume this is on my side.

Yesterday, and last night, Eligius connection was interrupted. It then reassigned difficultly and sat connected instead of rolling over to my failsafe. This doesn't *seem* to be affecting my slush or BTCguild connections, but I have seen it happen when BTCguild is down.

If anyone could give me some insight or maybe some troubleshooting options for making failsafe work. I'd be insanely and infinitely

Well it's failover not failsafe, I believe.

You use it by adding more than one pool to the command line.  After the miner starts go to your pool list and verify that they are all alive.  I would also switch to each one to verify that it actually works and that you entered everything correctly.

Some pools fail in a way that the mining node keeps sending the miner work so the mining software can't detect the outage.  I have no idea about Eligius though, so I don't know if that fits or not.
Sam

[ajas]

Occationally the cgminer log says:

Code:

BAJ 0:  max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U:  2.26/m
--------------------------------------------------------------------
 [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0)
 [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0)
 [2013-07-31 23:36:12] BAJ 2 failure, disabling!
 [2013-07-31 23:36:12] Thread 3 being disabled

and my Jalapeno stops working.

Can anybody tell me what this (especially the codes err=..., amt=...) mean ?

Thanks in advance

[lano1106]

Occationally the cgminer log says:

Code:

BAJ 0:  max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U:  2.26/m
--------------------------------------------------------------------
 [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0)
 [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0)
 [2013-07-31 23:36:12] BAJ 2 failure, disabling!
 [2013-07-31 23:36:12] Thread 3 being disabled

and my Jalapeno stops working.

Can anybody tell me what this (especially the codes err=..., amt=...) mean ?

Thanks in advance

amt = amount (I think...). Possibly if i/o op partially succeeded. Tells you the amount of bytes that were transfered., Personally I have never seen anything else than 0
err = error code. This is specific to the function called.

depending on the trace err is werr or rerr to indicate if the error happened on read or write

For instance error returned for doing i/o with a USB device usually maps with libusb error codes that can be found at

/usr/include/libusb-1.0/libusb.h

ie:

LIBUSB_ERROR_TIMEOUT = -7,

[kano]

Occationally the cgminer log says:

Code:

BAJ 0:  max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U:  2.26/m
--------------------------------------------------------------------
 [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0)
 [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0)
 [2013-07-31 23:36:12] BAJ 2 failure, disabling!
 [2013-07-31 23:36:12] Thread 3 being disabled

and my Jalapeno stops working.

Can anybody tell me what this (especially the codes err=..., amt=...) mean ?

Thanks in advance

It means the device disconnected (the second error = -4)
My first guess would be a bad or loose USB cable.
Second guess would be a bad hub if you are using a USB hub.
Also, what version of cgminer is it?

(Aside: rerr and werr are in the Icarus driver only - in the BAS driver you see the actual commands GetResults and RequestResults, since there are a lot more different commands on the BASs)

[crazyates]

I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer.

Other than that issue, it's working great on my BFL equipment. Thanks!

[kano]

I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer.

Other than that issue, it's working great on my BFL equipment. Thanks!

Yes I have seen curses go silly and lose an escape code and start spitting random junk into the window header name even on linux
So either it is indeed curses on windows or some command prompt problem.
Also note that Ctrl-S will pause the screen and Ctrl-Q unpause it.
But just to check - you mean that you didn't stop/restart cgminer, just minimised the window and brought it back up?

[mruiter]

http://pastie.org/private/qzjzezzghx4ojwyysygfqw

on Ubuntu 13.04
the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success.

I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically  do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success.

Thanks, that info is perfect and says exactly what I'd hope it says.
For 12.04 the problem for you is almost certainly in the libusb version.
I expect (though I'll wait to see before I'm 100% certain) that current git and latest libusb should not get SICK devices, should not hash at ~100MH/s for some devices (instead of ~333MH/s) and should not have regular TIMEOUT errors (a rare few is OK)

Detection problems 'might' also be addressed by current git since there is a usb config setup change I've added that may help
Though interestingly enough, writing this test code I found a situation where it would actually get out of sync with replies during initialisation, that I'll look into and see if it is related, once the libusb version issue is clarified and resolved.

FYI im on 13.04 not 12.04.

I just rebuilt cgminer (newest commit bda1e333222e9921be793a1e517d84d4aba88ea5)
./configure command:-

Code:

LIBUSB_CFLAGS="-I/home/xxx/tmp/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="/home/xxx/tmp/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" ./configure --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon

Summary: http://pastie.org/private/5qstv1txipwwddh97ujhmq

both AMUs are running at ~333MH/s.. and they start mining as soon as cgminer starts. Stopped and started a few times to be sure.

If the problem is fixed for most linux users by using a specific libusb version AND inclusion of this version of libusb in distro repositories is not in the horizon, i guess cgminer should bundle the working lib.

I Also have problems. On my USB there are 10 USB Eruptions en 1 BFL Jap. I pulled the latest again from github, build the latest libusb in the .16 range and build both with a configure pointing to the newly build usblib libs.

Result: Same problem, only 4 USB Erups are getting work done just above 100H the rest is going to SICK after a few moment.
I am using Raspberry PI model B , Debian Weezy fully updated and github cgminer and latest usblib.
The BFL is on one USB port the Eruptors are on the other with 2 hubs every hub beining powered by 5Amps PSU so it's no power issue at all.
BFGMiner (using plain serial comms) is working fine with very low hardware error rate.

I Guess maybee its another lib that is causing the problem , I read a lot of people on RaspPi 's with the problem and running Debian Wheezy on it. When i used ArchLinux it worked fine. But the kernel watchdog driver is not ok in that distribution and i want is the help itself when i crashes.

[kano]

What you are showing there is libusb failing to timeout.
That's what the test program will test and show for the version of libusb you use.
I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git:
https://github.com/kanoi/cgminer-binaries

On linux, To use the working libusb for cgminer instead of the system libusb -
First install udev-dev via one of:
Fedora: yum install libgudev1
Ubuntu derivatives: apt-get install libudev-dev
Arch: it should be installed by default as part of systemd
When you are in the cgminer folder:
mkdir libusb
cd libusb
wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true
tar -xvf libusb-1.0.16-rc10.tar.bz2
cd libusb-1.0.16-rc10
./configure
make
cd ..
cd ..

If you have already autogen/configured cgminer, next you want to edit Makefile
Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/
Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l)
Then
make clean
make
and now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly
N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb