tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 12:42:20 AM Last edit: February 25, 2014, 12:54:46 AM by tacotime |
|
What HW revision you got?
1.1 cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 01:45:38 AM Last edit: February 25, 2014, 02:09:20 AM by ckolivas |
|
What HW revision you got?
1.1 cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0 Yes there was a crash in 4.0 that was fixed afterwards in git. The bug is actually there in earlier versions as well but it's harder to trip. EDIT: I'll be releasing a new version tonight 4.0.1 with a few more improvements for hfa devices.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 03:53:28 AM Last edit: February 25, 2014, 04:33:09 AM by tacotime |
|
Big problem I'm seeing with this new firmware is that it no longer automatically restarts the unit by hotplugging once it dies from the internal watchdog on 3.11.0... shoot. Messing with 4.0.0 again now.
edit: Do not update this if you have a rev 1.1 board, the newer firmware is less stable at higher clocks!!
ckolivas, please pass me older firmware with the watchdog if you have it, this new firmware is super unstable for me
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
DoogieHouser
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 133
Merit: 100
Bitcoin Enthusiast
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 04:39:53 AM |
|
What HW revision you got?
1.1 cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0 Q: How can you tell which hardware rev you've got? Since my Ubuntu installation is fairly new, I went ahead and added the dependencies mentioned in firmware_update.py, as follows:
#!/bin/bash # pre-setup.sh - Run before setup.sh # sudo apt-get install libusb-1.0-0-dev sudo apt-get install python-usb sudo apt-get install python-pip sudo pip install --upgrade pyusb
Output from firmware_update.py confirm is False FIRMWARE_DIR is . Traceback (most recent call last): File "./firmware_update.py", line 62, in <module> DFU_PROGRAMMER=shutil.which("dfu-programmer") AttributeError: 'module' object has no attribute 'which'
|
--Doogie
|
|
|
DoogieHouser
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 133
Merit: 100
Bitcoin Enthusiast
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 04:54:26 AM |
|
[OT] Mt. Gox is off-line. BTC prices are at a three-month low...
|
--Doogie
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:19:15 AM |
|
ckolivas, please pass me older firmware with the watchdog if you have it, this new firmware is super unstable for me
This was the 0.3 release candidate: http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfuDon't assume any of these downloads will remain online long term. I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:38:29 AM |
|
Rolled back and seems to be working okay again, thanks With the other firmware it ran for 10 or so minutes okay and then kept detecting errors and downclocking the unit, then finally when it hit ~530 MHz. At that point it just kept resetting it every 30 seconds or so, it was really strange. That was with 4.0.0. With 3.11.0 it would run very stable for a while and then wouldn't be able to recover from crashes at all (15s of failing to give golden nonces or whatever). It was just keep going down until it his 0 MH/s and sit there. This new firmware is also seemingly slower than what it was shipped with (v0.2?) at the same clocks; was getting ~445 GH/s per unit at the pool, now I'm getting only ~410 GH/s. I'll let it run overnight and see if it's just variance. Looking at the power meter, they're drawing exactly the same amount as before. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif)
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
ninjarobot
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:55:39 AM |
|
I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.
Thanks ckolivas, your help is invaluable. Much appreciated.
|
|
|
|
DoogieHouser
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 133
Merit: 100
Bitcoin Enthusiast
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 08:43:01 AM |
|
I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.
Thanks ckolivas, your help is invaluable. Much appreciated. +1 Thanks, ckolivas!
When I first started using cgminer 4.0.0, the clock rate dropped from 612 MHz to 538 MHz in less than two hours. The BabyJet would disappear, cgminer would lower the clock rate, and reconnect.
Yesterday, I ran my BabyJet with bfgminer 3.10.0, to see how the hashrate compared to cgminer 4.0.0. When bfgminer was connected to the BabyJet, it ran about 5 GH/s faster, but I think it is due to the fact that cgminer is hotplugging the miner every 20 - 30 minutes. However, bfgminer declares the BabyJet dead every 6 - 12 hours, and the only way to reconnect is to restart bfgminer. This requires constant monitoring.
Anyway, today I am pleased to see that after four hours, cgminer is still running at 600 MHz, and hashing around 400 GH/s, according to Eligius (bfgminer hashed 380 - 390 GH/s)
cgminer version 4.0.0 - Started: [2014-02-24 23:10:06] -------------------------------------------------------------------------------------------------- (5s):1.067T (avg):794.4Gh/s | A:1518537 R:2064 HW:5360 WU:11050.7/m ST: 1 SS: 47 NB: 33 LW: 1646160 GF: 0 RF: 0 Connected to stratum.mining.eligius.st diff 256 with stratum as user Block: 11fee3d5... Diff:3.13G Started: [03:35:41] Best share: 3.92M -------------------------------------------------------------------------------------------------- [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit 020: HFB 20: 600MHz 77C 33% 0.79V | 1.026T/842.4Gh/s | A: 27648 R: 0 HW:114 WU:11722.2/m -------------------------------------------------------------------------------------------------- [2014-02-25 01:00:49] HFB 8 failure, disabling! [2014-02-25 01:08:37] HFB 9 failure, disabling! [2014-02-25 01:24:12] HFB 10 failure, disabling! [2014-02-25 01:40:58] HFB 11 failure, disabling! [2014-02-25 01:58:18] HFB 12 failure, disabling! [2014-02-25 02:01:07] HFB 13 failure, disabling! [2014-02-25 02:15:29] HFB 14 failure, disabling! [2014-02-25 02:29:59] HFB 15 failure, disabling! [2014-02-25 03:03:18] HFB 16 failure, disabling! [2014-02-25 03:07:29] HFB 17 failure, disabling! [2014-02-25 03:28:11] HFB 18: Failed to reset after hash failure, disabling [2014-02-25 03:28:11] HFB 18 failure, disabling! [2014-02-25 03:36:00] HFB 19 failure, disabling!
|
--Doogie
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 10:29:22 AM |
|
Great, I'm really hoping they actually do release a firmware soon this time, and I'm trying to use 4.0.1 as a tag they can use specifically for all its hashfast related changes, improvements and bugfixes. I added some important ones just an hour ago. Here's a preview from the current git manual (all this is available now if you build from git with the newer firmware, new in bold):
Hashfast devices
--hfa-hash-clock <arg> Set hashfast clock speed (default: 550)
This will change the initialisation clock speed on all attached hfa devices. Note that if instability is detected by cgminer and the device has to undergo a reset, cgminer will lower the clockspeed on resetting it each time till the value returns to the default of 550.
--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)
If you overclock your hashfast device with --hfa-hash-clock and cgminer detects it failing to return hashes, it will restart it at a lower clock speed if possible. Changing this value will allow you to choose how much it will lower the clock speed or to disable this function entirely.
--hfa-fan <arg> Set fanspeed percentage for hashfast, single value or range (default: 10-85)
This changes the range of fanspeeds used on hashfast devices with firmware that supports it. Note that the fanspeed will dynamically change to try and maintain a target temperature with --hfa-temp-target but if the target temperature is disabled, the fanspeed will remain static. eg: --hfa-fan 25-100
--hfa-temp-overheat <arg> Set the hashfast overheat throttling temperature (default: 95)
Cgminer will temporarily stop sending hashfast devices work once this temperature is reached. Note that with the water cooling in these devices, temperature recovery is likely to be very quick and the device will start hashing again after only a very brief period.
--hfa-temp-target <arg> Set the hashfast target temperature (0 to disable) (default: 88)
On hashfast devices with firmware that supports dynamic fanspeed and die speeds, cgminer will try to maintain temperature according to this target by adjusting fanspeed and then if need be, throttle speeds on a die-by-die basis. Disabling this feature will leave a constant fanspeed and die speed but will not disable the temp-overheat feature.
--hfa-name <arg> Set a unique name for a single hashfast device specified with --usb or the first device found
This command allows you to specify the unique name stored in nvram on a single hashfast device. This name can be queried from the API stats command and comes up as "op name". Discrete names are used by cgminer to try to maintain settings across restarts, unplugs/hotplugs and so on. If this command is used by itself, the name will be given to the first hashfast device it encounters and then cgminer will proceed to go back to regular mining. If you have multiple devices, it is best to discretely choose the device you wish to use with the --usb command. For example 'lsusb' on linux shows the following devices (297c:0001 is a hfa device): Bus 001 Device 079: ID 297c:0001 Bus 004 Device 042: ID 297c:0001 If you wished to name the second device Slug you would add the commands: --hfa-name Slug --usb 4:42
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
storm2k5
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 12:17:21 PM |
|
Q: How can you tell which hardware rev you've got?
There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw)
|
|
|
|
DoogieHouser
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 133
Merit: 100
Bitcoin Enthusiast
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 03:29:11 PM |
|
Q: How can you tell which hardware rev you've got?
There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw) As I suspected, the HW rev is 1.1 (mine shipped on January 28th)
cgminer 4.0.0 will run for a few hours @ 600 MHz (81 C), then a few hours at 575 MHz (78 C), then 555, etc. When it drops below 550, I just restart cgminer and repeat the cycle. It beats bfgminer getting stuck in an endless loop after it declare the BabyJet dead. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
--Doogie
|
|
|
storm2k5
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 04:21:34 PM |
|
Q: How can you tell which hardware rev you've got?
There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw) As I suspected, the HW rev is 1.1 (mine shipped on January 28th)
cgminer 4.0.0 will run for a few hours @ 600 MHz (81 C), then a few hours at 575 MHz (78 C), then 555, etc. When it drops below 550, I just restart cgminer and repeat the cycle. It beats bfgminer getting stuck in an endless loop after it declare the BabyJet dead. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10) Did you try to set that to 0?
|
|
|
|
CurcO
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 05:45:07 PM |
|
So the FW .03 is way better at OC than the Candidate release 0.4 however both are a step in the right direction ... I now get very few errors when I OC above 650 , ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) , thx Ckolivas
|
|
|
|
edgie13
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:03:22 PM |
|
So the FW .03 is way better at OC than the Candidate release 0.4 however both are a step in the right direction ... I now get very few errors when I OC above 650 , ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) , thx Ckolivas What gh/s are you getting at the pool when OCed above 650? Thanks.
|
BTC Scotch fund: 1GFZos2WGknCeVgDtjpHwo3jeJ4tSLVrXS
|
|
|
CurcO
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:40:49 PM |
|
650 = 450 gh/s 687 = 480 gh/s ( the best I get) 700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently
|
|
|
|
CurcO
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 06:42:10 PM |
|
Pool Eligius and also I have the same result with BTCGuild
|
|
|
|
Taugeran
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 08:37:57 PM |
|
I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.
Thanks ckolivas, your help is invaluable. Much appreciated. +1 Thanks, ckolivas!
When I first started using cgminer 4.0.0, the clock rate dropped from 612 MHz to 538 MHz in less than two hours. The BabyJet would disappear, cgminer would lower the clock rate, and reconnect.
Yesterday, I ran my BabyJet with bfgminer 3.10.0, to see how the hashrate compared to cgminer 4.0.0. When bfgminer was connected to the BabyJet, it ran about 5 GH/s faster, but I think it is due to the fact that cgminer is hotplugging the miner every 20 - 30 minutes. However, bfgminer declares the BabyJet dead every 6 - 12 hours, and the only way to reconnect is to restart bfgminer. This requires constant monitoring.
Anyway, today I am pleased to see that after four hours, cgminer is still running at 600 MHz, and hashing around 400 GH/s, according to Eligius (bfgminer hashed 380 - 390 GH/s)
cgminer version 4.0.0 - Started: [2014-02-24 23:10:06] -------------------------------------------------------------------------------------------------- (5s):1.067T (avg):794.4Gh/s | A:1518537 R:2064 HW:5360 WU:11050.7/m ST: 1 SS: 47 NB: 33 LW: 1646160 GF: 0 RF: 0 Connected to stratum.mining.eligius.st diff 256 with stratum as user Block: 11fee3d5... Diff:3.13G Started: [03:35:41] Best share: 3.92M -------------------------------------------------------------------------------------------------- [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit 020: HFB 20: 600MHz 77C 33% 0.79V | 1.026T/842.4Gh/s | A: 27648 R: 0 HW:114 WU:11722.2/m -------------------------------------------------------------------------------------------------- [2014-02-25 01:00:49] HFB 8 failure, disabling! [2014-02-25 01:08:37] HFB 9 failure, disabling! [2014-02-25 01:24:12] HFB 10 failure, disabling! [2014-02-25 01:40:58] HFB 11 failure, disabling! [2014-02-25 01:58:18] HFB 12 failure, disabling! [2014-02-25 02:01:07] HFB 13 failure, disabling! [2014-02-25 02:15:29] HFB 14 failure, disabling! [2014-02-25 02:29:59] HFB 15 failure, disabling! [2014-02-25 03:03:18] HFB 16 failure, disabling! [2014-02-25 03:07:29] HFB 17 failure, disabling! [2014-02-25 03:28:11] HFB 18: Failed to reset after hash failure, disabling [2014-02-25 03:28:11] HFB 18 failure, disabling! [2014-02-25 03:36:00] HFB 19 failure, disabling!
You can use bfgminer with --cmd-dead <cmd here> to restart bfgminer when it dies
|
Bitfury HW & Habañero : 1.625Th/s tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1 Come join Coinbase
|
|
|
storm2k5
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 08:54:31 PM |
|
650 = 450 gh/s 687 = 480 gh/s ( the best I get) 700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently
Interesting, I also got my best OC at 687.
|
|
|
|
CurcO
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 09:30:51 PM |
|
650 = 450 gh/s 687 = 480 gh/s ( the best I get) 700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently
Interesting, I also got my best OC at 687. Strom2k5 What rev ?, I'm on 1.1
|
|
|
|
|