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

[mdude77]

3.6.1 isn't working for me.  (win7x64 - 33 usb block erupters).   I let it run for a while, then it stopped mining, repeatedly saying something like USB write error_no_mem.

I tried to copy/paste the error but lost it.  I can get it again if need be.

M

[1714932458]

1714932458

[1714932458]

1714932458

[jedimstr]

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

[-ck]

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

Sorry but code designed just for altcoin mining takes absolutely last priority.

[jedimstr]

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

Sorry but code designed just for altcoin mining takes absolutely last priority.

Fair enough... better than a flat out "no" unless that's what this is.

That said, failover switchback timing doesn't just have to be an "Altcoin" issue.  That was just a symptom.  Making it defeatable so that it can use the previous behavior of switching back to primary pool once that pool is Alive would work.  Either way, just putting it out there.

[-ck]

i'm running 24 AMU's on a raspberry pi. cpu load is down to 23-25% now with 3.6.1. had about 60% cpu load on 3.5.1 :-D

Well that's nice

3.6.1 isn't working for me.  (win7x64 - 33 usb block erupters).   I let it run for a while, then it stopped mining, repeatedly saying something like USB write error_no_mem.

I tried to copy/paste the error but lost it.  I can get it again if need be.

And FFS LOL windows. Always with the new and exciting modes of failure. This suggests a memory leak within the windows specific part of the libusb code. Anyway now that timeouts are managed differently it means we can try libusbx instead of libusb, so I'm putting up some testing binaries that use it. Please try them, but I'm not holding much to hope.

http://ck.kolivas.org/apps/cgminer/temp/

[ksenter]

In case it helps you.  I just got a LOT of this on the newest version after running for a few hours:

[2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: Error: Request temp invalid/timed out (0:-11)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM

[mdude77]

In case it helps you.  I just got a LOT of this on the newest version after running for a few hours:

[2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)

That's the one I got too.

M

[-ck]

In case it helps you.  I just got a LOT of this on the newest version after running for a few hours:

[2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)

That's the one I got too.

M

Did either of you try the experimental binaries I listed above?

This suggests a memory leak within the windows specific part of the libusb code. Anyway now that timeouts are managed differently it means we can try libusbx instead of libusb, so I'm putting up some testing binaries that use it. Please try them, but I'm not holding much to hope.

http://ck.kolivas.org/apps/cgminer/temp/

[ksenter]

Trying it now.  I'll let you know if it crashes.  Unless I'm asleep by then.

Edit: BTW, I just downloaded cgminer-nogpu.exe and libusb-1.0.dll and dropped them in the 3.6.1 folder.  Is that good enough, or do I need all the files?

[ksenter]

Btw, it ran all night.  So far so good.

[btc6000]

Hi,

I'm currently mining with a BFL Jalapeno and CGMiner, and am also waiting for some BlueFury USBs to arrive. Will I be able to run both sets of hardware on the same box with one instance of CGMiner?

Cheers

[wolfskill]

I updated those files from last night and my BFL 30gh miner has been running without the error.


WolfSkill

[SpaceCadet]

I had a different issue with 3.6.1 that I haven't seen before.  I'm running win7-x64 with 9 BEs (no GPU) and when I got up this morning, cgminer was locked up (no errors showing in the window, and I forgot to note the run duration before windows reported the app had crashed).  I went back to 3.5.1 for now, and will try the test code when I get a chance. 

I'm also running a cpu miner in one window for SRC, and cgminer 3.3.1 to drive the GPU on a script coin (it ignores the BEs), so there may be some conflicts there (even though 3.5.1 runs without issue - well, the timeout errors, but those done seem to affect performance too much).  Also, another box running 3 BEs on 3.6.1 (win7-32) did not have the same issue.

Just an info report...

[ineedit]

Hi Guys,

I am re-compiling on Windows to get ready for some Bitfury's that should appear soon but I have run into problems with make. I can successfully compile and run cgminer versions up to 3.3.3 but after that all versions to 3.5.1 consistently fail with

"ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."

There are a number of fixes around the Interweb but I would rather use the same fix that you guys must be using to build the exe's. I am using the same versions of mingw, gtk, etc as per the windows build doc and follow the guide without problems for versions to 3.3.3, all builds are clean onto a fresh Win 7 VM.




As an aside I am also noticing differences in the dll's included in the exe distro against those required from the windows build doc, not a biggie but something that needs to be added to a tidy up list at some point.

[os2sam]

I am re-compiling on Windows to get ready for some Bitfury's

The precompiled Windoze binaries don't work?

[ineedit]

I am re-compiling on Windows to get ready for some Bitfury's

The precompiled Windoze binaries don't work?

The pre-compiled exe's work fine, but it is open source and I like to compile my own for a number of various reasons.

[os2sam]

I am re-compiling on Windows to get ready for some Bitfury's

The precompiled Windoze binaries don't work?

The pre-compiled exe's work fine, but it is open source and I like to compile my own for a number of various reasons.

OK, that's cool.

I'm guessing you already looked in the windows-build file?

I'll just shut up now.
Good Luck,
Sam

[Aurum]

3.6.1 isn't working for me.  (win7x64 - 33 usb block erupters).   I let it run for a while, then it stopped mining, repeatedly saying something like USB write error_no_mem.

I tried to copy/paste the error but lost it.  I can get it again if need be.

And FFS LOL windows. Always with the new and exciting modes of failure. This suggests a memory leak within the windows specific part of the libusb code. Anyway now that timeouts are managed differently it means we can try libusbx instead of libusb, so I'm putting up some testing binaries that use it. Please try them, but I'm not holding much to hope.

http://ck.kolivas.org/apps/cgminer/temp/

I replaced cgminer-nogpu.exe with the one in the above temp folder. I get ever increasing lines of:
AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT

[techman05]

Should 3.6.1 be working? I've had it on for maybe 1 Minute with no errors showing on windows 7.

I'm using block eroupters if that makes any difference.

[ineedit]

I am re-compiling on Windows to get ready for some Bitfury's

The precompiled Windoze binaries don't work?

The pre-compiled exe's work fine, but it is open source and I like to compile my own for a number of various reasons.

OK, that's cool.

I'm guessing you already looked in the windows-build file?

I'll just shut up now.
Good Luck,
Sam

NP Sam 

The problem been around a while and I have not found the answer in this thread or any of the build docs, etc. I was trying to stay out of the dev's way until I really started to need it as they have been very busy doing all this fantastic work on ASIC support.