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

[rkozola]

thanks for the tip.  that did it.

[Epoch]

Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2?  2.3.6 seems to be able to handle 5 singles fine.  But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.

Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128
Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95
Exception code: 0xc0000005
Fault offset: 0x000012fe
Faulting process id: 0xb24
Faulting application start time: 0x01cd419e02e067d8
Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe
Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll

I think I saw a thread elsewhere here that said if you increase the size of the command window in windows, it might solve this problem.

Yes, increasing the size of the command window (before starting cgminer) has helped people with similar symptoms.

(EDIT: I've seen you already got it working.)

To set a larger size as a default, hit start->run and type in cmd.exe<enter>; then click the black system icon in the top left corner of the command window that pops up. Choose 'properties'. The important thing here is the 'Layout' tab. Specifically Window Height. Set the Window height to 40 or 50. You can change the font as well to make it fit your monitor better. Click ok. You may then exit the command window. Any command window you open after this will come up with its new size.

There is a difference in how different versions of cgminer behave with Singles. 2.3.6 worked perfectly for me with up to 15 Singles. I since moved to 2.4.1 (and now 2.4.2) and have found that, using the same command line and command window layout size, 15 Singles crashes it. 2.4.1 are happy with 10 Singles, but not 15. 2.3.6 works fine with 15.

I don't know what broke between cgminer 2.3.6 and 2.4.1. It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

[deadlyasp]

Pardon any noob-ness this shows, but I only converted to cgminer from GUIMiner about a week ago, and just have a quick query;
With Intensity (that is in the OP) It warns of the futility of going over I:9, is this still the case or would I be able to go higher with my 6870HD? (Doubt this one is worth asking, but I also have a 6670HD miner as well till it gets upgraded in a few days)

[Krak]

With Intensity (that is in the OP) It warns of the futility of going over I:9, is this still the case or would I be able to go higher with my 6870HD?

I use 2 6870s at dynamic and 9 for intensity. I definitely wouldn't recommend putting it above 9 because it sends your rejects through the roof.

[deadlyasp]

With Intensity (that is in the OP) It warns of the futility of going over I:9, is this still the case or would I be able to go higher with my 6870HD?

I use 2 6870s at dynamic and 9 for intensity. I definitely wouldn't recommend putting it above 9 because it sends your rejects through the roof.

Thanks for the update! I thought maybe it had been answered before, but gods only know how many rejected I would waste while wading through almost 300 pages

Sent you a small donation for your trouble

[Krak]

Sent you a small donation for your trouble

Oh cool, thanks.

[jddebug]

Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2?  2.3.6 seems to be able to handle 5 singles fine.  But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.

Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128
Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95
Exception code: 0xc0000005
Fault offset: 0x000012fe
Faulting process id: 0xb24
Faulting application start time: 0x01cd419e02e067d8
Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe
Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll

I think I saw a thread elsewhere here that said if you increase the size of the command window in windows, it might solve this problem.

Yes, increasing the size of the command window (before starting cgminer) has helped people with similar symptoms.

(EDIT: I've seen you already got it working.)

To set a larger size as a default, hit start->run and type in cmd.exe<enter>; then click the black system icon in the top left corner of the command window that pops up. Choose 'properties'. The important thing here is the 'Layout' tab. Specifically Window Height. Set the Window height to 40 or 50. You can change the font as well to make it fit your monitor better. Click ok. You may then exit the command window. Any command window you open after this will come up with its new size.

There is a difference in how different versions of cgminer behave with Singles. 2.3.6 worked perfectly for me with up to 15 Singles. I since moved to 2.4.1 (and now 2.4.2) and have found that, using the same command line and command window layout size, 15 Singles crashes it. 2.4.1 are happy with 10 Singles, but not 15. 2.3.6 works fine with 15.

I don't know what broke between cgminer 2.3.6 and 2.4.1. It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

I hope that this can be fixed. I want to consolidate everything to one host computer. I'm wasting power running multiple rigs. (10 on one and 4 on another)

I'm wondering if the BFL Mini-Rig will be seen as one device or as many. If its many then that's going to be a problem.

[kano]

...
I hope that this can be fixed. I want to consolidate everything to one host computer. I'm wasting power running multiple rigs. (10 on one and 4 on another)
...

Run two (or more) cgminers on the one computer?
7 (or less) BFL's in each cgminer

Edit: N.B. for the API, each miner will need a different --api-port

[-ck]

This multi device display issue is because it gets corrupt at 14 devices with the old code. The curses display was never designed with people throwing so many devices at it and I never anticipated people would do it. Then I made it stop showing all the devices if there were over 8 - and people complained bitterly, so I made it scale to draw as many devices as you can fit. However pdcurses isnt as smart as ncurses which is used on linux so it just decides to crash instead of display them. SOOOOOOooooo what we're left with is yet another moronic scenario where the choice is either don't display devices and don't crash, or do something to your window before it runs to display them all and not crash, or it will crash. Solution? If you are using LOTS of devices - don't run cgminer with the display enabled by using -T and use a monitoring app to manage that many devices. The basic display was not designed with bucketloads of devices in mind.

Summary: Fuck you windows.

[bulanula]

Thanks for the update. Much appreciated ckolivas !

Anybody know the answer to my previous question, though :

They will only clock back up if the temperature drops enough again.

How long will this take ? I left them about 15 minutes after the heat stopped and the cold begun and they did not clock back automatically ( I had to do it manually ).

Thanks !

Anybody know how much this "unthrottling" takes once the source of heat is gone ?

It seems that the cards do clock back up after some time ( as ckolivas said ) but I still have not managed to determine after how long.

I left them overnight and they did clock back up !

Just for my reference and for others wondering about this. It seems they only clock back up slowly after the temperature reaches (target temp. - hysteresis ).

For example if the target temp is 70 then they will only start clocking back up when reaching 64.5.

[nedbert9]

Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2?  2.3.6 seems to be able to handle 5 singles fine.  But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.

Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128
Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95
Exception code: 0xc0000005
Fault offset: 0x000012fe
Faulting process id: 0xb24
Faulting application start time: 0x01cd419e02e067d8
Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe
Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll

I think I saw a thread elsewhere here that said if you increase the size of the command window in windows, it might solve this problem.

Yes, increasing the size of the command window (before starting cgminer) has helped people with similar symptoms.

(EDIT: I've seen you already got it working.)

To set a larger size as a default, hit start->run and type in cmd.exe<enter>; then click the black system icon in the top left corner of the command window that pops up. Choose 'properties'. The important thing here is the 'Layout' tab. Specifically Window Height. Set the Window height to 40 or 50. You can change the font as well to make it fit your monitor better. Click ok. You may then exit the command window. Any command window you open after this will come up with its new size.

There is a difference in how different versions of cgminer behave with Singles. 2.3.6 worked perfectly for me with up to 15 Singles. I since moved to 2.4.1 (and now 2.4.2) and have found that, using the same command line and command window layout size, 15 Singles crashes it. 2.4.1 are happy with 10 Singles, but not 15. 2.3.6 works fine with 15.

I don't know what broke between cgminer 2.3.6 and 2.4.1. It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

Being able to service or temporarily power down units in a non GPU multi hasher setup without having cgminer exit is a good thing.

[Luke-Jr]

It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in?

[-ck]

Repackaged the source as 2.4.2-1 because 2 of the READMEs were missing. Binary packages are unchanged.

[Epoch]

This multi device display issue is because it gets corrupt at 14 devices with the old code. The curses display was never designed with people throwing so many devices at it and I never anticipated people would do it. Then I made it stop showing all the devices if there were over 8 - and people complained bitterly, so I made it scale to draw as many devices as you can fit. However pdcurses isnt as smart as ncurses which is used on linux so it just decides to crash instead of display them. SOOOOOOooooo what we're left with is yet another moronic scenario where the choice is either don't display devices and don't crash, or do something to your window before it runs to display them all and not crash, or it will crash. Solution? If you are using LOTS of devices - don't run cgminer with the display enabled by using -T and use a monitoring app to manage that many devices. The basic display was not designed with bucketloads of devices in mind.

Summary: Fuck you windows.

cgminer 2.6.2's display worked very well with 15 devices under Windows. 2.4.1 does not. I don't know if this change was intentional or an accidental side-effect, but it certainly is frustrating to find that something which *used* to work before is suddenly broken without notice.

I have a PC with a 'bucketload' of devices. Under Windows I can conveniently remotely connect to it via Remote Desktop, or VNC, or Live Mesh, or TeamViewer ... I don't use the API because I've no need for it. If cgminer's display remains broken for 'bucketloads' of devices, at least I can run multiple instances. Inefficient and inelegant, but we're not in an aesthetics contest here.

So in the 'grand scheme' of things, it doesn't really matter.

[-ck]

cgminer 2.6.2's display worked very well with 15 devices under Windows. 2.4.1 does not. I don't know if this change was intentional or an accidental side-effect, but it certainly is frustrating to find that something which *used* to work before is suddenly broken without notice.

I have a PC with a 'bucketload' of devices. Under Windows I can conveniently remotely connect to it via Remote Desktop, or VNC, or Live Mesh, or TeamViewer ... I don't use the API because I've no need for it. If cgminer's display remains broken for 'bucketloads' of devices, at least I can run multiple instances. Inefficient and inelegant, but we're not in an aesthetics contest here.

So in the 'grand scheme' of things, it doesn't really matter.

I don't disagree, but the problem is it does different things on different operating systems and different shells. Working with curses is painful on a scale that almost puts it on par with working with Luke-jr as it never does something predictable or logical. I fixed stuff after that old cgminer and yeah it broke other stuff. It's an endless tirade of one piece of shit after another and I'm sick of fighting with it, like Luke-jr.

[bulanula]

cgminer 2.6.2's display worked very well with 15 devices under Windows. 2.4.1 does not. I don't know if this change was intentional or an accidental side-effect, but it certainly is frustrating to find that something which *used* to work before is suddenly broken without notice.

I have a PC with a 'bucketload' of devices. Under Windows I can conveniently remotely connect to it via Remote Desktop, or VNC, or Live Mesh, or TeamViewer ... I don't use the API because I've no need for it. If cgminer's display remains broken for 'bucketloads' of devices, at least I can run multiple instances. Inefficient and inelegant, but we're not in an aesthetics contest here.

So in the 'grand scheme' of things, it doesn't really matter.

I don't disagree, but the problem is it does different things on different operating systems and different shells. Working with curses is painful on a scale that almost puts it on par with working with Luke-jr as it never does something predictable or logical. I fixed stuff after that old cgminer and yeah it broke other stuff. It's an endless tirade of one piece of shit after another and I'm sick of fighting with it, like Luke-jr.

Not only a coding GOD but a good sense of humour too !

2.4.2 works very well for me in LINUX.

Windows <- there's your problem. Are miners still using Windows ? LOL.

[Epoch]

It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in?

Luke, one benefit of exiting is that cgminer can then be executed in a 'forever loop' script such as this, which is useful for automated and unattended error recovery (in lieu of something like akbash):

:loop
cgminer <params>
waitfor xx seconds
goto loop

Because cgminer is re-run automatically by the script, it re-enables all the Singles. This was the behavior with 2.3.6, and worked well.

With 2.4.1 and 2.4.2, if any Singles goes offline for whatever reason (temporary power failure, USB cable unplugged, it crashes, ...) cgminer marks it as OFF and it can never be re-enabled unless you quit cgminer and re-run it. This makes it less suitable for this type of automated error recovery.

Now, if cgminer could be altered to re-enable any devices when they are plugged back in, that would be a significant improvement.

[Luke-Jr]

It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in?

Luke, one benefit of exiting is that cgminer can then be executed in a 'forever loop' script such as this, which is useful for automated and unattended error recovery (in lieu of something like akbash):

:loop
cgminer <params>
waitfor xx seconds
goto loop

Because cgminer is re-run automatically by the scrpt, it re-enables all the Singles. This was the behavior with 2.3.6, and worked well.

If a Single is unplugged, it won't be detected when the new cgminer starts... so you get the same thing, minus the ability to enable it later. Is there something else going on here?

[Epoch]

cgminer 2.6.2's display worked very well with 15 devices under Windows. 2.4.1 does not. I don't know if this change was intentional or an accidental side-effect, but it certainly is frustrating to find that something which *used* to work before is suddenly broken without notice.

I have a PC with a 'bucketload' of devices. Under Windows I can conveniently remotely connect to it via Remote Desktop, or VNC, or Live Mesh, or TeamViewer ... I don't use the API because I've no need for it. If cgminer's display remains broken for 'bucketloads' of devices, at least I can run multiple instances. Inefficient and inelegant, but we're not in an aesthetics contest here.

So in the 'grand scheme' of things, it doesn't really matter.

I don't disagree, but the problem is it does different things on different operating systems and different shells. Working with curses is painful on a scale that almost puts it on par with working with Luke-jr as it never does something predictable or logical. I fixed stuff after that old cgminer and yeah it broke other stuff. It's an endless tirade of one piece of shit after another and I'm sick of fighting with it, like Luke-jr.

Agreed. Having to support multiple OS's is a pain. And there will be casualties. I can accept that.

[-ck]

Agreed. Having to support multiple OS's is a pain. And there will be casualties. I can accept that.

A most enlightened response. Thanks. All I can do is try my best within reasonable effort.