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

[lano1106]

Hi,

I'm having this message continually since I upgraded to 3.3.3

 [2013-08-12 23:49:01] Rejected 9f13b83d Diff 1/1 AMU 3 pool 0 (Extranonce2_size violated)

will roll back to 3.2 to see if it fix the problem.

EDIT: The problem seems to only happen with bitminter. I have switch to slush pool and all is fine.
EDIT2: Yep. The incompatibility has been introduced by 3.3.3. I have come back to 3.3.2 and it started to work again.

[-ck]

Hi,

I'm having this message continually since I upgraded to 3.3.3

 [2013-08-12 23:49:01] Rejected 9f13b83d Diff 1/1 AMU 3 pool 0 (Extranonce2_size violated)

will roll back to 3.2 to see if it fix the problem.

EDIT: The problem seems to only happen with bitminter. I have switch to slush pool and all is fine.
EDIT2: Yep. The incompatibility has been introduced by 3.3.3. I have come back to 3.3.2 and it started to work again.

Ah yes I see what's wrong there. I've committed a fix to git for this.

[-ck]

First problem found in  --avalon-freq <arg> Set frequency range for avalon-auto, single value or range

with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?

There's a regression where auto doesn't go quite as fast as it used to, I'm working on a fix now.

[kano]

FYI I put the 3.3.3a binaries and sources etc into my cgminer-binaries git as usual ... but about 2 hours ago.
Yes I'm skimping on the post this time

[Krak]

FYI I put the 3.3.3a binaries and sources etc into my cgminer-binaries git as usual ... but about 2 hours ago.
Yes I'm skimping on the post this time

Damn, no Raspbian binary this time.

[-ck]

First problem found in  --avalon-freq <arg> Set frequency range for avalon-auto, single value or range

with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?

There's a regression where auto doesn't go quite as fast as it used to, I'm working on a fix now.

I've uploaded a new firmware. Should fix this.

http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/

[kano]

FYI I put the 3.3.3a binaries and sources etc into my cgminer-binaries git as usual ... but about 2 hours ago.
Yes I'm skimping on the post this time

Damn, no Raspbian binary this time.

I've a 2nd RPi in transit (that I'll leave running Raspbian)
Once I get that I'll build both each time (and a 3.3.3a Raspbian) - just annoying to shut it down, switch, reboot, build, shutdown, switch, reboot, mine ...
... since I know the other one is due here soon.

[bitpop]

hope ck releases a single firmware and maybe updates jalapeno to 1.2.6

https://blockchain.info/tx/52485d6a05fdaa54d6c6bd73906a840590503bfb078cb1bacc77c6e0f76df5bb

[didjaydisteele]

There are difficulties changes be mining while the old value was only without found number of shares -, but isn't what number this really the shares than other calculated to this.
More worse than without found based on it, but still, if the mining was after the number not really the matter of what they say.

[kano]

There are difficulties changes be mining while the old value was only without found number of shares -, but isn't what number this really the shares than other calculated to this.
More worse than without found based on it, but still, if the mining was after the number not really the matter of what they say.

Gotta love google translate

Let see if I understood the question ....

A 1diff share is fixed, independent of the network difficulty.
You should find on average 1x1diff share per 2^32 hashes done - average, after finding a few million of them

The network difficulty defines how many of these you need to find before you should, on average, find a block
Of course you have to find thousands of blocks to expect to be close to the average.

[didjaydisteele]

Got it! Thanks Kano. 

[Roy Badami]

The network difficulty defines how many of these you need to find before you should, on average, find a block

Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty?  (I find it's not the same - but I guess that may be just down to what the pools report?)

roy

[kano]

The network difficulty defines how many of these you need to find before you should, on average, find a block

Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty?  (I find it's not the same - but I guess that may be just down to what the pools report?)

roy

It's there in the block header you are hashing.
Block header being hashed is: Type, Prev, Merkl, Time, Bits, Nonce.
Diff = f(Bits)

[-ck]

New version: 3.3.4, 14th August 2013

Hotfix release.


Human readable changelog:

- Fixed the breakage when mining on bitminter.
- Fixed the performance regression on avalons
- Added extra % counts to devs fields in API


Full changelog:

- API/miner.php add some % fields
- Nonce2 stratum submission is not working with nonce2 lengths >4, revert the
buggy __bin2hex function and use bin2hex.
- The write thread in avalon is only ever actually woken up by timeout so remove
the write semaphore and use a simple sleep poll.
- Fix warning.
- Interrupting reads on the avalon to start writes loses data so remove the
cgsem_post in the read code.
- Add room for the null byte at the end of the nonce2 string on stratum share
submission and zero the allocated ram.

[lano1106]

Already running 3.3.4 on bitminter flawlessly.

thank you very much for your amazing job!

[bzh]

want to move past 3.1.1 on my pi with BE's but i really dislike arch. does 3.3.4 still have usb issues with rasbian wheezy? Is there a custom libusb that works with it yet?

Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.

[-ck]

want to move past 3.1.1 on my pi with BE's but i really dislike arch. does 3.3.4 still have usb issues with rasbian wheezy? Is there a custom libusb that works with it yet?

Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.

As we discovered, it's not cgminer that has usb issues, it's the libusb included with the distributions, so - yes you will need a custom libusb installed if you wish to use raspbian and not move to arch (which has the new libusb). You'll have to compile it yourself. Maybe some generous soul here will create a custom libusb package for raspbian?

[kano]

want to move past 3.1.1 on my pi with BE's but i really dislike arch. does 3.3.4 still have usb issues with rasbian wheezy? Is there a custom libusb that works with it yet?

Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.

How to compile with the known working libusb is documented step by step in README (I added it in 3.3.2)
https://github.com/ckolivas/cgminer/blob/master/README#L112

It is actually not many commands: get, extract, configure, make, autogen.sh cgminer (with the new libusb) then the rest as usual
I have that working libusb source archive in my cgminer-binaries also:
https://github.com/kanoi/cgminer-binaries

[daemondazz]

Are you able to build the binaries you released statically against the known good version of libusb?

[Roy Badami]

The network difficulty defines how many of these you need to find before you should, on average, find a block

Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty?  (I find it's not the same - but I guess that may be just down to what the pools report?)

roy

It's there in the block header you are hashing.
Block header being hashed is: Type, Prev, Merkl, Time, Bits, Nonce.
Diff = f(Bits)

Thanks.  And of course the value reported by cgminer is correct :-)

I made the mistake of believing the figure at the top of bitcoincharts.com

roy