Why only Inaba gets a device ? Is he VIP ? Part of the "gang". Who knows but I am not buying their BS ...
7) The first buyers are indirectly a part of the scam. They are honest people who are going to say to others :"Hey, this thing WORKS! It's awesome, blablabla". The feedback is almost garanteed to be positive. I've re-read myself, and maybe I wasn't clear enough. I don't accuse Inaba into that scam. I really believe he received his box and that his feedback is genuine. It's only that the first buyers, getting their awesome product, will certainly leave good feedback. If I bought that product, and received those specs at that price, I would certainly act that way too. And that's the point, for the scam to work, it needs to be "approved" first by people with a good reputation. But those first buyers aren't doing this to scam, they are only honest with their impressions and, sadly, it serves the purpose of the scam. What you are describing is known as a 'long con', the idea of which been brought up here before. Yeah, but it's the first time I'm reading this topic and it's 72 pages long  Anyway, that was my last intervention on that topic. I just wanted to write my theory because, if I was a con man and in the shoes of the Butterflylabs CEO, that's exactly what I would do. The potential revenue for this scam is huge, and my greed could use a part of it. Why actually develop a working product (you agree that it's a working product, right?) and ship a few and then run and be pursued by the FBI (it would be mail fraud etc.), when you just can ship more and more products, derive a modest profit from them and smile all the way to the bank? No, I really don't think they have the intent to defraud. However, that said, lots of things can happen, for instance, they place a big order in China, to catch up with the order backlog and in anticipation of future orders (now that the favorable reviews are in), pay for them with retail customers' funds, in the meantime the BTC exchange rate crashes and/or MtGox suddenly ceases operation just like TradeHill, whereupon a vast majority of customers cancel their orders and demand a refund, which they are now unable to provide because the money has been wired to China... One of the top 10 reasons why small businesses fail is actually a scenario where the small business gets overwhelmed with demand, fails to manage cash flow and production schedules diligently, and then gets buried once lots of customers demand their money back. I'm not saying that it WILL happen that way. I'm just saying it MIGHT happen that way. |
|
|
|
The KC705 board is now available (well, at least advertised on the Xilinx webpage) and costs $1700.
Thank you for pointing this out. I'm glad I didn't pull the trigger on a ML605 purchase last year. I'll get a KC705 as soon as Avnet shows them as available. Not for the mining though, for fault simulation and mixed-signals experiments. By the way, AVNET has its one-day X-FEST (X stands for Xilinx) again this spring (in San Jose on April 26th, check the website for other cities) and typically they offer Xilinx dev boards to attendants at a substantial discount. So, maybe I can pick up a KC705 board for, say, $1400 or so. |
|
|
|
So you got 3 rings going on in one LX150, right? Any idea what's the smallest (cheapest?) device one could fit a single ring? And 2? Maybe with your approach we can get a better bang for the buck somewhere else, or at least easier sourcing of FPGAs  Stefan of ZTEX fits one ring (65 rounds) into a Spartan6-75. If eldentyrell fits 3 rings into a Spartan6-150, it's not inconceivable that one could fit two rings into a Spartan6-100. I think the main problem of implementing only one ring is, that the result coming out of the SHA-256 operation has to be fed back into the other side, and long interconnects on FPGAs are notoriously slow. Thus, your clock rate suffers, which is probably what eldentyrell is experiencing. Still, Stefan achieves about 180 or 184 MHz on the Spartan6-75 http://www.ztex.de/btcminer/ and I'm dying to learn what clock rate eldentyrell is getting. |
|
|
|
If anyone with one or more paid units for the first batch wants to trade his pre-order position for a few bitcoins (10-15, negotiable), feel free to send me a PM Three problems with this proposal: 1. People typically don't know which batch they're in 2. Allegedly, as soon as the first batch ships, the price for new orders will rise by $100, which is more than your offer 3. BFL would need to agree to the position trading, which is far from certain 1. So my offer is valid for anyone with a confirmed first batch unit  2. Hmm. 3. Wouldn't it be up to the buyer to decide where to ship it to? (ie. if I pay the original buyer then all that would change would be the shipping address, and of course some Bitcoins would change hands outside of BFL) I take it from your reply that you are not willing to trade your pre-order position for a few Bitcoins, are you? Not for this price. I ordered my first one 5 weeks ago, the other ones somewhat later, and ASSUMING that I'm in the first batch, which I have no evidence of, you can acquire it for $799 + $10 shipping via private buy-it-now auction on eBay, once I have received it. Edit: Actually my memory is not that great as to the precise time I ordered it, but I am positive that it was 4 to 6 weeks ago. |
|
|
|
Are you familiar with the term "SerDes"?
Yes, as in "device that iS not suitablE for sending 64 bits to an addeR anD rEceiving 32 bitS back, all within 1 or 2 ns total" - SERDES. You'd be shooting for 100 Gbit/s SerDes units - possible in ASICs now (if expensive), not yet available in FPGAs. Furthermore, FPGAs typically have only about half a dozen or a dozen or maybe two dozens of SerDes units - not 875. |
|
|
|
If anyone with one or more paid units for the first batch wants to trade his pre-order position for a few bitcoins (10-15, negotiable), feel free to send me a PM Three problems with this proposal: 1. People typically don't know which batch they're in 2. Allegedly, as soon as the first batch ships, the price for new orders will rise by $100, which is more than your offer 3. BFL would need to agree to the position trading, which is far from certain |
|
|
|
wondermine, I wish you the best. I really do. However, please take a look at the SHA-256 algorithm. http://en.wikipedia.org/wiki/Sha-256The 32 bit values b, c, d, f, g, and h are trivially derived from the previous round, i.e. copied from a, b, c, e, f, and g, respectively. The 32 bit value e is derived from the previous round's d, h, e, f, and g (i.e. 5/8th of the previous round's 256 bits are used to derive it). The 32 bit value a is derived from the previous round's h, e, f, g, a, b, and c - i.e. 7/8th of the previous round's 256 bits are used to derive it. Now think this through over just one more round. Only four 32 bit values are trivially derived from their "grandfather" round. The other four 32 bit values are derived from brutal mixing of almost all bits of the grandfather round. And so on. After just 4 rounds, a single bit change in the great-great-grandfather round influences ALL bits of the current round. Thus, any notion of shaving more than 4 or 5 rounds off the 128 total rounds is a pipe dream. In other words, speeding up an implementation of SHA-256 cannot be done by mathematical tricks. Rather, the operations of each round should be optimized. There is no real reason why the clock is a measly 200 MHz (and thus the clock cycle 5 ns) in the best currently available implementations, such as the ZTEX implementation. Think about it: 5 ns, that is a delay straight from the 70s. A TTL technology-like delay. Certainly we can do better than that?!? Analyzing the operations for their contribution to the delay yields: rightrotate ... instant, no delay at all xor ... minor delay, bit by bit, probably a few dozen picoseconds and ... minor delay, bit by bit, probably a few dozen picoseconds not ... minor delay, bit by bit, probably a few dozen picoseconds + ... this should be scrutinized. A 32 bit add operation can be quite costly and the fastest possible implementation should be pursued. Adding insult to injury, SHA-256 features not just binary or ternary adds, but 4-fold adds (in the t1 function) and 5-fold adds (e := d+t1) and 6-fold adds (a := t1 + t2). So, there you go. The biggest detriment to performance is probably the 6-fold 32 bit wide add in a := t1 + t2. If you can speed this operation up, maybe by pre-computing partial results in the PREVIOUS round, then bringing them to the table when needed, the entire SHA-256 will be sped up (assuming optimal placing and routing). I'm very familiar with the SHA-256 algorithm and understand its complexity. And I don't mean from reading Wikipedia. What you fail to capture here is that I'm not looking at this to know exact values to avoid... it's a matter of probability. Why does SHA-256 use 64 opaque rounds? Precisely so something like this does not happen. It might be a waste of time and resources if checking a value wasn't so resource-friendly, but it's not. As far as "more standard" optimizations, I already mentioned I would do that. And I know adding is the biggest resource hog here. I'm looking into the best ways to do that, precalculation, DSP chips on custom boards (to offload logic that does not require programming and other benefits)... I may be a student but I'm not exactly lacking in mathematical or engineering understanding. The 200MHz issue... Actually there is a reason we're down in the "70s" range of timing. Optimizing for high clockability is a huge challenge. It is a problem, also something I'm already looking into. I'm looking into quad-pumping and other technologies that major manufacturers use. I'm going to take it from your knowledge of some of this that you understand how hard it is to come by clean clocking, and then making sure that doesn't become unstable. Have you looked at commercial IP for SHA or other block ciphers? They don't run much higher than 200MHz stably, and they cost thousands of dollars and have had many engineers optimize the hell out of them. So all that to say, yes I know what routes of action to take. I also won't say I'm looking into something unless I believe it's feasible and have done adequate research. >to offload logic You can't offload logic. Not enough IO pins on an FPGA. There are seven additions per round, 125 rounds - do you want to connect 875 external adders? These 875 external adders would need 96 pins (64 inputs, 32 outputs) connected to the FPGA each, for a grand total of 84,000 pins... |
|
|
|
|
He may be interested in writing his own Verilog code, and with the LX150 device he'd have to BUY the toolchain, as the LX150 is not supported by the free toolchain. But I recommend buying at least the LX75 device. Module 1.15b. It can be used for mining AND for trying out new code variants. Maybe I'll buy a 1.15b myself. The discussion with wondermine in a different thread gave me some ideas on how to speed up the "add" operations.
|
|
|
|
I too had similar "countdown to death" experiences yesterday with a new 1.15x and d3a and d2, only d1 worked. I have also changed the pool yesterday just to make sure it wasn't a problem with the pool, but same result.
Surprisingly, today the d3a worked without problem. I have not changed anything else, heat sink still the same, same power supply, same parameters etc.
d2, d3 and d3a firmwares are marked as experimental because they may not work. But I think I found the problem: it was an undocumented requirement in the DCM re-programming sequence. Did you see application note 879? Quote: In short, the operations that must be implemented to reconfigure one value in the PLL are: • Assert RST to the PLL (do not de-assert) • Set DADDR on the PLL and assert DEN for one clock cycle • Wait for the DRDY signal to assert from the PLL • Perform a bitwise AND between the DO port and the MASK (DI = DO and MASK) • Perform a bitwise OR between the DI signal and the BITSET (DI = DI or BITSET) • Assert DEN and DWE on the PLL for one clock cycle • Wait for the DRDY signal to assert from the PLL • De-assert RST to the PLL • Wait for PLL to lock |
|
|
|
No problem, it wasn't the most brilliant question.
Anyways, here are the stats we have cooking, no screenshots yet, this project is requiring more math than I might have liked. One of the ways I'm optimizing the mining is checking late-round values against (to be determined, but known) constants to determine whether or not they will (or are likely to) yield a win. If not, the SHA algorithm aborts early, saving resources. It's gonna be a lot of work, and that's a big way of how we will be shrinking approximately 60 MH/s (number based on more recent data) onto a Cyclone IV Nano. The work begins today.
SHA-2 hashes are unpredictable at 128 rounds, or 64 rounds, but if we have access to the data all the way through, and know what our starting and end data should look like, we can side-channel it. I'm speaking to our school's cryptanalysis expert.
The above may sound like heresy but block ciphers are weakened by attacking their implementation, and we have full access to this one. I'm going to keep working, on all fronts of optimization.
Donation-wise, there have been about 45 BTC and $50 USD/CAD donated, allowing me to buy a couple of DE0 Nanos from our friends at Terasic and paying for a bit of the countless hours I've been pouring into learning all of this. Hopefully that's something you're all happy with.
wondermine, I wish you the best. I really do. However, please take a look at the SHA-256 algorithm. http://en.wikipedia.org/wiki/Sha-256The 32 bit values b, c, d, f, g, and h are trivially derived from the previous round, i.e. copied from a, b, c, e, f, and g, respectively. The 32 bit value e is derived from the previous round's d, h, e, f, and g (i.e. 5/8th of the previous round's 256 bits are used to derive it). The 32 bit value a is derived from the previous round's h, e, f, g, a, b, and c - i.e. 7/8th of the previous round's 256 bits are used to derive it. Now think this through over just one more round. Only four 32 bit values are trivially derived from their "grandfather" round. The other four 32 bit values are derived from brutal mixing of almost all bits of the grandfather round. And so on. After just 4 rounds, a single bit change in the great-great-grandfather round influences ALL bits of the current round. Thus, any notion of shaving more than 4 or 5 rounds off the 128 total rounds is a pipe dream. In other words, speeding up an implementation of SHA-256 cannot be done by mathematical tricks. Rather, the operations of each round should be optimized. There is no real reason why the clock is a measly 200 MHz (and thus the clock cycle 5 ns) in the best currently available implementations, such as the ZTEX implementation. Think about it: 5 ns, that is a delay straight from the 70s. A TTL technology-like delay. Certainly we can do better than that?!? Analyzing the operations for their contribution to the delay yields: rightrotate ... instant, no delay at all xor ... minor delay, bit by bit, probably a few dozen picoseconds and ... minor delay, bit by bit, probably a few dozen picoseconds not ... minor delay, bit by bit, probably a few dozen picoseconds + ... this should be scrutinized. A 32 bit add operation can be quite costly and the fastest possible implementation should be pursued. Adding insult to injury, SHA-256 features not just binary or ternary adds, but 4-fold adds (in the t1 function) and 5-fold adds (e := d+t1) and 6-fold adds (a := t1 + t2). So, there you go. The biggest detriment to performance is probably the 6-fold 32 bit wide add in a := t1 + t2. If you can speed this operation up, maybe by pre-computing partial results in the PREVIOUS round, then bringing them to the table when needed, the entire SHA-256 will be sped up (assuming optimal placing and routing). |
|
|
|
(with more side holes) (yes that's a question  ) Many years ago I designed a 1U rack-mount enclosure for six miniITX motherboards. One of my business ideas that didn't pan out, but that's a different story. The enclosures had vent holes in the front bezel and rear bezel, and, for good measure, lots of vent holes in the side panels also. Guess what? The holes in the side panels created an easier path for the air, so the cool air did not go all the way from the front to the rear (in a data center, the aisle where all the front panels are is the "cool aisle" and the aisle where all the rear panels are is the "hot aisle"), but instead the air took a shortcut. The motherboards got really hot. Not good. So, I duct-taped the holes in the side panels shut. Result: Much better cooling performance, as the air was now forced to go from the front to the very rear. In a nutshell: More air holes do not necessarily translate to better cooling performance - sometimes the opposite is true. |
|
|
|
hahaha.. i thought of doing that renting some space at an executive office building.. only concern i have is that they tend to turn the AC off on the weekends  Actually, an office AC can only get rid of maybe 1000 W without the room getting uncomfortably hot - in the old office there were two window panes that opened (left and right) and I had all 4 mining rigs on the left and 4 on the right and had cardboard ducts with fans to blow the hot air right out for the windows. And still the room was like a sauna. In my current office, unfortunately the window does not open at all, and I have only 3 rigs in operation, four HD 5830 each, and once again it is like a sauna and I always take my shirt off when I'm there. So, now you know why I'm increasingly interested in FPGA mining.  |
|
|
|
If yall are in south florida PM me I have a location that I let miners put their machines. I charge 1BTC for every 10BTC your miner generates. Currently I am at 7.6GHash and I have two clients (Friends, lol) that are at 1GHash each. If I get enough people to mine at the location might do a local pool. I would like as much input about this as possible.
This may be a very good deal for miners with power-hogging graphics cards, such as the HD 6990, but not a good deal at all for FPGA miners. |
|
|
|
like what gh level?
Like i am putting my first dedicated rig together.. aiming for 2.4gh..
need a bit more funding to put get more 5970s
You are a respectable miner if you have already tripped circuit breakers and/or contributed to global warming and/or got kicked out of your "mining office" by your commercial landlord. The latter happened to me half a year ago. 3 day notice to vacate for breach of lease terms. "The owner has seen the electrical bill of the entire office building DOUBLE, and he wants you out." "Consider this your 3 day notice." I had four mining rigs plugged into the 20 amp circuit of the left wall, and four mining rigs plugged into the 20 amp circuit of the right wall, drawing close to 40 amps total. Once I tried to print a document on the laser printer - when the laser printer heated up its toner filament, it caused the circuit breaker to trip. Good times. |
|
|
|
I need help cooling my 6870s They are running in the upper high 70 degrees (77-80s C) This is an open case rig with CM Storm Trooper. Also keep in mind that this is COLD air being blown into the cards from outside ... I don't know why they're still hot. Autofan with CGMiner 85% fan speed Here are some pics:    I have two 12cm 110cfm Coolermaster fans in front of them. The fans are held in place with cable ties. The fans are on top of each other - the bottom fan cools the two graphics cards at the bottom and the top fan cools the two graphics cards at the bottom. Works for me. But don't waste your time with 70cfm fans or something puny like that. Make sure they have in excess of 100cfm, each. |
|
|
|
Stay away from Kingwin and Rosewill. Buy Cooler Master, Corsair, Seasonic, Enermax, Sparkle, or PC Power & Cooling. |
|
|
|
I have a 1000W Rosewill Bronze Cert PSU running:
5870
5970
Phenom II X4 830
Asus Crosshair IV Extreme
SSD
Is that enough juice to power all these or is my PSU dying?
after a day of mining it just completely shut down and I have to hold down power button to restart it.
Rosewill is junk. A so-called 1000W Rosewill power supply *cannot* provide 1000W, not even close. Do yourself a favor and get yourself a 750W or an 850W Corsair power supply, these are typically $99 and $119, respectively, if you shop around a little bit. Make sure you get a power supply with a SINGLE +12V rail. There are 4-rail or even 6-rail power supplies out there, where each rail is so weak that you will run into problems (hello, Antec!). I've been burned by multi-rail power supplies before and will never again buy a multi-rail power supply. |
|
|
|
No problem over here. I run a 4 board and a 2 board cluster.
Thanks. Are you running the d3 firmware? I think you mentioned that you were having some frequency issues until you tried the dumbbells?! Yes d3a, had some issues with that board yesterday and today. Downclock of death two times. Placed some weight on the heatsink. BTW the board is a 1.15d not 1.15x. I own 4 x and 2 d boards. The 1.15d have a smaller heatsink and are more difficult to cool. Now that mention it (downclock of death ), a few days ago I my DSL modem hung and I switched DSL modems, whereupon there were ARP cache issues causing me to reboot the Windows 7 laptop as well - in a nutshell, when, after finally being online again, I tried to restart the mining software for the ZTEX board, I once again experienced the "downclock of death". With the d3a bitstream, no kidding. I then flashed the original (December) bitstream into it, but that also went into a "downclock of death" situation. Then, I flashed the d3a bitstream again and, lo and behold, this time it worked. In other words: This PLL stuff is not 100% stable, but on the other hand there is a good chance it eventually will work, given a few tries. >dumbbells I think, Xilinx specifies a maximum weight somewhere, and if I were you, I'd make sure not to exceed that. |
|
|
|
I have received my first FPGA Board and I am running ZtexBTCMiner-120130 with D3 on Windows 7. I get stable 210.00 MHz. The Java.exe process is using 50% CPU during mining (not yet during FPGA configuration). Is this normal? I am starting it in a command.com prompt as administrator in case that matters. java -cp ZtexBTCMiner-120130.jar BTCMiner -host "http://api2.bitcoin.cz:8332" \
-u user -p password -f ztex_ufm1_15d3.ihx -v -l 120130-d3-slush.log
I have one ZTEX module 1.15x and it's running the d3a bitstream. The Windows 7 laptop it is attached to shows all 4 cores idle. The clock frequency of the module 1.15x with a shitty $2.79 VGA cooler in a hot office (on account of twelve 5830s mining along happily and on account of the fact that the office window doesn't open) is 208 MHz. I can't complain. |
|
|
|
Well, 7.5A/core was ok for a 192-205MHz 122-round 2-stage-per-round pipeline design. Just my later designs needed more power.
So, are you alluding to SUCCESSFUL designs that went beyond 205 MHz and thus used more power, or to UNsuccessful designs that somehow wound up using more power? If the former, that would be big news on this forum, considering the fact that right now I'm mining at a mere 208 MHz on a ZTEX board (with a shitty $2.79 fan cooler from China, though, not ZTEX's luxury cooler). |
|
|
|
|
Show Posts
