Open Hardcore-fs opened 11 years ago
What do you mean by unstable? How many boards? I haven't gotten to the stage you are yet but it seems the python code pre-dates 'gettemplate' I don't have the details in front of me. I'm thinking python may be OK to use if it is updated to the newer standard for obtaining work units. I haven't spent a lot of time yet on trying to understand that end of things.
I generally don't want to reply to your personal attacks/insults, but I would like to address some of your technical complaints:
First of all, I assume that by "the damned 'theseven' python code" I assume you mean the latest MPBM, and not the very simple proof-of-concept code that shipped with the VHDL code.
"polling boards in sequence" is a matter of how python works. Due to it's global interpreter lock, you cannot just use threads to parallelize this. (In fact the code is already multithreaded in that area.) You can get around that for more processing-intensive interfaces by using out-of-process workers and IPC, but for the SimpleRS232 interface the overhead of that would be much bigger than the actual work to do. Polling a serial port really isn't a computationally intensive operation.
It does back off. If attempting to reconnect to a board every 30 seconds is too often for you, you must be using some really shitty hardware. I'm running this with several different boards on a Raspberry Pi and it works just fine. In my case I have quite some CPU load because of some other board interfaces that require JTAG bitbanging etc., but if I would only be using SimpleRS232 workers, I guess the Pi should be able to handle several dozens to hundreds of boards.
I don't fully understand what you mean with "as it prints the error messages BETWEEN polling the next dev". You do realize that the actual printing of the message is asynchronous, even though it isn't even a very costly operation to print something to standard output?
I know that ngzhang has used MPBM with 50+ Icarus boards (which have an interface that is very similar to SimpleRS232), and it worked just fine, at least after working around some windows-specific bugs in the PL2303 kernel driver.
If you are not happy with my software, and don't appreciate my work, please just stop using it and go away. You publicly reported that you're using my VHDL code and improved the performance of it, and are not planning to release your modifications to the public. I just don't want to cooperate with this kind of open source leechers.
I know that the GPL doesn't enforce you to release it, but fair behavior is something entirely different.
Where did I ever say that I either optimized that VHDL code extensively, or that I am a VHDL expert?
Interesting discussion. I was wondering that too. I have a lot more to say on this but I need to take care of other things this morning. I'm working with the verilog version but the same optimizations I'm doing can be applied to the VHDL version. I'm still debating on what to do with any of this work. I'm currently mining with two APUs and it looks like it will be weeks before I even get a first payout from a mining pool. I'm debating buying an FPGA board to try things out on but even at the above mentioned 300MH/s it feels like it would not likely ever pay for itself as a miner. I'm an ASIC designer and I'm using this to learn/re-learn the FPGA tools which I haven't worked with for years. Some of the things I noticed in the verilog have to do with the designer probably coming from a programing background and not thinking about things from a hardware perspective and what the tradeoffs are. Instead of just looking at this from a pure speed perspective, I'm considering the low power versions which would allow you to run the same FPGA mining board in a low power mode that may still be cost competitive in the future. From what I have seen of the butterfly labs device, they have replicated their FPGA design as an ASIC as opposed from designing an ASIC from scratch. It isn't clear what the others have done from the design side but it is clear they are running wafer lots which will dump huge amounts of mining power on the network even cutting their own throat in the not very long run as every miner will be paying more for electricity than the coins are worth in the not too distant future. People are hesitant to shut equipment off even in that situation so I don't see this as worthwhile in the long run. There are after all CPU miners running right now at 400KHs even though that makes no sense at this point. I ran one for a short period of time as part of the learning curve but there seem to be others that have just been set up and forgotten. The same will eventually happen with the ASIC equipment. Well, now I'm really late. I will jump back in here when I can.
You both make valid points on the open source licensing. Be nicer.
Happy Mining
Just been taking a look at the VC707 code.....
This thing compiles for a V6 and clocks at Minimum period: 1.804ns (Maximum Frequency: 554.278MHz)
(there must be something not right!!!)
Hm, I think I remember it running at 400MHz on Kintex7, so that might possibly even be right :)
K found an issue... it uses 2 DSP more than a V6-240 has!! WHY does Xilinx tools not report this correctly..... ohmpossum any chance you can re-jig the project for a V6-240, just to get some sort of Idea compared to the Kintex7, I cannot believe a Virtex 6 is faster than something newer with a smaller gate structure..
I'll take a look at it. I have been working with Altera and just switched over to the Lattice tools but haven't played with them much yet. I have Xilinx installed but haven't played with them yet. I'll give it a shot.
On Thu, May 23, 2013 at 6:48 AM, razorfish-sl notifications@github.comwrote:
K found an issue... it uses 2 DSP more than a V6-240 has!! WHY does Xilinx tools not report this correctly..... ohmpossum any chance you can re-jig the project for a V6-240, just to get some sort of Idea compared to the Kintex7, I cannot believe a Virtex 6 is faster than something newer with a smaller gate structure..
— Reply to this email directly or view it on GitHubhttps://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/issues/17#issuecomment-18338288 .
Gordon Aplin Lewisville, TX
Brief update, my install of Xilinx tools just doesn't work. A window eventually comes up and immediately closes. I spent time messing around with licenses and compatibility settings and re-installing altogether with no luck so I have gone back to Altera and have just been working there. I hope you have had better luck on your end. I'll get back to Xilinx eventually but I am making such good progress on Altera I feel I'm wasting time on the others at this point.
yep... it needs a NEW install of the xilinx tools in a NEW home, and delete the old one. This is one reason WHY I consider xilinx have a cheek charging for their tools.
Updating JAVA wouldn't hurt either (YEP they use JAVA.......)
The best way to run the Xilinx tools is inside a VM, that way when something trashes you can just 'roll-back' the whole OS image, plus it allows you to rapidly spinoff different design environments.
Playing about with the current pyton code for submitting jobs, seems unstable once the number of boards is scaled up.
Really the RS232 interface could do with a BFGminer plugin.