Pages:
Author

Topic: Experimenting with Jalapeno firmware... - page 8. (Read 62616 times)

newbie
Activity: 20
Merit: 0
September 15, 2013, 04:45:00 PM
Yeah I did remove the heatsink and replace the thermal pad with IC Diamond 7 (seemed like a good choice to replace the pad due to the thickness of the paste and it being advertised as less prone to bleeding/separating than other pastes). Shouldn't be loose, snugged the heatsink down pretty good but was careful about overtightening as well, have worked with old AthlonXP CPUs and other bare die chips before and didn't want to chip or crack a die or anything.

And as mentioned reported temps always seemed great. Was getting like 40-41C stock I think, 43-44C after replacing the pad and stock fan with a lower RPM model, then up to 47-50C after flashing to 1.2.5 and running at a higher hash rate.

When I get around to taking the case off I'll check everything out and make sure it looks OK. So far it's been hashing away at 4GH/s or so (looks like it only initialized with 13 engines on processor 7 this time I started it up, seems like when it initializes with 14-15 is when it stops working after running for a bit).
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
September 15, 2013, 03:24:41 PM
Leaving it unplugged for a little bit can get it going again (still only initializes with one ASIC, processor 7). After running for a little while (20-30 min or so), though, HW errors start increasing a bunch and eventually it stops accepting shares. If I do a java API stats when this happens it shows the ASIC frequency as 0MHz.

Almost seems like it's overheating, but temps reported in cgminer seem fine (40-41C). Might try removing the case and pointing a box fan at it just to rule overheating out.
Hm. Did you ever take off the heat sink? Is the sink loose? Can you try backing the speed back down to 0?

C
newbie
Activity: 20
Merit: 0
September 15, 2013, 11:19:14 AM
CGMiner won't talk to my Jally; apparently the problem is some sort of timing error, it works fine with my erupters. So I'm back on BFG, and blind as to the details of my JP. Oh well.

FF: Sorry you blew up your JP, can you post what kinds of temps you were running and error rates? Every time I tried to move above 7 the unit would generate more heat, a lot more errors (5-10%), and not a lot more hashing. It's back to stock speed 7.4gh or so 43c, 2.6% error rate, and 335.7mh/s, 1.6/.91% error rate on the two erupters.

So an overall hashing rate of 8gh/s.  I can live with that although with the difficulty change I just dropped from .05btc/day to .03btc/day. Ah well.....


Temps were 47-50C, 4-5% error rate with 1.2.5 and __ASIC_FREQUENCY_ACTUAL_INDEX=7. Keep in mind that I was getting roughly 2% error rate with the default 1.0.0 firmware straight from BFL, though (my stock Jalapeno was also hashing pretty high, 5.8GH/s so wasn't too concerned about the slightly high HW error rate). This was before I replaced the fan, added heatsinks, flashed the firmware, or did any other mods.

Maybe I had some dud chips and the firmware flash/higher frequency just accelerated their failure?

Leaving it unplugged for a little bit can get it going again (still only initializes with one ASIC, processor 7). After running for a little while (20-30 min or so), though, HW errors start increasing a bunch and eventually it stops accepting shares. If I do a java API stats when this happens it shows the ASIC frequency as 0MHz.

Almost seems like it's overheating, but temps reported in cgminer seem fine (40-41C). Might try removing the case and pointing a box fan at it just to rule overheating out.
full member
Activity: 237
Merit: 100
September 15, 2013, 03:02:24 AM
My Jalapeno has stopped working with LED1 flashing quickly. When I try to interface with it using my Dragon, I am unable to reprogram it, as I get a message: Read voltage 0.3V is outside selected device's operating range: 3.0V to 3.6V.

Has anyone encountered this issue? Any solutions?
Maybe your power supply is shot?
legendary
Activity: 2912
Merit: 1060
September 15, 2013, 01:26:07 AM
The voltage error means there's nothing attached aka atmel unresponsive
legendary
Activity: 1946
Merit: 1006
Bitcoin / Crypto mining Hardware.
September 15, 2013, 01:23:10 AM
Flip your cable my dude

It's been a few months since I tinkered with the code and flashed my Jalapeno so your suggestion was a good one, but flipping the cable did nothing as I had it plugged in properly. Has anybody else had a similar experience? It's maddening not being able to interface with the Jalapeno.
I had this issue intermittently on one of my Jala. Happened after reflashing. Power cycling few times usually fixed it for that power on period.
member
Activity: 104
Merit: 10
September 15, 2013, 01:02:23 AM
Flip your cable my dude

It's been a few months since I tinkered with the code and flashed my Jalapeno so your suggestion was a good one, but flipping the cable did nothing as I had it plugged in properly. Has anybody else had a similar experience? It's maddening not being able to interface with the Jalapeno.
legendary
Activity: 2912
Merit: 1060
September 15, 2013, 12:51:05 AM
Flip your cable my dude
member
Activity: 104
Merit: 10
September 15, 2013, 12:50:19 AM
My Jalapeno has stopped working with LED1 flashing quickly. When I try to interface with it using my Dragon, I am unable to reprogram it, as I get a message: Read voltage 0.3V is outside selected device's operating range: 3.0V to 3.6V.

Has anyone encountered this issue? Any solutions?
newbie
Activity: 4
Merit: 0
September 14, 2013, 11:41:36 PM
I've also noticed at times my jally (flashed over a month ago) will fail something internally on power up, and I'll get the "Fast Flashing front LED of doom"... I'll have to power off and on a few times to get it to not do that.  I meant to take a look at the code I compiled on there last and see if I should scale something back, but to be honest, it's never stopped hashing on me (I only see this issue when I have to power it off and back on), and it's been solid at 7.5, with less than .6% HW errors (as reported by BFG), for that month solid, so part of me says why tinker with something that works. Wink
full member
Activity: 237
Merit: 100
September 14, 2013, 11:25:22 PM
And it looks like my Jalapeno bit the dust. RIP. Sad

Last night one of the ASICs seem to have stopped working, hash rate dropped down to ~4GH/s or so and only chip #7 was showing up when running java API stats. Then got home tonight and found the red status LED on the Jalapeno flashing quickly and cgminer unable to communicate with it.

Maybe I pushed the little guy too hard. Any ideas for reviving it or is it probably toast? Tried power cycling the unit but no luck. Going to leave it unplugged for a bit then try starting it up again and see if that does anything.

EDIT: Huh. Well that seemed to get it going again, at least for the time being. Still only recognizing processor 7, though, processor 3 no longer active and hashing.

I had this problem once after a firmware flash with a higher frequency setting (the red light rapidly flashing) and fixed it by reflashing with the released BFL firmware.
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
September 14, 2013, 09:56:03 PM
CGMiner won't talk to my Jally; apparently the problem is some sort of timing error, it works fine with my erupters. So I'm back on BFG, and blind as to the details of my JP. Oh well.

FF: Sorry you blew up your JP, can you post what kinds of temps you were running and error rates? Every time I tried to move above 7 the unit would generate more heat, a lot more errors (5-10%), and not a lot more hashing. It's back to stock speed 7.4gh or so 43c, 2.6% error rate, and 335.7mh/s, 1.6/.91% error rate on the two erupters.

So an overall hashing rate of 8gh/s.  I can live with that although with the difficulty change I just dropped from .05btc/day to .03btc/day. Ah well.....

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
September 14, 2013, 10:07:40 AM
i use cgwatcher to find number of engines and speeds on powerup..
I use cgminer - way better coz it also mines.
newbie
Activity: 20
Merit: 0
September 13, 2013, 06:49:32 PM
member
Activity: 87
Merit: 10
September 11, 2013, 05:21:21 PM
i use cgwatcher to find number of engines and speeds on powerup..
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
September 11, 2013, 03:47:43 PM
Indeed. I've found that going beyond 7 does weird things for my Jally; staying at 7.3gh. Did note that uing the Artic heat pad has reduced my temps to 40c, which is very nice actually. And I found a 10 pin header that I am going to sand down to fit under the sink so I can stop taking it off all the time. Want to flash on demand. :-)

Speaking of which, is there a way to identify the number of active cores using BFGMiner, or do I have to install CGMiner?

newbie
Activity: 20
Merit: 0
September 11, 2013, 11:30:01 AM
Sounds like you lucked out, got some great chips in your Jalapenos. Smiley

There's a setting __ASIC_FREQUENCY_ACTUAL_INDEX=7 in the firmware source code that you can try changing to 8 or 9. My understanding is that this will clock the ASICs more aggressively than the default value of 7. As few HW errors as you're getting I bet there's still quite a bit of frequency headroom for the chips.
sr. member
Activity: 742
Merit: 250
September 09, 2013, 04:51:08 PM
hello. i have this jalapeno which has 15 active engines on both chips, reported max hashrate is 8745MH/s and it runs at freaking 2.6V. my other one has 15 engines on both chips, reported max hashrate of 7569MH/s and runs at 3.5V. both very low hw error rate (bfg reports <0.5%). if i apply some pseudo-logic to this, i'd think that the 8745 one is a beast which could run even higher. is it possible with current fw to get this done?
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
September 05, 2013, 12:32:40 PM
75% of 9 = ... 6.75
so obviously if you run it at 8 and only get less than 15% you are ahead
Exactly. I should get cgminer running so I can see how many cores are running on each CPU, and if that changes by my moving the diagnostic level from 10 to 1. Right now I backed out my 8 change yesterday to 7, left the diagnostics set to low, and am getting 4% failures on the bad chip instead of the 2% before. So I might have enabled another core that is throwing 2% errors overall on the chip.

The trick with running faster is it burns more heat, it seems to be going up exponentially and not linerally as I clock up, more heat=more wear=more power (which is a hill of beans right now, even with the laptop the whole shooting match only pulls 40 watts).

Next up is to try powering the system off a 12 volt battery to see if a perfectly smooth power input reduces errors. If some of the error is caused by instabilities due to the cheap-o-power supply, clean DC might mean more cores to bear which would mean more $$$$

C
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
September 05, 2013, 10:59:49 AM
I am in a very similar boat as you. I have both jallys set to 9. One Jally has normal hw errors while the other is through the roof. Plus my average speeds are all over the place.

Define through the roof? I don't think error work is sent back; I think it's just dropped. Mine now is 2.5% overall, 0% on one chip, 5% on the other. But in a technical sense, a chip core that is 25% bad is still doing 75% of the work and contributing to my overall dollars.

Perhaps.

C

75% of 9 = ... 6.75
so obviously if you run it at 8 and only get less than 15% you are ahead
Pages:
Jump to: