The Habanero - 650GH/s - OOS - page 20.

QuiveringGibbage

hero member

Activity: 617

Merit: 543

http://idontALT.com

Quote from: MrTeal on June 17, 2014, 08:33:42 AM

The voltage reported by cgminer comes from some on-die sensors, so it will always be lower than the setpoint measured by the VRM, which happens off-chip. That's normal.

Do you still have that piece of MDF right behind the boards, and is there any air flowing over the boards themselves? You can see similar things if the VRMs shut down due to high temperatures.

ahh yes, you the man!! and Gateway, I remember him telling me to put more air flow over the boards. just got ahead of my self and didn't attached the fans. Here's the difference; Pic1 Temps. (90c) with fan OFF and Pic2 temps.(75c) with fan ON and I could see the errors appear and disappear as I turn the fan off an on and as the board heated up and cooled.

Pic1 and Pic2

Pic3

More pics here: http://imgur.com/a/SMBJP#21

Cheers,
QG

GenTarkin

legendary

Activity: 2450

Merit: 1002

btw ... for me --hfa-noshed actually disables those 8 cores to begin with in cgminer
Leaving out --hfa-noshed ... activates all 768 cores from start...
I wonder, will the inflight value in the api ... change to reflect if a core gets disabled via firmware ... as its mining?

btchedge

member

Activity: 92

Merit: 10

Important consideration regarding cooling heads!

Through the process of sourcing various cooling heads in our search for the best performance, we learned that many popular cooling heads are NOT flat. Certain heads are just slightly curved so as to better fit the intended CPU form factor they were originally designed for. Using such a head could lead to less than optimal results with Habaneros since the contact surface is not perfectly flat. I will post some more details soon regarding the heads that test best. In the meantime, make sure you don't haul off and buy a high performance solution whose design will only guarantee lower performance due to it's design.

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: Taugeran on June 17, 2014, 01:42:56 PM

We're all your runs long enough to let things settle? ~30mins

I remember flipping out very time if have to restart bfgminer on my bitfury rigs it'd occasionally show stupid high error rates for about 4-5 minutes while things settled down to normal 0.5-1.5%

Sorry to bring different hardware into the tread. Just sharing experience

Yep, Ive let it settled for sure.

QuiveringGibbage

hero member

Activity: 617

Merit: 543

http://idontALT.com

Quote from: faxfan2002 on June 16, 2014, 05:03:56 AM

Are those push or pull fans? I would expect them to be the other way round pushing the hot air away from the boards?

Pull, sucking the hot air from radiator and pushing them away from the board.

Quote from: MrTeal on June 17, 2014, 08:33:42 AM

The voltage reported by cgminer comes from some on-die sensors, so it will always be lower than the setpoint measured by the VRM, which happens off-chip. That's normal.
Do you still have that piece of MDF right behind the boards, and is there any air flowing over the boards themselves? You can see similar things if the VRMs shut down due to high temperatures.

Right, I'll try more air flow over and under the boards. I have ~50cm standoffs which the boards mount on so there's space below the boards for airflow, just need to attached fans to my frame.

Will report back once i've made completed the build.

Cheers,
QG

gateway

hero member

Activity: 552

Merit: 500

Btw JakeTri has his code he converted from the python hf-tool into cgminer pushed into the latest git of cgminer.. so you have commands like

Code:

--hfa-options  Set hashfast options name:clock or clock@voltage (comma separated)

Code:

--hfa-options "rabbit:650,turtle:550@800"

Quote

+Would set a device named rabbit to clock speed 650 MHz using default voltage
+and the one named turtle to 550 MHz using a voltage of 800 mv. Starting the
+device at a speed where it is most stable will give more reliable hashrates
+long term and prevent it interacting with other devices, rather than depending
+on the clockdown feature in cgminer.

see https://github.com/ckolivas/cgminer/commit/ef97e80a14240c95a7d2966abe462b12f7d4bf03

you would need to build the latest git cgminer for this to work.

Also use with caution, we cannot be responsible if you happen to blow up your board

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: Taugeran on June 17, 2014, 01:42:56 PM

Quote from: GenTarkin on June 17, 2014, 01:05:41 PM

Quote from: gateway on June 17, 2014, 12:54:02 PM

Quote from: GenTarkin on June 17, 2014, 12:18:52 AM

Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:

1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer

3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"

Any ideas as to what could be going on?! =/
This is confusing the hell outta me....

are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement.

Yeah, seems to have no effect =/ ... Whats odd is w/ noshed, the inflight count was 760, w/o noshed, at least this time, the inflight shows 768 =P ROFL! ... complete opposite of what it should be like, but I may verify those results.
If only bfgminer supported setting fan speeds, Id be using it instead of cgminer for the habs, seems to have much more accurate hashrate readout & consistency ... not to mention poolside hashrate measurement is always nice to see, which cgminer doesnt show at all.
Also, I dont know which miner to believe, because bfgminer shows upwards of 4% HW error on one of the habs, cuz its clocked a bit too high, whereas cgminer shows only 1.2% ... so which to believe, not sure, but the loss in hashrate would be consistent w/ the 4% HW ... but dropping clocks, even tho lowers HW%, doesnt affect the drop in hashrate. Its just allout confusing ... LOL

We're all your runs long enough to let things settle? ~30mins

I remember flipping out very time if have to restart bfgminer on my bitfury rigs it'd occasionally show stupid high error rates for about 4-5 minutes while things settled down to normal 0.5-1.5%

Sorry to bring different hardware into the tread. Just sharing experience

I've noticed that with the Habaneros and Chilis as well, and it seems to be pool dependent. Right off the start you might see a few hundred HW errors, and after that it settles down to a normal pace.

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: GenTarkin on June 17, 2014, 01:05:41 PM

Quote from: gateway on June 17, 2014, 12:54:02 PM

Quote from: GenTarkin on June 17, 2014, 12:18:52 AM

Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:

1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer

3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"

Any ideas as to what could be going on?! =/
This is confusing the hell outta me....

are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement.

Yeah, seems to have no effect =/ ... Whats odd is w/ noshed, the inflight count was 760, w/o noshed, at least this time, the inflight shows 768 =P ROFL! ... complete opposite of what it should be like, but I may verify those results.
If only bfgminer supported setting fan speeds, Id be using it instead of cgminer for the habs, seems to have much more accurate hashrate readout & consistency ... not to mention poolside hashrate measurement is always nice to see, which cgminer doesnt show at all.
Also, I dont know which miner to believe, because bfgminer shows upwards of 4% HW error on one of the habs, cuz its clocked a bit too high, whereas cgminer shows only 1.2% ... so which to believe, not sure, but the loss in hashrate would be consistent w/ the 4% HW ... but dropping clocks, even tho lowers HW%, doesnt affect the drop in hashrate. Its just allout confusing ... LOL

We're all your runs long enough to let things settle? ~30mins

I remember flipping out very time if have to restart bfgminer on my bitfury rigs it'd occasionally show stupid high error rates for about 4-5 minutes while things settled down to normal 0.5-1.5%

Sorry to bring different hardware into the tread. Just sharing experience

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: gateway on June 17, 2014, 12:54:02 PM

Quote from: GenTarkin on June 17, 2014, 12:18:52 AM

Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:

1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer

3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"

Any ideas as to what could be going on?! =/
This is confusing the hell outta me....

are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement.

Yeah, seems to have no effect =/ ... Whats odd is w/ noshed, the inflight count was 760, w/o noshed, at least this time, the inflight shows 768 =P ROFL! ... complete opposite of what it should be like, but I may verify those results.
If only bfgminer supported setting fan speeds, Id be using it instead of cgminer for the habs, seems to have much more accurate hashrate readout & consistency ... not to mention poolside hashrate measurement is always nice to see, which cgminer doesnt show at all.
Also, I dont know which miner to believe, because bfgminer shows upwards of 4% HW error on one of the habs, cuz its clocked a bit too high, whereas cgminer shows only 1.2% ... so which to believe, not sure, but the loss in hashrate would be consistent w/ the 4% HW ... but dropping clocks, even tho lowers HW%, doesnt affect the drop in hashrate. Its just allout confusing ... LOL

gateway

hero member

Activity: 552

Merit: 500

Quote from: GenTarkin on June 17, 2014, 12:18:52 AM

Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:

1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer

3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"

Any ideas as to what could be going on?! =/
This is confusing the hell outta me....

are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement.

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: QuiveringGibbage on June 17, 2014, 06:42:51 AM

Quote from: SVK on June 16, 2014, 07:05:07 AM

Are you running both boards from that AX1200 PSU ?
If yes there might be your problem.
I'm using 2 PSUs 850W + 750W and power draw from the wall is around 1450W at 775MHZ.

no no, Antec1300w and AX1200i pulling a total of 1440w at the wall.

and this is the cgminer stats at the time of posting.

Code:

 0: HFB JOLOKIA : 825MHz  87C 100% 0.84V  | 534.3G / 621.0Gh/s WU:8676.0/m A:428159 R:  0 HW:119
 1: HFB FRUTESCE: 762MHz  77C 100% 0.84V  | 539.6G / 586.9Gh/s WU:8199.9/m A:418570 R:532 HW: 49

sadly if I push either board any more it's noticeably unstable. 620ghs and 580ghs is what i can get from my boards. without the ability to adjust the individual dies' clock rate, i can't squeeze the last bits of hash out of them. I don't know if anyone's going to put the effort in to read the code and suggest what needs to be fixed so we can fully utilize the HF-Tool.

oh and this is what happens when i say unstable:

Code:

[2014-06-17 21:25:45] Accepted 380808fb Diff 1.17K/532 HFB 0 pool 0
 [2014-06-17 21:25:51] Accepted 65e2e50e Diff 643/532 HFB 1 pool 0
 [2014-06-17 21:25:52] HFB JOLOKIA: No valid hashes for over 5 seconds, shutting down thread
 [2014-06-17 21:25:59] HFB 0 failure, disabling!
 [2014-06-17 21:26:05] HFA 0 HFName usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2014-06-17 21:26:05] HFA 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-06-17 21:26:05] HFA : hfa_send_frame: USB Send error, ret 0 amount 0 vs. tx_length 8, retrying
 [2014-06-17 21:26:05] HFA : hfa_send_frame: recovered OK
 [2014-06-17 21:26:05] HFA 0 HFGetHeader usb read err:(-9) LIBUSB_ERROR_PIPE
 [2014-06-17 21:26:05] HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-06-17 21:26:05] FAIL: USB get_lock not found (2:11)
 [2014-06-17 21:26:10] Accepted 79a271c1 Diff 539/532 HFB 1 pool 0
 [2014-06-17 21:26:11] HFA: Found old instance by op name JOLOKIA at device 0
 [2014-06-17 21:26:11] Hotplug: Hashfast added HFA 2
 [2014-06-17 21:26:24] Accepted 23b05141 Diff 1.84K/532 HFB 1 pool 0
 [2014-06-17 21:26:25] Accepted 32558e25 Diff 1.3K/532 HFB 0 pool 0

I have no solution to the above other than to use a lower clock rate. I have tried to set the Voltage higher with the HF-Tool but even if i set 930, cgminer still only runs with under 0.90V.

if anyone has any hints, I'd much appreciate it.

Cheers,
QG

The voltage reported by cgminer comes from some on-die sensors, so it will always be lower than the setpoint measured by the VRM, which happens off-chip. That's normal.

Do you still have that piece of MDF right behind the boards, and is there any air flowing over the boards themselves? You can see similar things if the VRMs shut down due to high temperatures.

QuiveringGibbage

hero member

Activity: 617

Merit: 543

http://idontALT.com

EDIT: Issue resolved https://bitcointalksearch.org/topic/m.7377697

Quote from: SVK on June 16, 2014, 07:05:07 AM

Are you running both boards from that AX1200 PSU ?
If yes there might be your problem.
I'm using 2 PSUs 850W + 750W and power draw from the wall is around 1450W at 775MHZ.

no no, Antec1300w and AX1200i pulling a total of 1440w at the wall.

and this is the cgminer stats at the time of posting.

Code:

 0: HFB JOLOKIA : 825MHz  87C 100% 0.84V  | 534.3G / 621.0Gh/s WU:8676.0/m A:428159 R:  0 HW:119
 1: HFB FRUTESCE: 762MHz  77C 100% 0.84V  | 539.6G / 586.9Gh/s WU:8199.9/m A:418570 R:532 HW: 49

sadly if I push either board any more it's noticeably unstable. 620ghs and 580ghs is what i can get from my boards. without the ability to adjust the individual dies' clock rate, i can't squeeze the last bits of hash out of them. I don't know if anyone's going to put the effort in to read the code and suggest what needs to be fixed so we can fully utilize the HF-Tool.

oh and this is what happens when i say unstable:

Code:

[2014-06-17 21:25:45] Accepted 380808fb Diff 1.17K/532 HFB 0 pool 0
 [2014-06-17 21:25:51] Accepted 65e2e50e Diff 643/532 HFB 1 pool 0
 [2014-06-17 21:25:52] HFB JOLOKIA: No valid hashes for over 5 seconds, shutting down thread
 [2014-06-17 21:25:59] HFB 0 failure, disabling!
 [2014-06-17 21:26:05] HFA 0 HFName usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2014-06-17 21:26:05] HFA 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-06-17 21:26:05] HFA : hfa_send_frame: USB Send error, ret 0 amount 0 vs. tx_length 8, retrying
 [2014-06-17 21:26:05] HFA : hfa_send_frame: recovered OK
 [2014-06-17 21:26:05] HFA 0 HFGetHeader usb read err:(-9) LIBUSB_ERROR_PIPE
 [2014-06-17 21:26:05] HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-06-17 21:26:05] FAIL: USB get_lock not found (2:11)
 [2014-06-17 21:26:10] Accepted 79a271c1 Diff 539/532 HFB 1 pool 0
 [2014-06-17 21:26:11] HFA: Found old instance by op name JOLOKIA at device 0
 [2014-06-17 21:26:11] Hotplug: Hashfast added HFA 2
 [2014-06-17 21:26:24] Accepted 23b05141 Diff 1.84K/532 HFB 1 pool 0
 [2014-06-17 21:26:25] Accepted 32558e25 Diff 1.3K/532 HFB 0 pool 0

I have no solution to the above other than to use a lower clock rate. I have tried to set the Voltage higher with the HF-Tool but even if i set 930, cgminer still only runs with under 0.90V.

if anyone has any hints, I'd much appreciate it.

Cheers,
QG

EDIT: Issue resolved https://bitcointalksearch.org/topic/m.7377697

GenTarkin

legendary

Activity: 2450

Merit: 1002

Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:

1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer

3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"

Any ideas as to what could be going on?! =/
This is confusing the hell outta me....

i3luefire

member

Activity: 86

Merit: 10

Quote from: ZiG on June 15, 2014, 09:58:35 PM

Quote from: MrTeal on June 15, 2014, 09:04:21 PM

Quote from: ZiG on June 15, 2014, 08:33:52 PM

Brand...?...Model...? ...Link...?

Thanks,

ZiG

They're from an HP BLC7000 blade server, model # HSTNS-PR16
http://www.ebay.ca/itm/Hewlett-Packard-HP-HSTNS-PR16-488603-001-2450W-Power-Supply-for-HP-C7000-/321369086929?pt=PCA_UPS&hash=item4ad3171bd1

Thanks, buddy...

What is the pinout on that connector? is it easy to mate to?

GenTarkin

legendary

Activity: 2450

Merit: 1002

Think I just figured it out and how can this be fixed....?
I ran bfgminer and immediately on startup it shows a total of 8 lines showing "disabled" .. like cores or something... it goes by to fast to see exactly what its saying.
Ugh... why would it be disabling shit? =/

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quick update, I looked at miner.php api output and it just shows inflight_target at 760
Also shows "sequence modules" at 2048, if that means anything to figuring this all out =/

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: gateway on June 16, 2014, 04:06:25 PM

Quote from: GenTarkin on June 16, 2014, 09:47:06 AM

Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH
Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH
So, somewhere Im losing 3% on each one =*(

What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation?

Also, like in my original post, any way to see the status of each 96 cores?
Thanks

Sorry to hear about your issues, as far as a status of each core cgminer does not provide this information, BFGMiner does but I haven't had the time or energy to work on porting the Pepper App to use BFG, and while BFG is a great miner its missing some of the functionality currently that you can do with cgminer for HF/HAB products.

One thing is to check your inflight value per board, now this isnt displayed in the pepper app, I could prob make a build with a debug option at the bottom of each page, this should be around 760ish.. if you have damaged a die this value gets lower. Mr Teal could maybe elaborate a bit on this if he has time.

Also while these things can be fun to play with and tweak to maximum performance their are times where damage *could* happen. I have busted a few boards just doing this and killed off a die so just be careful with them.

I think I saw the inflight field in my miner.php, will look for that. I would like an explanation about this value and how to make heads or tails about the condition of the cores.

Also, I cant fathom how I would damage a board, Ive barely gone over stock (highest Ive put in hf-tool is 950mv and one one hab Ive not gone over stock period) in voltages and the dies have never seen over 104C - cgminer immediately drops them off. Most of the times my temps are under 100C

I will look into bfgminer ... see if it can give me more info =)

gateway

hero member

Activity: 552

Merit: 500

Quote from: GenTarkin on June 16, 2014, 09:47:06 AM

Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH
Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH
So, somewhere Im losing 3% on each one =*(

What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation?

Also, like in my original post, any way to see the status of each 96 cores?
Thanks

Sorry to hear about your issues, as far as a status of each core cgminer does not provide this information, BFGMiner does but I haven't had the time or energy to work on porting the Pepper App to use BFG, and while BFG is a great miner its missing some of the functionality currently that you can do with cgminer for HF/HAB products.

One thing is to check your inflight value per board, now this isnt displayed in the pepper app, I could prob make a build with a debug option at the bottom of each page, this should be around 760ish.. if you have damaged a die this value gets lower. Mr Teal could maybe elaborate a bit on this if he has time.

Also while these things can be fun to play with and tweak to maximum performance their are times where damage *could* happen. I have busted a few boards just doing this and killed off a die so just be careful with them.

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: MrTeal on June 16, 2014, 12:32:53 AM

Quote from: GenTarkin on June 16, 2014, 12:13:20 AM

So, is it possible to see the status of the 96 cores per die?
Reason I ask is, when I got these, before I tweaked voltages / cooler mounting etc... I remember the MHav over a 10hr period was right around 650GH per hab @ 850mhz
Which, 850 * 96 * 2 * 4 = 652GH ... add the HW% and the 650GH sounds about right.

After tweaking the waterblock heads, voltages and messing w/ clocks ... I have the cooler hab running at 875mhz, 1mv higher than stock, it shows no dropouts(due to not enough voltage) in the pepper app .. after a few hours of mining, its only showing 645GHav ... it should be closer to 660-670 .. HW% is largely unchanged.
So, Im confused as hell, if I put it back to 850mhz, its right around 630GHav now =(

My other hab, Im not able to get it stable at 875mhz, so its at 850mhz ... its showing the same drop, down to 630GH now =/

So, Im wondering, is it possible for individual cores or an engine in a core just die / not work and go unnoticed? Hence why Im wondering if its possible to see the status?

I have no idea whats causing this random drop.

My temperatures are all well within range too.... help!

I have noticed this sometimes happens as well. It's a peculiarity of the chip, and a little more voltage usually cures it. Remember there are two kinds of hardware errors, one is where a share is submitted that shouldn't be; cgminer will see this and flag it as a HW error. The other is a dark HW error, where a specific bit of work should give a valid share but doesn't. This one won't get reported as a HW error, since cgminer doesn't know it's happened.
There seems to be a small zone between where work stops noticeable enough to affect temperatures that you can see in the PepperApp, and normal operation where (probably) valid nonces don't get reported.
As a general rule, we shipped the boards with the voltage set high enough to get the 650GH/s we advertised, and most will hit 875MHz at that voltage as well. It's a compromise between power consumption and overclocking ability. If your temperatures are still good, I'd try giving it another 10mV and see if the hashrate moves to what you expect.

Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH
Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH
So, somewhere Im losing 3% on each one =*(

What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation?

Also, like in my original post, any way to see the status of each 96 cores?
Thanks

joeltang

newbie

Activity: 35

Merit: 0

Quote from: Batshark on June 14, 2014, 11:40:51 PM

Quote from: joeltang on June 13, 2014, 07:18:18 PM

Quote from: Batshark on June 13, 2014, 05:37:44 PM

Quote from: joeltang on June 13, 2014, 05:00:23 PM

Quote from: joeltang on June 13, 2014, 04:22:26 PM

this might be a cgminer config issue but can anyone help me with this error?
"HFA : OP_USB_INIT failed! Operation status 20 (regulator programming error)
edit:using cgminer 4.3.4

Now I get this one: "OP_USB_INIT: Tossing packet, valid but unexpected type 144"

Can someone point me in a direction? I'm lost.

I had a similar error, but I cant remember if it was the exact same. My issue was a missing WinUSB driver. I installed the missing driver using zadig (http://zadig.akeo.ie/), and haven't had any issues since.

I'm okay now, it wasn't clear to me that power was required on all four plugs. (at least it is in my case) USB errors are for the most part gone.

My cooler has yet to arrive and I'm reaching thermal overload rather quickly even with "--hfa-hash-clock 100".
I'm assuming this is normal behavior without a cooler on board. I'm going to see how much hashing I can achieve with my cpu air cooler resting on the die with the fan on it.

My face when I read this

No, don't do that, and dont just 'sit' the cooler on top, you need to attach it properly and securely with quality thermal paste and appropriate pressure on all four dies. But you seriously need a liquid cooling system to run these properly. I think you should get an off the shelf cooling system, corsair and coolermaster make factory sealed liquid cooling options (coolermaster nepton 280 fits perfect if you plan on cooling the bottom of the board with the radiator exhaust, which I recommend.)

Unless you are trolling us, which I'm giving you the benefit of the doubt, but if you still have power going to your habanero, please turn it off. You can contact me and I can walk you through the steps if you really need to, but please don't run it without all of the proper equipment and installation. It would be a shame to blow it up before you even got it working properly. There is plenty of information on how to install these on the forums, you can clearly see every habanero picture posted has some kind of liquid cooling attached. If you need any questions answered before you power it on again, please ask away but for everyone's sake please turn it off until you are completely sure what you need to do

Not trolling, thanks for your offer to help but I think those few items were the only pieces of information I was lacking. I agree, that this thread does have lots of disjointed information I could have gleamed if I had been aware of its existence. I've been running this setup for the whole weekend never exceeding 96C, but I highly look forward to my Nepton 280 arriving early this week. I work in electronics and have tons of hardware experience like many of you, so I do understand the basics of heat dissipation. I am not upset but do not expect me to have sympathy for a business that sells a product without providing instructions or even inform customers of a thread that requires reading to avoid destroying the product. That kind of info should be included somehow. . you would think. Just a suggestion.

Topic: The Habanero - 650GH/s - OOS - page 20. (Read 96043 times)