Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

needs a plug in for bfgminer #17

Open
Hardcore-fs opened this issue May 20, 2013 · 10 comments
Open

needs a plug in for bfgminer #17

Hardcore-fs opened this issue May 20, 2013 · 10 comments

Comments

@Hardcore-fs
Copy link

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.

@ohmpossum
Copy link

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.

@TheSeven
Copy link

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.

@TheSeven
Copy link

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?

@ohmpossum
Copy link

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

@razorfish-sl
Copy link

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!!!)

@TheSeven
Copy link

Hm, I think I remember it running at 400MHz on Kintex7, so that might possibly even be right :)

@razorfish-sl
Copy link

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..

@ohmpossum
Copy link

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 [email protected]:

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//issues/17#issuecomment-18338288
.

Gordon Aplin
Lewisville, TX

@ohmpossum
Copy link

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.

@razorfish-sl
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants