Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Software change is VERY unlikely since no one has changed the BFL code for a month.
Not impossible of course, but certainly not a likely suspect.
Right, none of the fpga code has been touched in a while. On the other hand, cgminer keeps devices busier than ever so if they're borderline, it will push them over.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
After my recent upgrade to 2.9 I started getting a lot of this:

Code:
 [2012-11-05 18:43:46] BFL0: Garbled response probably throttling, clearing buffer
 [2012-11-05 18:43:49] BFL0: Comms error

It happens quite often, every 10-20 lines or so and I'm watching the BFL unit mine and there are no blinky lights to indicate throttling...

Also, every once in a while, I'll come back to my computer to find that cgminer isn't running. I don't see any errors, it starts back up just fine, it just mysteriously stops running...

Is there some kind of debug flag I can set to figure out what's causing these two problems and if they're related?
Best bet would be a bad USB cable.

A USB cable that worked fine for several months then magically broke at the exact moment that I upgraded cgminer?
Well - it's like this.
You want to HOPE it's a bad USB cable problem that often people have with BFLs

On the other hand it could be something worse ...

To add doom and gloom to the discussion, things often fail when they change - specifically turning them off and on or letting them cool down and heat up (if no power cycle)

Software change is VERY unlikely since no one has changed the BFL code for a month.
Not impossible of course, but certainly not a likely suspect.
sr. member
Activity: 446
Merit: 250
After my recent upgrade to 2.9 I started getting a lot of this:

Code:
 [2012-11-05 18:43:46] BFL0: Garbled response probably throttling, clearing buffer
 [2012-11-05 18:43:49] BFL0: Comms error

It happens quite often, every 10-20 lines or so and I'm watching the BFL unit mine and there are no blinky lights to indicate throttling...

Also, every once in a while, I'll come back to my computer to find that cgminer isn't running. I don't see any errors, it starts back up just fine, it just mysteriously stops running...

Is there some kind of debug flag I can set to figure out what's causing these two problems and if they're related?
Best bet would be a bad USB cable.

A USB cable that worked fine for several months then magically broke at the exact moment that I upgraded cgminer?

Give it a try at least. kano is telling you what the likely issue it. The message you are seeing I have had to deal with off and on for months. Its either been usb issues or bad cooling due to thermal grease/fan problems.
hero member
Activity: 742
Merit: 500
After my recent upgrade to 2.9 I started getting a lot of this:

Code:
 [2012-11-05 18:43:46] BFL0: Garbled response probably throttling, clearing buffer
 [2012-11-05 18:43:49] BFL0: Comms error

It happens quite often, every 10-20 lines or so and I'm watching the BFL unit mine and there are no blinky lights to indicate throttling...

Also, every once in a while, I'll come back to my computer to find that cgminer isn't running. I don't see any errors, it starts back up just fine, it just mysteriously stops running...

Is there some kind of debug flag I can set to figure out what's causing these two problems and if they're related?
Best bet would be a bad USB cable.

A USB cable that worked fine for several months then magically broke at the exact moment that I upgraded cgminer?
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
After my recent upgrade to 2.9 I started getting a lot of this:

Code:
 [2012-11-05 18:43:46] BFL0: Garbled response probably throttling, clearing buffer
 [2012-11-05 18:43:49] BFL0: Comms error

It happens quite often, every 10-20 lines or so and I'm watching the BFL unit mine and there are no blinky lights to indicate throttling...

Also, every once in a while, I'll come back to my computer to find that cgminer isn't running. I don't see any errors, it starts back up just fine, it just mysteriously stops running...

Is there some kind of debug flag I can set to figure out what's causing these two problems and if they're related?
Best bet would be a bad USB cable.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Switching from a stratum pool to a gbt pool is a little broken it seems on 2.9.0... No need to report this bug  Lips sealed

EDIT: Hotfix quick update to 2.9.1 getting rid of this bug.
hero member
Activity: 742
Merit: 500
After my recent upgrade to 2.9 I started getting a lot of this:

Code:
 [2012-11-05 18:43:46] BFL0: Garbled response probably throttling, clearing buffer
 [2012-11-05 18:43:49] BFL0: Comms error

It happens quite often, every 10-20 lines or so and I'm watching the BFL unit mine and there are no blinky lights to indicate throttling...

Also, every once in a while, I'll come back to my computer to find that cgminer isn't running. I don't see any errors, it starts back up just fine, it just mysteriously stops running...

Is there some kind of debug flag I can set to figure out what's causing these two problems and if they're related?
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
cut/paste ...

2.9.0 2.9.1
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.9.0a cgminer-2.9.1a
https://github.com/kanoi/cgminer/downloads
(it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my '2xGPU' or 'BFL+ICA' - yes I've rearranged them (40 minutes so far) GPU's on solo and BFL+ICA (1.6GH/s) on EMC with GBT (MMQ is doing other testing)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make
full member
Activity: 231
Merit: 100
OK I looked.. used the search function and even google but can't find an answer to this question...  I posted on a new thread and was directed to this one.  My question is why will cgminer running on ubuntu 12.04 64 bit will not submit shares (in a timely manner) for scrypt mining.  Hashrate in the cgminer console is ~310Kh/s but share submits are reporting 2Kh/s

Here is my post https://bitcointalksearch.org/topic/cgminer-will-not-submit-on-linux-120773

When I posted it I was running 2.7.5 and now I am running 2.8.7 and having the same problem.  Any ideas?
Any help is much appreciated.

Naelr
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version -> 2.9.1

Main thing in this new point release is support for the pooled GBT mining protocol. This is once again a large chunk of new code and carries with it the attendant risks of new instability so I'm leaving 2.8.7 up for download. The GBT implementation is my own from scratch, not using an existing implementation. luke-jr helped debug a few things to do with how the protocol worked since no one else seems to understand it.

Note that I have serious reservations about recommending GBT as significantly advantageous for the miner (in terms of performance) unlike stratum. See my post here as to why:
https://bitcointalksearch.org/topic/m.1317574



Human readable changelog

Support for GBT mining protocol.
Minor stratum tweaks, bugfixes and improvements.


Full changelog

Version 2.9.1 - November 6, 2012

- Reset work flags to prevent GBT shares from being submitted as stratum ones
after switching.


Version 2.9.0 - November 6, 2012

- Add endian swap defines for where missing.
- Only retarget stratum shares to new pool diff if diff has dropped.
- Remove resetting of probed variable when detecting GBT.
- Count lost stratum share submits and increase message priority to warning.
- Only retrieve a new block template for GBT pools that are the current pool.
- Show which pool untracked share messages have come from.
- Add management for dead GBT pools.
- Count lost shares with stratum as submit stale lost.
- Discard record of stratum shares sent and report lost shares on disconnection
since they will never be reported back.
- Swab, don't just swap the bytes in the GBT target.
- Change status window message for GBT connected pools versus LP.
- Generate a gbt work item from longpoll when required to set new block and
message appropriately.
- Use existing pool submit_old bool from gbt data.
- Retrieve a new block template if more than 30 seconds has elapsed since the
last one to keep the data current and test the pool is still alive.
- Update GBT longpollid every time we request a new longpoll.
- Manage appropriate response codes for share submission with GBT.
- Allow the longpoll thread to start with GBT and only set the longpollid once.
- Correct last few components of GBT block generation courtesy of Luke-jr.
- Use correct length for offsetting extra nonce and remaining data.
- Flip all 80 bytes in the flip function which was wrongly named flip256 for its
purpose.
- Calculate midstate for gbt work and remove now unused variable.
- Use a standard function for flipping bytes.
- Insert the extra nonce and remaining data in the correct position in the
coinbase.
- Remove txn size debugging and enlarge gbt block string to prevent overflow.
- Remove varint display debugging.
- Build varint correctly for share submission and sleep 5 seconds before
retrying submit.
- Make gbt_coinbase large enough for submissions, swap bytes correctly to make a
header from GBT and encode the number of transactions in share submission.
- Store the fixed size entries as static variables in GBT in binary form,
byteswapping as is required.
- 32 bit hex encoded variables should be in LE with GBT.
- Target and prevblockhash need to be reversed from GBT variables.
- Construct block for submission when using GBT.
- Use same string for debug as for submission and make string larger to cope
with future GBT messages.
- Skip trying to decipher LP url if we have GBT support.
- Store all the transaction hashes in pool->txn_hashes instead of separating
txn0 and correct generation of merkle root, fixing memory overwrites.
- Hook into various places to generate GBT work where appropriate.
- Create extra work fields when generating GBT work.
- Generate header from correct hashing generation of the merkle root for GBT.
- Generate the merkle root for gbt work generation.
- Create a store of the transactions with GBT in the minimum size form required
to generate work items with a varied coinbase.
- Create a function that generates a GBT coinbase from the existing pool
variables.
- Extract and store the various variables GBT uses when decoding gbt work.
- Check for invalid json result in work_decode.
- Decode work in separate functions for getwork vs gbt.
- Check for the coinbase/append mutable in GBT support to decide whether to use
it or not.
- Add a gbt mutex within the pool struct for protecting the gbt values.
- Convert work decode function to prepare for decoding block templates.
- Check for GBT support on first probing the pool and convert to using the GBT
request as the rpc request for that pool.
- Make the rpc request used with getwork a pool variable to allow it to be
converted to/from gbt requests.
- Changes to build prototypes to support building on FreeBSD 9.1-RC2 amd64
- Free old stratum_work data before replacing it
- There is no need for addrinfo any more.
- server and client sockaddr_in are no longer used in struct pool.
- Merge pull request #322 from luke-jr/bugfix_stratum_tmpwork
- Set sshare id and swork_id within the sshare mutex to avoid multiple share
submits with the same id.
- Initialize temporary stratum work
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
There are other complexities related to this when share difficulty is changed by the pool (that I think is bad in Stratum) but the basics are as I said above.

I'm thinking about the solution and I think that I found it. When the protocol change from current "drop all shares above the target since receiving this new difficulty" to "drop all shares abouve the target for all new jobs", will it solve our problem?

a) When pool want to force user to new difficulty, it will send set_difficutly and job with clean_jobs=True like now
b) When pool want to update difficulty lazily, he will just send set_difficulty, no new job is required. In would be the most common scenario and there's also no way how to "lose" shares.

It just need some minor change in cgminer. It will basically bound difficulty with the job as you wanted and leave the difficulty as separate message as I wanted. So it looks like win-win solution.

ckolivas, Eleuthria - hm?
Hmm... To work with the current stratum limitation, cgminer checks shares against the current stratum pool difficulty before trying to submit them. I can remove this code and then difficulty is tied to the work at the time it was generated up to how the pool does things entirely. I'm thinking I will check difficulty against the new difficulty only if difficulty has dropped and then leave it up to the pool to cope. While this may introduce more rejects with diff increases, at least there is no chance of work lost, and will work with your idea.

Tying difficulty with work entirely would still be much better.
sr. member
Activity: 383
Merit: 250
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?

did you READ THE README

This would be one of the quietest threads on the forum if more people read the included README document/file.
hero member
Activity: 988
Merit: 1000
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?

did you READ THE README
full member
Activity: 373
Merit: 100
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?

http://goo.gl/2wnwi

I've read it. It's all saying about cgminer.exe used with many malware, but not libpdcurses.dll.

Search the thread for libpdcurses.dll - it's been covered ad nauseam...
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?

http://goo.gl/2wnwi

I've read it. It's all saying about cgminer.exe used with many malware, but not libpdcurses.dll.
legendary
Activity: 952
Merit: 1000
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?

http://goo.gl/2wnwi
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
ckolivas, currently, AVG 2012 Free Edition Antivirus saying that file:
libpdcurses.dll
contains a virus: PSW.KeyLogger.AVU http://www.avgthreatlabs.com/webthreats/info/psw.keylogger.avu/

Weird, isn't?
legendary
Activity: 1386
Merit: 1097
There are other complexities related to this when share difficulty is changed by the pool (that I think is bad in Stratum) but the basics are as I said above.

I'm thinking about the solution and I think that I found it. When the protocol change from current "drop all shares above the target since receiving this new difficulty" to "drop all shares abouve the target for all new jobs", will it solve our problem?

a) When pool want to force user to new difficulty, it will send set_difficutly and job with clean_jobs=True like now
b) When pool want to update difficulty lazily, he will just send set_difficulty, no new job is required. In would be the most common scenario and there's also no way how to "lose" shares.

It just need some minor change in cgminer. It will basically bound difficulty with the job as you wanted and leave the difficulty as separate message as I wanted. So it looks like win-win solution.

ckolivas, Eleuthria - hm?
hero member
Activity: 780
Merit: 510
Bitcoin - helping to end bankster enslavement.

The pool tells the miner what difficulty the shares need to be.
cgminer checks the shares difficulty and only submits shares that are above the difficulty
(which actually means below the target value Smiley)
The pool checks that the difficulty is above what it told the miner.
If it is above, it is accepted, if it is below it is rejected.

There are other complexities related to this when share difficulty is changed by the pool (that I think is bad in Stratum) but the basics are as I said above.

Thanks!  Nice and simple explanation.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
(and no shares would get paid double).

Huh? What?
If a pool requires miner 1 to submit minimum difficulty 2 shares, but miner 2 can submit minimum difficulty 1 shares, then each share submitted by miner 1 will be paid twice as much as each share submitted by miner 2.  If all miners are required to submit minimum difficulty 2 shares, then no miner's shares are worth more than any other miner's shares.

I get the first part but how can a miner submit "No Shares" and get paid?
LOL, nice, you are joking right?  Just in case you're not, let me rephrase it this way: "none of the submitted shares get paid double."  This is because they would all get paid equally since there would be no variation from the minimum difficulty for different shares to be compared against.  Presumably you understood this from Krak's post and I am wasting my time.

OK it appears that I understood the concept long before, but assumed it was more complicated than I thought.  However what has left me kind of confused is the fact that pool can or can't determining the difficulty of shares.  If they can then then submit the number of shares found in the db, if they can't then how the hell can they require all miners to submit a higher difficulty when the miner could just send the a diff of 1 and they would never know.

I think you guys are making it more complex than it needs to be so I will just assume that pools can detect the diff of shares sent from miners under certain circumstances and I just don't know what those circumstances are.  And leave it at that.
The pool tells the miner what difficulty the shares need to be.
cgminer checks the shares difficulty and only submits shares that are above the difficulty
(which actually means below the target value Smiley)
The pool checks that the difficulty is above what it told the miner.
If it is above, it is accepted, if it is below it is rejected.

There are other complexities related to this when share difficulty is changed by the pool (that I think is bad in Stratum) but the basics are as I said above.
Jump to: