|
I'm pretty sure that Mr. etotheipi is well meaning, but he is also very young and inexperienced. His advice about "attack surface" is generally right, but it just betrays his lack of experience.
1) Those who remember the old product called Laplink and its special "serial and parallel on both ends" cable will probably also remember the trivial procedure used to transfer Laplink from one machine to the other through that cable. Once you had Laplink on both machines you had access to all files on both machines.
2) Ten years old laptop computers frequently have IrDA (or other infrared) port. There wasn't many commercial products using those ports, but it was heavenly invention for hackers. Clever person could gain access to the other person's computer while siting right in front of him around the conference table during negotiations.
3) The biggest attack surface on 10 years old computers in not from hackers, but from your good old friend Murphy. If you plan on following his advice to store your valuable bitcoins on an old PC please buy at least 2 or 3 identical copies to have spare parts in case of inevitable component failure. Also make sure that either you know how to swap those parts or have a trusted person who could help you with that task.
This is pretty much close to a security theater performance art.
The constructive advice I could give is:
1) use modern computers, just learn how to boot them off the external drive or how to swap internal drives.
2) when storing on the hard drives learn about SmartMonTools (or other S.M.A.R.T. toolset), how to use them and how to interpret the results.
3) DVD-RAM is the only consumer-grade removable media technology with any track record of long-term reliability.
4) USB flash drives are to be trusted only if you also have access to the test and configuration application that is specific to the particular controller used in your flash device.
Thank you for reading.
|
|
|
|
Can I safely connect 4 of them to a 16A circuit?
Safely? Yes. The worst that would happen will be a circuit breaker trip during a prolonged brownout. Or if you have a brief outage then the breaker will trip right after the power is restored because of the startup surge current. If your measurement device has a "MAX" function for the "A" values you can measure the startup surge current on your own. You could also simply try it Additionally you could try to borrow a variac/autotransformer from some nearby electrical shop and test a single power supply simulating the brownout by adjusting the variac. On the other hand, if you live in a locale where brownouts are a rarity then just don't worry about them. |
|
|
|
Your design only is considered unsafe when you exceed ATX specification.
I'm sorry I wasn't specific enough. I'm pretty sure nobody is testing every power supply comming off the assembly line for the ATX conformance. Only a statistical sampling is done on the already-certified products. However every power supply has to be tested for the UL,CE and other local electrical product safety specifications. The full UL (and equivalent) tests are destructive. Therefore only specific non-destructive subset of the tests is run, which must include verification of certain nominal parameters. The only results allowed are PASS and FAIL; grading isn't done and is not allowed. I apologise for derailing this thread with my imprecise answers. |
|
|
|
I was thinking if the power supply doesn't meet internal product qualification targets, like <3% ripple or efficiency numbers or what have you. Not electrical code violations.
Me neither. As far as I know any discrepancy from the approved design targets must be considered a potential failure. For example: ripple too high -> capacitors already faulty or with shortened expected lifespan. This is one of the first rules of safety engineering. Basically if any component or assembly procedure can be shown to be out of specification the whole device is considered faulty and potentially dangerous. The above is a theory and the broad market practice. There may be other practices applied in the extreme low-end and extreme high-end. For example ultra-high-end handmade audio equipment is sometimes bin-sorted. At the ultra low-end side anything goes. |
|
|
|
My guess is that the 850W is a 1000W that has been relabeled and maybe didn't pass some quality testing criterion at 1000W.
I never heard of anyone bin-sorting power devices. If it fails QA then it cannot be sold, period. Some countries have the electrical code demanding the worst-case labeling for the devices that exhibit negative dynamic impedance. For the usual case of positive dynamic impedance the device draws more current if the input voltage rises and vice-versa draws less current if the input voltage sags. In the case of an internally compensating device that exhibits negative dynamic impedance it will draw less current if the input voltage rises and more current if the input voltage sags. I know that old German industrial regulations (DIN) demanded such a labeling. And the input voltage ranges for testing were asymmetric, something like -20%/+10% or -25%/+12%. I remember reading that those regulations were scheduled to be obsoleted by the pan-European regulations, but the consultants advised us to follow the older regulations to assure speedy regulatory approvals. Edit: I just wanted to add that I wasn't talking about "regular electrical code". I was talking about "special electrical code for health care facilities". |
|
|
|
So how do you explain that the 850W power supply with 88%+ efficiency at full load says 5.5A on the box with 240V?
Please read up about power factor and the difference between watts (W) and volt-amperes (VA). http://en.wikipedia.org/wiki/Power_factor |
|
|
|
Those two quotes from your recent posts are mutually contradictory. Packet loss is ALWAYS handled on miner's side - if no reply received, request is re-tried with some delay,
with exponential backoff.
Bitcoind / pool NEVER retransmits packets on its own.
There no such flaw if you look carefully on protocol.
Server CAN respond with msg_opcode == 12 (work is invalidated)
BEFORE Miner sent his work.
I understand that you are trying to reinvent the whell like ZeroMQ or DCOM; but specialized for Bitcoin mining. Based on my previous discussions here I'm more or less convinced that you are going to either fail or rediscover why 0MQ or DCOM are seemingly too complex and in the process reimplement most of it. I had a long and productive discussion with Mr. slush here regarding more general protocol, but with the same requirement of two-way asynchronous messaging. I'm not going to reiterate my points here, just give a link: https://bitcointalk.org/index.php?topic=55842.0Thank you for your undestanding. |
|
|
|
|
Sorry Mr. V, but your design has a serious flaw. There isn't an equivalent of the existing long-poll. The miner has to be able to register itself with the mining pool to receive notification about the need to abandon the current work because new block had been found.
Therefore any strict master-slave, request-response, pool-server-always passive protocol will end up beeing inefficient.
Full two-way communication is essential for any effective design.
|
|
|
|
Right, but I'm still not sure from that description where the bottleneck is - like I said, there are always ways to speed anything up, even if the speed difference isn't a lot. For instance, if the CPU doesn't actually relate to how long such a design placement takes, you could save money there and spend it somewhere else - for instance, on a 24-drive SSD array.  My best guess for the bottleneck in compiling small designs into large FPGAs is in decrypting the floorplan files. Xilinx ISE has separate files for each chip in each package. All this information is a trade secret and serious effort was spent to encrypt and obfuscate it. So my guess for the best Xilinx FPGA design workstation would be the fastest server-grade CPU with a huge cache and lowest-latency RAM. Number of cores is immaterial as most of the workflow is single-threaded. |
|
|
|
If not, what combination of components relate to the speed loss? It seems to me that they way to speed it up would be to use a very fast processor, very fast RAM, and lots of RAM - more than 64GB to start with.
I'm sorry I probably wasn't clear enough. The classic programming language compiler has the CPU architecture stored in the back end and it is always the same no matter whether you compile short or long program: in the end the RAM is linear. The HDL programming language compiler also has to have the FPGA architecture stored in the back end. But unlike RAM the FPGA is not linear, it isn't even rectangular. Remember reading the complaints of eldentyrell and bitfury that the LX-150 has some things missing in the middle of the chip where it has the global clock buffer? Well the back-end of the design compiler (place and route) has to read in the detailed chip resource layout: SLICEs, BRAMs, DSPs (all those are explicitly documented) as well as undocumented switches and routing resources. Not only it has to read in all that data, in the place and route stage it has to explicitly fit the design into the floorplan. Even if the toolchain is all running from SSD disk it will still have to do those tasks. And those tasks aren't linear, the slowdown from LX9 to LX150 will not be 150/9, it will be noticeably more. |
|
|
|
I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?
The language choice doesn't really matter. This project is so simple conceptually that the normal reasons for chosing the language are immaterial. This project stresses later stages of the design flow. Your experience with classical sequential programming languages is probably even counterproductive. What really helps is understanding the basics of logic design: combinatorial and sequential logic, flip-flops, etc. as well as any previous experience with declarative or parallel programming languages. Most of the time you will spend researching various ways of transforming your program to convince the toolchain to accept your idea of how the design should be laid out. If you use Xilinx ISE as your toolchain then be aware of the following: 1) dense LX150 design will require more than 4GB of RAM during the later stages of the workflow, make sure that your machine has at least 8GB and the OS is 64-bit. 2) Xilinx changed the toolchain front-ends (both for Verilog & VHDL) with their "-6" FPGA families. When using tutorials prepared around older Xilinx FPGA families you may experience problems related to the corner-case differences in the HDL implementations. 3) even very small designs on a large chip take comparatively long time to compile. By the time the toolchain reads the floorplan and pinout of the LX150 chip the whole workflow on the LX9 chip will be done. Therefore for the beginners I recommend obtaining $98 Avnet Spartan-6 LX9 kit. If you start with a full LX150 design, especially the unrolled one, you will experience annoyingly long workflow iteration times, in the order of hour or two. FPGA design is like playing tetris, chess and contract bridge all on the same board that is rectangular, not square. |
|
|
|
I'm just going to quote this for posterity, since this board software allows editing of posts long after the original poster had calmed down. I'm not entirely certain that this can be clearly proven given what's on the table. BFL provided statements that they were experts in this area with a history of delivery. The bona fides were lightweight in terms of evidence, but argue against significant ignorance. While I don't expect you to take my word for it, please check around with other FPGA and IC developers and ask them how a Bitcoin application compares to basically every other FPGA application in terms of chip utilization. The unusual requirements of mining compared to basically all other applications of FPGAs impose unusual requirements that a typical designer would not factor in without prior knowledge of the situation. I don't know you. You seem intelligent but a little too emotional on this particular issue. This could be because you believe in the longer-term goals of BFL and are offended at what amounts to pure BS on the part of many of its detractors. I understand this, but it's the Internet. Use the Ignore link with great prejudice. I do, and it helps my outlook significantly. I'm sorry you feel that way and that some how my deconstruction of your arguments are somehow "emotional." I have no personal stake in BFL, but I to take umbrage to the fact that people spout all sorts of misinformation and outright lies (not saying that's the case here, I'm referring to another thread) and I would defend the subject with the same "emotion" you are attributing here. I'm highly opposed to bullshit and armchair lawyers, yes it's true. Conveniently, given my geography, I have a lot of friends and acquaintances in the FPGA and IC spaces at companies such as Intel and Cadence. I recognize the debating technique of trying to find an area where your "opponent" is soft, but I am neither your opponent in this discussion, nor am I weak in the area. Your pattern of "x is entirely unlike every other y" is not helping you in this debate, as I well recall the early days of SSL and other crypto and hashing accelerators. I remember having to pay $10k per Big IP just to offload SSL (which is, as a streaming protocol, a slightly different beast) for a handful of servers. What debate? You haven't offered any contrary position beyond your initial statement. It's not really a debate. You stated that BFL made statements with regards to their expertise in a given area, yet fell well short of delivering. I gave you a reason as to why that was the case. That's not exactly a debate, which is why I invited you to check with someone OTHER than myself, since you believe I am biased (which is fine). Given that fact, it's not unsurprising that even experienced designers would be surprised and appalled by the requirements of a bitcoin miner. Throwing in a little bit of veritable conjecture: I suspect this is exactly what happened to LargeCoin when they realized that their initial ASIC designs were not going to meet their targets, as they were designed with traditional simulations and not mining simulations. Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.
The claim would be reasonable had it not been so easy for smaller shops (ngzhang, ztex, etc.) to deliver FPGA-based solutions in a timely fashion. The programming is obviously accessible to a reasonable practitioner in the craft, given the number of byte streams that have been produced that push the LX150. What does the programming have to do with it? The bitstream has never been a bone of contention as far as I know (someone correct me if I'm wrong) - the only bone of contention has been the power usage (which directly correlates to the hashrate as related to heat). I'm sure none of the engineers you have listed would argue that the chips BFL uses are incapable of producing a 1 GH run for brief periods, as described by "normal" FPGA applications. The breakdown occurs when you try to mine at upwards of a 50% switching rate, instead of the industry norm of 12%... suddenly those 1.2 GH/s chips start to overheat and fail at 50%, whereas they can run all day for years at 12%. Any FPGA designer coming into that territory and being unfamiliar with bitcoin, yet familiar with industry standards would conceivably make that mistake. I am not making excuses for BFL or their failure to deliver. I am simply pointing out why your argument is flawed. I am sorry if that offends you or somehow puts you on edge, but the facts are facts. BFL could have easily delivered a comparable product to Ztex, nghzhang, et al, since their hashrates are so far removed from what BFL was offering, even AFTER the reduction... but the fact that they were offering a product that, after refactoring, was 4x the speed for 1/2 the cost should afford them quite a bit of leeway when it comes to the very first product delivered. Using the other products as examples is disingenuous at best, since they are fall so very short in terms of performance and price. The FPGA-to-ASIC process is capital intensive but not difficult. It's a very well-worn path. We have tools such as Verilog and friends. We can prototype on the FPGA, validate with various circuit validation tools (OK, these are _all_ buggy), simulate (slowly) on our beefy workstations, and have a reasonable shot at a successful IC, especially one as simple as a BTC ASIC. This isn't a Pentium 60, where you're going to run into corner cases with FDIV. The rest is glue and IO, and the smart move is to leave the ASIC as dumb as possible and leverage existing tech for this. I don't disagree with this... but I'm not sure what is has to do with anything or how it's relevant to your previous statements. If you could clarify? |
|
|
|
|
I have one comment related to your choice of CPUs.
It seems like you have a wide power margin in your power budget, in fact so wide that you are thinking of plainly burning this power to increase the resistance to DPA & DFA (Differential Power Analysis & Differential Fault Analysis).
I propose that you could burn that power in a more usefull way. If you choose a CPU that supports SIMD instructions you can greatly increase the resistance to those side-channel attacks. I'm aware of AVR32 controllers with SIMD extensions (apparently mature/obsoleted) as well as versions of ARM processors with NEON extensions.
The basic attack defense mode is to use a 4-way SIMD streams to simultaneously compute:
1) two copies of the desired cryptographic result
2) two copies of a benchmark cryptographic problem with a known result
The benchmark problem is randomly selected from a library of known solutions, and the allocation of the problems to the vector registers is also made randomly.
The papers I remember seeing about the above techniques were concerned with symmetric crypto as well as RSA assymetric crypto. I would presume that the results carry over to the elliptic assymetric crypto.
If the ARMs with NEON are too expensive or otherwise unsuitable the techniques are still valid when used in a plain CPU. In that case care must be taken to prevent the compilers from optimizing and reordering the instruction streams bythe use of the appropriate "__builtin" functions (in GCC).
|
|
|
|
As far as I know, ngzhang has not provided an ncd file.
Please double check. I currently have no access to my main computer, but I do distincly remember that he provided the design in an relatively easily editable form. The main hashing pipelines were created using Synopsys and the placed&routed netlist from that step was fed to the Xilinx ISE as a black box to be sorrounded by the glue/interface logic. The only reason that I couldn't play with it was that my main machine couldn't be upgraded with enough RAM to get sensible speed in the toolchain. |
|
|
|
I fear that you will find out that synthesizing a bitstream for the Spartan6-150 is not as easy as some people think it is.
I somehow got an impression that the fault is just a swap of RxD/TxD lines. This should be doable with "fpgaeditor" on the ".ncd" file. But I may be wrong. |
|
|
|
Please send me only the overachiever type personality boards pls. Thnks.
And send the underachiever ones to the boarding school with military regimen, it has been shown that they improve the expected achievement. |
|
|
|
Also hole in center - but I cannot fit there round exactly as below - lacking 2 slices and it is difficult to make workaround for that,
I have one more question/suggestion. I understand that you're using LUT-RAM to store the the FIPS-180-x constants. I also guess that each hashing cell in your design has a dedicated private copy of that ROM. Have you tried pairing (or quad-ing) the neighboring cells to share a single ROM storage? If the cell clocks are in sync the neighbors could share those without paying to much cost in switch/route overhead. I'm just asking, I'm not trying to question your skills or anything like that. I'm not involved in Bitcoin mining and I read this board for intellectual stimulation only. |
|
|
|
Since this refers to my message that wasn't clear: Xilinx bitstream format WAS at one time available to Xilinx EDA software partners, possibly under NDA, possibly under some different sort of legal and financial protection. I no longer consult for that EDA vendor and I have no relevant knowledge regarding current products. I only remain friends with people who continue to maintain and upgrade the EDA software applications that I co-authored years ago. |
|
|
|
You have all the clues... Turn on your head and just guess using data you have - print screen from PlanAhead - I certify that it is correct one... Try placing some BRAM and watch your timings... Why would you ask then ?
I'm asking because I'm not fully up-to-speed on possible space-time tradeoffs on the current Xilinx platforms. When I worked on them professionally we had the information about the routing and bitstream format available directly from Xilinx (maybe under NDA, I'm not sure, it was years ago). I've also remember the comments from a poster who implemented the bitcoin hashers on Virtex-6 and quick-and-dirty solution was to use DSP48s for some fraction of the adders in SHA-256 mixing steps. In theory at least it should be possible to fill every BRAM with multiple copies of the constants and use those constants at least in those hashing cells that are close to the BRAMs. As far as I understand your design you currently have just one class/macro of hashing cell, but have plans on implementing another class/macro to fill out the space that currently remains unused. Overall, I'll venture to guess that the ultimate Spartan-6 bitstream will use the sea-of-hashers concept and the hashers will be a heterogenous mixture: close-to-DSP48, close-to-BRAM and far-from-DSP-and-BRAM. I occasionally talk to my friends who do digital design and they always mention "don't leave any FPGA resource unused, even at the expense of partially mangling the original algorithm". I guess the ultimate way to express all the above is that the design space tradeoffs are multidimensional space of clock-freq*number-of-gates*time-to-market. |
|
|
|
This is most likely due to the Spartan6's awful long distance routing fabric,
This isn't Spartan's fault. This is a property of any modern FPGA: most of the delay and energy loss occurs in the routing fabric. So the easiest way to speed up the design is to minimize the demand on routing resources. I was always perplexed why everyone here was focusing on unrolling the combinatorial logic. After gaining some experience with the currently available EDA tool suites for FPGA it became obvious: they make the place and route of repetitive designs very difficult. The "sea of tight hashers" approach will probably be also beneficial for the future ASIC designs, although not by such a wide margin. Does anyone know if bitfury's design stores the SHA-256 constants in BRAMs or has them spread over through the SLICEs? |
|
|
|
|
Show Posts
