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.

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

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

Occationally the cgminer log says:


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)

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?

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

I have an Avalon batch3 4 modules, firmware 20130723.
After a few hours of hashing, some of the modules stops (once all stopped, once three of them, once two of them). The other(s) continue hashing.
Temperatures are normal, 21,65,50.
It happened @300 and @282MHz, although unit can hash @350MHz at least for some time.
I have measured power consumption at the wall and it's in normal PSU parameters.
When module(s) stop, there's this error in System Log:
Any ideas?

Default target was 70, cutoff 90. I have put them at 65 and 85.