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

Agreed, but is 3.2.1 working reliably with the USB Block Erupter under Win7 yet?

Hence why we have direct USB in the new code... it uses a lot less CPU because the ftdi driver is very inefficient.

What level of CPU usage are people getting using CGMiner 3.1.1?

I've got a Win7 x64 setup with a Core i5-3570k and getting about 25% CPU usage, hashing with just one USB Block Erupter.

I can send you an anker 10-port USB 3.0 hub if it will help you track this down faster... I'd like to switch away from 3.1.1 but can't just yet...
PM me if interested.

Thanks. There's a pdcurses bug where it crashes if ap is null. ncurses on linux does not have this problem. Should be fixed in the next version. Disabling the curses interface will avoid it (-T)

Version 3.1.1 worked fine, but I went ahead and compiled it anyway out of interest. The segfault is from libpdcurses when writing    applog(LOG_NOTICE, "Probing for an alive pool");
It might be specific to windows. I left a stacktrace on http://pastebin.com/5eMb5dsf

About having seperate threads - I agree it doesn't make sense to start new ones if it means you have to monitor them all. A bug tracker may be easier to work with than forum threads though.

Thank you good sir.

Thanks, that's precisely what I do. The top thread always points to the announce for the latest release, and I do go to great pains to write human readable changelogs so people can see what has changed, but that does not give the full history. I certainly don't have the time to maintain a wiki.

Yeah, one thread. Unless you were going to move towards a Wiki based system, like Redmine or similar, it could also incorporate bug tracking. I know there is github, but something more non-dev friendly. I find 500+ pages hard to extract useful data, it's a mess. Something structured would most likely cut down on the majority the repetitive questions that were answered 3-4 pages back. Instead of telling everyone to read the README, you tell them to read the WiKi. 

Yep, its in the readme's and/or the Top Post of this thread.

--------------------------------------From Top Post-------------------------
The output line shows the following:
(5s):1713.6 (avg):1707.8 Mh/s | Q:301  A:729  R:8  HW:0  E:242%  U:22.53/m

Each column is as follows:
5s:  A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
Q:   The number of requested (Queued) work items from the pools
A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
E:   The Efficiency defined as number of shares returned / work item
U:   The Utility defined as the number of shares / minute

 GPU 1: 73.5C 2551RPM | 427.3/443.0Mh/s | A:8 R:0 HW:0 U:4.39/m

Each column is as follows:
Temperature (if supported)
Fanspeed (if supported)
A 5 second exponentially decaying average hash rate
An all time average hash rate
The number of accepted shares
The number of rejected shares
The number of hardware erorrs
The utility defines as the number of shares / minute

The cgminer status line shows:
 TQ: 1  ST: 1  SS: 0  DW: 0  NB: 1  LW: 8  GF: 1  RF: 1

TQ is Total Queued work items.
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
DW is Discarded Work items (work from block no longer valid to work on)
NB is New Blocks detected on the network
LW is Locally generated Work items
GF is Getwork Fail Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)

Sounds about right to me too.  Kudos on an imaginative solution/workaround.

Still don't know what your original problem was though.  That wouldn't be giving me a warm fuzzy feeling.
Good Luck,
Sam

keep it simple. one thread.

The nounce is the number that has to be added to the rest of the data in order to obtain a hash that satisfies the difficulty by being smaller than a certain value.
So what happens is that a mining device would report that the hash of a given nounce+data satisfies the difficulty when in fact it doesn't because the computed hash is wrong due to an hw error.
So I think what is bad is the hash computed by the miner. This in turn would cause the nounce being tried "bad" (generating a hash that does not satisfy the difficulty).
Somebody correct me if I'm wrong.
I think it's just a matter of how the error message has been phrased.

no worries, why do people then specify worksize? on the wiki I see 128 and 256 being used.. whats the benefit?

That fixed it thanks! 

How to fix it with Debian 7.0:
sudo cp cgminer-3.2.1/01-cgminer.rules /etc/udev/rules.d/
sudo service udev restart

Now unplug and plug again the usb erupter.
Restart cgminer and it should work.

FWIW, I would say just stick with this one thread and update the OP with a link to the latest notes ITT.

Seeing a thread with 545 pages commands a certain degree of respect and gravitas, with respect to this project. Afraid making a post for each release would fragment things further.

copy the 01-cgminer.rules into /etc/udev/rules.d/ and restart udev.
the permission of the cgminer executable doesnt make any difference

I'm probably just gonna be referred to a README that i read and forgot, but i'll ask anyway. Is there anyplace where all the abreviations on the terminal output are explained?

Also, I'm running, 3.1.1 with ASICminer Eruptors. So i understand that i'll get hardware errors occasionally, i'm curious why it reports the error as a bad nounce? i thought a nounce was just a number.

I have a problem with cgminer on my AsicMiner usb erupter.
3.1.1 works fine, but 3.2.1 gives me this never ending series of errors:

[2013-06-08 19:38:12] USB init open device failed, err -3, you dont have priviledge to access - AMU device 1:9
[2013-06-08 19:38:12] Icarus detect (1:9) failed to initialise (incorrect device?)
 [2013-06-08 19:38:17] USB init open device failed, err -3, you dont have priviledge to access - AMU device 1:9
 [2013-06-08 19:38:17] Icarus detect (1:9) failed to initialise (incorrect device?)
 [2013-06-08 19:38:22] USB init open device failed, err -3, you dont have priviledge to access - AMU device 1:9
 [2013-06-08 19:38:22] Icarus detect (1:9) failed to initialise (incorrect device?)
.....

The only usb connected mining hardware is the AsicMiner usb Erupter.
I set the same permissions on both 3.1.1 and 3.2.1:

-rwxr-sr-x 1 andrea dialout  304853 May 24 09:46 cgminer-3.1.1/cgminer
-rwxr-sr-x 1 andrea dialout 1160140 Jun  8 19:35 cgminer-3.2.1/cgminer

Running debian 7.0.

cgminer compiled with ./configure --enable-icarus --enable-bflsc --disable-opencl

------------------------------------------------------------------------
cgminer 3.2.1
------------------------------------------------------------------------


Configuration Options Summary:

  curses.TUI...........: FOUND: -lncurses
  OpenCL...............: Detection overrided. GPU mining support DISABLED
  scrypt...............: Disabled (needs OpenCL)
  ADL..................: SDK NOT found, GPU monitoring support DISABLED

  Avalon.ASICs.........: Disabled
  BFL.ASICs............: Enabled
  BitForce.FPGAs.......: Disabled
  Icarus.FPGAs.........: Enabled
  ModMiner.FPGAs.......: Disabled
  Ztex.FPGAs...........: Disabled

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -g -O2 -I/usr/include/libusb-1.0  
  LDFLAGS..............:  -lpthread
  LDADD................:  -lcurl   -ljansson -lpthread     -lm -lusb-1.0  

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local

Yes. It is exactly what it needs to be...

EDIT: about 2 more... Running now 36.8 before that it was 34.8 to 34.7...