Watch out, the 2013-08-14 image seems to get rid of the temp cutoff settings in the Avalon GUI, make sure you add the appropriate command-line settings, especially for batch 3.
A reminder that I've said in my announces that there is no specific batch3 support in my firmware images. Luckily the default settings are too cold for batch3 so it will not harm your device, just crank the fans up to maximum. Add your parameters to the More Options box as I said in the 3.3.2 announce. Hopefully there will be new firmware from xiangfu soon which includes all my changes as well as his batch3 interface changes. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 252. (Read 5805531 times)
August 14, 2013, 01:00:31 PM
August 14, 2013, 12:53:55 PM
Watch out, the 2013-08-14 image seems to get rid of the temp cutoff settings in the Avalon GUI, make sure you add the appropriate command-line settings, especially for batch 3.
August 14, 2013, 12:52:26 PM
guys quick question.
I have 2 identical 7970 cards. When my cards are cold, I see that fan speed is displayed differently for each of my cards:
GPU 0: 68.0C 50% | 620.3M/683.2Mh/s | A:3 R:0 HW:0 WU: 7.1/m I: 9
GPU 1: 55.0C 1815RPM | 620.3M/680.6Mh/s | A:5 R:0 HW:0 WU: 11.8/m I: 9
Eventually when they get warmer, they % value gets replaced with a RPM value in the 3000-3100 range.
Maybe I am wrong bu tthis seems like a recent behavior change. As far as I know, previously fan speed was always displayed in RPM...
That code hasn't been changed in a long time. Each device reports whether it can detect RPM speed or only report the set fan percentage speed. cgminer tries to show the actual RPM speed if it can (since that's safer than a device that thinks it's set to 100% but the fan isn't spinning), and falls back to percentage only when the device reports it doesn't support RPM. If something is changing while your machine is running, your driver/hardware is doing some funkiness I have 2 identical 7970 cards. When my cards are cold, I see that fan speed is displayed differently for each of my cards:
GPU 0: 68.0C 50% | 620.3M/683.2Mh/s | A:3 R:0 HW:0 WU: 7.1/m I: 9
GPU 1: 55.0C 1815RPM | 620.3M/680.6Mh/s | A:5 R:0 HW:0 WU: 11.8/m I: 9
Eventually when they get warmer, they % value gets replaced with a RPM value in the 3000-3100 range.
Maybe I am wrong bu tthis seems like a recent behavior change. As far as I know, previously fan speed was always displayed in RPM...
August 14, 2013, 12:49:56 PM
guys quick question.
I have 2 identical 7970 cards. When my cards are cold, I see that fan speed is displayed differently for each of my cards:
GPU 0: 68.0C 50% | 620.3M/683.2Mh/s | A:3 R:0 HW:0 WU: 7.1/m I: 9
GPU 1: 55.0C 1815RPM | 620.3M/680.6Mh/s | A:5 R:0 HW:0 WU: 11.8/m I: 9
Eventually when they get warmer, they % value gets replaced with a RPM value in the 3000-3100 range.
Maybe I am wrong bu tthis seems like a recent behavior change. As far as I know, previously fan speed was always displayed in RPM...
I have 2 identical 7970 cards. When my cards are cold, I see that fan speed is displayed differently for each of my cards:
GPU 0: 68.0C 50% | 620.3M/683.2Mh/s | A:3 R:0 HW:0 WU: 7.1/m I: 9
GPU 1: 55.0C 1815RPM | 620.3M/680.6Mh/s | A:5 R:0 HW:0 WU: 11.8/m I: 9
Eventually when they get warmer, they % value gets replaced with a RPM value in the 3000-3100 range.
Maybe I am wrong bu tthis seems like a recent behavior change. As far as I know, previously fan speed was always displayed in RPM...
August 14, 2013, 12:37:15 PM
Latest cgminer 3.3.3 on usb be is not working on p2pool - all rejected.
In p2pool log i see some startum errors.
Hence 3.3.4 In p2pool log i see some startum errors.
August 14, 2013, 12:34:40 PM
Latest cgminer 3.3.3 on usb be is not working on p2pool - all rejected.
In p2pool log i see some startum errors.
In p2pool log i see some startum errors.
August 14, 2013, 12:28:24 PM
Unofficial Mac binaries updated to 3.3.4 at http://spaceman.ca/cgminer.
August 14, 2013, 01:50:50 AM
Are you able to build the binaries you released statically against the known good version of libusb?
All the ones in my cgminer-binaries are statically linked to the working libusb, but dynamic with everything else.https://github.com/kanoi/cgminer-binaries
August 14, 2013, 01:36:52 AM
Updated my binaries git to 3.3.4a + 3.3.4 master binaries/src (and removed 3.3.3a + 3.3.3 master binaries/src)
https://github.com/kanoi/cgminer-binaries
https://github.com/kanoi/cgminer-binaries
August 14, 2013, 01:01:10 AM
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
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
August 14, 2013, 12:53:52 AM
Are you able to build the binaries you released statically against the known good version of libusb?
August 14, 2013, 12:39:02 AM
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)Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.
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
August 13, 2013, 11:46:07 PM
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? Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.
August 13, 2013, 11:41:38 PM
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.
Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.
August 13, 2013, 10:14:58 PM
Already running 3.3.4 on bitminter flawlessly.
thank you very much for your amazing job!
thank you very much for your amazing job!
August 13, 2013, 10:10:40 PM
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.
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.
August 13, 2013, 06:58:08 PM
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
Block header being hashed is: Type, Prev, Merkl, Time, Bits, Nonce.
Diff = f(Bits)
August 13, 2013, 06:32:58 PM
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
August 13, 2013, 05:33:28 PM
Got it! Thanks Kano. 
August 13, 2013, 05:22:06 PM
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 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.
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.
Jump to: