 Show Posts
|
|
Pages: [1]
|
Problem solved!!I was really annoyed about my V2 blades sometimes not connecting to my stratum proxy/resetting on their own, resulting in low efficiency and uptime. Few times they went down for 1 or 2 hours without any reason. Someone mentioned to keep mobiles with enabled WiFi/WLAN away from the blades. Followed that hint and the connection to my proxy got more stable, decreasing the downtime! As next, i changed the physical network by connecting the blades to the machine running the proxy using good old cheap ethernet cable instead of plugging them to the WLAN-router to connect via WLAN to my proxy. By now, i have an uptime of 4 days on my blades without any problems connecting to the proxy (my desktop) anymore  This is so weird. Have two V2 Blades that had been working fine for a couple months, then recently both seemed to stop working. All chips showing enabled but they just weren't receiving and accepting many shares (would submit some I think they were hashing at a couple hundred MH/s or so) and kept rebooting. Tried resetting and power cycling the Blades, restarting Stratum proxy, etc. with no luck. Then got on here and saw your post. My HTC Thunderbolt being connected to my home WiFi ended up being the cause (I very rarely get on my home network with it, usually just use it on the 4G network, but last night connected it to the WiFi to transfer some files). Turned WiFi on the phone back off and Blades started running and hashing away at ~10.9GH/s again. Really, really weird. These things must have really poor shielding or something. But just wanted to say thanks for posting this and wanted to post my experiences, may help others having a similar problem. |
|
|
|
Will probably check into other options as well. Not like it'd be the end of the world if I wasn't able to get the BTC in time and buy some ASICs I probably don't even need anyway though haha.  I guess I don't see the hangup, I trade with strangers on other forums all the time without asking or being asked for their ID or being uber paranoid about getting scammed. Trade with an established buyer or seller and the likelihood of getting scammed is very very small. Just my $0.02, though. |
|
|
|
It's already compiled, you don't need to load it a project and compile source code. Just go straight to the programming screen in Atmel Studio, select your programmer and the chip to be programmed like you did before, then go to the memories tab. On that screen should be able to select the .elf file on your computer to program to the chip.  |
|
|
|
Thanks for the tip, I did end up trying ckolivas 1.2.5 and it improved the HW error rate quite a bit on the one working ASIC lol. Should have flashed that version right from the get-go. Other ASIC still doesn't even seem to be recognized, though. You too? Interesting, now I'm really wondering what that does. Might be time to crack out the threading disassembler :-) Heatsink was snugged down tight and everything looked good when I had the case off. Only potential problem I can think of is one of the ASICs isn't entirely covered by the aluminum heatsink, actually a thread on the BFL forums about this. I didn't think too much of it when I first got it and opened it up since I didn't figure BFL would ship them out like this if it could cause problems, but almost wonder now if maybe that created hotspots on the ASIC or caused it to get hot enough to go belly up. Of course quieter/lower RPM fan and overclocking probably didn't help either, but for all I know it would have gone out sooner rather than later because of this even running it stock.
Mm. How tight was tight? I've been snugging the bolts down using a t8 torx bit by hand without handle or anything, pressing down on the sink and plate and snugging it down just enough to take out the slack. Finger tight, counting on the artic pad to do the work of transferring the heat. When I first took off the plate it was easy to remove with fingers on the torx bit, so I used that as the measurement of torque to snug it down. Maybe one of the chips broke a bga connection or something. Do you have air tools to try and refloat it? C It was snug but was careful about over-tightening as well. Pretty sure there's less flex to the PCB now than there was when I got it, so heatsink shouldn't be torqued down more than it was from the factory. I may have to try taking the heatsink off sometime and inspecting everything. Or may just leave well enough alone considering it's still hashing at 4GH/s or so. Hadn't thought about possibility of a bad BGA joint, I don't have a reflow station and proper tools, though, closest thing I'd have is an adjustable temp heat gun. But as mentioned I think part of the chip being exposed and not covered by the heatsink might have been what did the one ASIC in, though. Had figured it was by design, didn't even realize it was a defect until after I had already flashed it, then I had seen the thread on BFL forums about it. Too late to request an RMA since firmware has been flashed. Couldn't hurt to ask I guess but doubt they'd grant one. |
|
|
|
I recognize a lot of your story from my 7GH jalap flash with the standard 1.2.5 FW, then I tried ckolivas' 1.2.5 and all was well again. Let the case front/sides and back plate off though, as the top plate, and have the fan blowing down getting 8.25GH average at 30-31C.
Thanks for the tip, I did end up trying ckolivas 1.2.5 and it improved the HW error rate quite a bit on the one working ASIC lol. Should have flashed that version right from the get-go. Other ASIC still doesn't even seem to be recognized, though. Heatsink was snugged down tight and everything looked good when I had the case off. Only potential problem I can think of is one of the ASICs isn't entirely covered by the aluminum heatsink, actually a thread on the BFL forums about this. I didn't think too much of it when I first got it and opened it up since I didn't figure BFL would ship them out like this if it could cause problems, but almost wonder now if maybe that created hotspots on the ASIC or caused it to get hot enough to go belly up. Of course quieter/lower RPM fan and overclocking probably didn't help either, but for all I know it would have gone out sooner rather than later because of this even running it stock. |
|
|
|
It sucks if you canceled another order and waited for these boards based on the projection that they would be cheaper, but unless you were *guaranteed* that these boards would cost €470, not sure what recourse you'd really have. This is the exact reason I don't invest anything in Bitcoin/preorders/ASICs that I'm not willing to lose.
Well i am aware that i wasn't guaranteed that price, but i just trusted burnin. He was usually a man of word and he never said anything about the price going up for this boards and cryptx kept it secret until he opened his store (no idea what's the logic there). I already said that i'm ok with the loss and will try to minimize it and i will move on. I don't have a grudge against anyone. Sorry didn't mean for the post to sound like it was directed at you, was just speaking generally. And yeah burnin sounds like a pretty good guy and sounds like he's checking into the pricing to see if there's any wiggle room. Hopefully they can get it down a bit. Sounds like part of the higher cost is just higher parts cost, though. Don't know how much of it is that and how much is CryptX's markup. |
|
|
|
Pricing isn't based manufacturing costs, it's based on how much people are willing to pay. Charging the maximum the market will bear isn't greed, it's just smart business. They'd be idiots to give their product away for less than they could get out of it. What is idiotic is comments like this. You don't know how much the network hashrate grows in the coming months, and pricing your product so high the miners won't even ROI if the growth is just slightly higher than pessimistic estimates is just plain greedy - offloading the risk to miners. Besides, if every manufacturer followed your advice of not selling to "the public", you'd just get centralization of the network hashpower - the exact opposite that Bitcoin is supposed to achieve. Actually he is true. From a business point of view it's better to sell at what people are willing to pay than at manufacturing costs+small profit, but you need to find the sweet spot. Exactly. They're running a business, not a charity. I mean I can understand people's frustrations, but at the end of the day their job is to make money, not guarantee us a certain ROI or make us money. And we all know how crazy things have been with Bitcoin and ASICs. Their margins may be healthy with current pricing, but then maybe in 2-3 months they'll have to sell the boards at razor thin margins or even take a loss on them just to get rid of the remaining inventory. How much time and money did they lose on those Avalon boards that became worthless before they even shipped, for example? Very soon the amount of Bitcoins generated by these BitFury boards and price people are willing to pay for them may be exceeded by how much it cost them to purchase the chips/other components and manufacture/distribute the boards. This may all be stuff they're taking into account when you see that €699 price. You have to appreciate that they are taking a risk here as well, it's certainly not only the miners who are putting their $$$ at stake. It sucks if you canceled another order and waited for these boards based on the projection that they would be cheaper, but unless you were *guaranteed* that these boards would cost €470, not sure what recourse you'd really have. This is the exact reason I don't invest anything in Bitcoin/preorders/ASICs that I'm not willing to lose. |
|
|
|
|
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).
|
|
|
|
You know, all this complaining about the price is unnecessary. You can just vote with your BTC's. Then when he starts taking a loss because he's not selling enough, the price falls.
This, I guess I don't understand all the outrage. If the price is too high, they won't sell any and will be forced to lower it. Seriously doubt that will be the case, though, seem to be plenty of people out there who have no problem buying ASICs even with questionable ROI. And price seems to be competitive with other current and upcoming offerings. Pricing isn't based manufacturing costs, it's based on how much people are willing to pay. Charging the maximum the market will bear isn't greed, it's just smart business. They'd be idiots to give their product away for less than they could get out of it. On the bright side for those who want it cheaper, with difficulty increasing as fast as it is, probably won't have to wait long at all before it's available for €470 or even less. |
|
|
|
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. |
|
|
|
Don't know if this is typical for newer Jalapenos, but mine actually came from BFL with two chunks of the heatsink cut out over the fan and JTAG1 headers. Mine also didn't have a JTAG2 header soldered on. So didn't need to remove the heatsink to put the JTAG cable on and program the μC (of course didn't open it up and realize this until after I had already ordered a JTAG cable w/grabber kit that still hasn't arrived yet for like $10 off eBay).     Was getting ~5.8GH/s with default firmware (not sure why but was running pretty high straight from the factory, but also had what seems to be fairly high HW error rate, about 2%, so effective hash rate would actually be a bit lower). Flashed an unmodified 1.2.5 to it and now getting 8.1GH/s-8.3GH/s, depending on how many engines initialize and at what speed they initialize. Even more hardware errors now, though, looks like roughly 4%. Might be some other issue with my setup. Going to try letting it cool down for a bit here sometime and seeing if I can get it to reinitialize at a higher hash. Looks like currently it's only initialized with 13 engines on on chip 3 and 14 engines on chip 7, but they are clocked super high, 305MHz for chip 3 and 296MHz for chip 7. The #define __ASIC_FREQUENCY_ACTUAL_INDEX should be whatever the default is, 7 right? I didn't realize it would clock them that aggressively. Before I was getting about the same number of engines initializing, 13-14, and they were clocking at 190-200MHz I think (again depending on whether you were cold booting and starting up the unit after it had been running for a bit). And it looks like my Jalapeno bit the dust. RIP.  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. |
|
|
|
|
Received the V2 Blade today and got it set up and running. Hashing away at about 10.9GH/s. Thanks again Canary!
Was a bit nervous about shipping in a padded envelope, but arrived very well packed. Blade itself comes in a plain brown box with antistatic bag and foam padding, then that was inside a padded envelope, then that envelope was inside another padded envelope. Any concerns disappeared after pulling the envelope out of the mailbox and seeing how well it was packaged.
What are the two surface mount components included in a baggie with the Blade, by the way? Extra fuses I assume?
|
|
|
|
Sounds like you lucked out, got some great chips in your Jalapenos. 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. |
|
|
|
Should be sent now. Thanks! |
|
|
|
|
frostedflakes; 1; 4.0; 1GXYtZd6mfLtRnkDdwUYK5oBavgk81T2Fk
|
|
|
|
Definitely. Always a tradeoff. |
|
|
|
|
It actually did come with some nice sleeving. It was pretty stiff and hard to deal with inside the cramped Jalapeno case, though. So just cut the sleeve off, far easier to route the fan ribbon cable inside the case without it.
And yeah made a huge difference in noise, really happy with the fan. The stock one was unbearable.
|
|
|
|
Don't know if this is typical for newer Jalapenos, but mine actually came from BFL with two chunks of the heatsink cut out over the fan and JTAG1 headers. Mine also didn't have a JTAG2 header soldered on. So didn't need to remove the heatsink to put the JTAG cable on and program the μC (of course didn't open it up and realize this until after I had already ordered a JTAG cable w/grabber kit that still hasn't arrived yet for like $10 off eBay). Was getting ~5.8GH/s with default firmware (not sure why but was running pretty high straight from the factory, but also had what seems to be fairly high HW error rate, about 2%, so effective hash rate would actually be a bit lower). Flashed an unmodified 1.2.5 to it and now getting 8.1GH/s-8.3GH/s, depending on how many engines initialize and at what speed they initialize. Even more hardware errors now, though, looks like roughly 4%. Might be some other issue with my setup. Going to try letting it cool down for a bit here sometime and seeing if I can get it to reinitialize at a higher hash. Looks like currently it's only initialized with 13 engines on on chip 3 and 14 engines on chip 7, but they are clocked super high, 305MHz for chip 3 and 296MHz for chip 7. The #define __ASIC_FREQUENCY_ACTUAL_INDEX should be whatever the default is, 7 right? I didn't realize it would clock them that aggressively. Before I was getting about the same number of engines initializing, 13-14, and they were clocking at 190-200MHz I think (again depending on whether you were cold booting and starting up the unit after it had been running for a bit). |
|
|
|
|
You used zadig to install the WinUSB drivers for the Block Erupters?
|
|
|
|
|
