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

[Xian01]

What do other people think about having multiple forum threads?

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.

[ndr76]

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.

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

[pengoau]

Thanks (that worked), do you know what worksize i should be using for my gpus? I've been using 128 just wondering if its worthwhile using 256? Guess I can try and then find out, but if anyone would know for sure you would? thanks again

Also if I use --temp-hysteresis 6 does that mean the fan will kick in at 6 degrees earlier?

cgminer is pretty smart.  I wouldn't set the worksize, let cgminer pick it.

M

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

[ndr76]

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.

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.

[vapourminer]

What do other people think about having multiple forum threads?

keep it simple. one thread.

[os2sam]

And I got back missing 150MH by seting cards to 10 and 12. So I'm on full speed now. I know it is not the internet since I have tested the cards on another computer before installing it and they worked... I still think it is a bug...

EDIT: So that much about getting slower over 8...

Has your WU: increased as well?

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...

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

[os2sam]

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?

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)

[BitMinerN8]

What do other people think about having multiple forum threads?

keep it simple. one thread.

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. 

[-ck]

What do other people think about having multiple forum threads?

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.

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.

[Trongersoll]

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?

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)

Thank you good sir.

[bb000]

Trying version 3.2.1 for a new Asicminer USB with Windows 7 x64, cgminer crashes with segmentation fault when I enable debug output. With debug output turned off it runs for about a minute, but keeps failing with AMU0: Comms error (rerr=-9 amt=0)
...

Version 3.1.1 still remains the most stable release for your hardware, but bear in mind you will need to use zadig to re-associate the device with the ftdi driver instead of WinUSB when you go back to it. 3.2.0 did not work at all for AMU devices so if you're trying the new code, use 3.2.1. 3.2.1a is just a binary built for older versions of ubuntu and no different to 3.2.1.

Compiling it yourself will not make it more stable as my builds should be optimal - the only advantage to building yourself is you can build a stripped down version containing support only for the hardware you want to use, and assuming you're on windows, compiling it is FAR from trivial.

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.

[-ck]

Trying version 3.2.1 for a new Asicminer USB with Windows 7 x64, cgminer crashes with segmentation fault when I enable debug output. With debug output turned off it runs for about a minute, but keeps failing with AMU0: Comms error (rerr=-9 amt=0)
...

Version 3.1.1 still remains the most stable release for your hardware, but bear in mind you will need to use zadig to re-associate the device with the ftdi driver instead of WinUSB when you go back to it. 3.2.0 did not work at all for AMU devices so if you're trying the new code, use 3.2.1. 3.2.1a is just a binary built for older versions of ubuntu and no different to 3.2.1.

Compiling it yourself will not make it more stable as my builds should be optimal - the only advantage to building yourself is you can build a stripped down version containing support only for the hardware you want to use, and assuming you're on windows, compiling it is FAR from trivial.

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.

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)

[CanaryInTheMine]

i used 3.2.1 but didn't recognize the usb asicminers. Perhaps because i use a usb 3.0 hub ?

Yeah that was going to be the next thing to sort out, USB 3.0

But there is still another AMU problem I'm looking at first - 'SICK' on the RPi that I get also - looking into it ...
I'd not tried the RPi due to the fact that for me, linux crashes when I plug my powered hub with the AMU into my RPi
Though I found last night I can plug in the hub first then the AMU and it doesn't.
(Probably the hubs fault, but it works OK now if I order it the right way, and 3.1.1a works also ... so I can reproduce the problem ...)

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.

[GuiltySpark343]

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.

[-ck]

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

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

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

[GuiltySpark343]

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

[Trongersoll]

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

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

I'm seeing about 60% on each of two cores. But the cpu is only runniing at 1Ghz so i don't expect much from it. running 4 erupters and a Radian 6570 GPU.

[os2sam]

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

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

I'm seeing about 60% on each of two cores. But the cpu is only runniing at 1Ghz so i don't expect much from it. running 4 erupters and a Radian 6570 GPU.

1Ghz Dual Core? never heard of such a thing.

[Trongersoll]

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

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

I'm seeing about 60% on each of two cores. But the cpu is only runniing at 1Ghz so i don't expect much from it. running 4 erupters and a Radian 6570 GPU.

1Ghz Dual Core? never heard of such a thing.

I only got 10Mh/s out of the on board GPU so i put a small video card in the PCIe slot. getting a whopping 85Mh/s on the video card now. heh.

http://www.amazon.com/gp/product/B007ZT1FAI/ref=oh_details_o05_s01_i00?ie=UTF8&psc=1

[CommanderVenus]

cgminer 3.2.1 is working wonderfully with my block erupter! I notice that my hardware failure is actually much lower with this version. This is a screenshot of cgminer with an uptime of about 1 day 2 hours 35 minutes.
https://www.dropbox.com/s/h0cen93laqkyh3e/cgminer3.2.1.png