I am seeing a slight performance increase (over CGMiner 2.3.3....although I haven't tried CGminer 2.3.4 yet). Unfortunately, I'm pretty sure this would have to either be variance, or driver-related. The only change I can think of that would have made any difference for GPUs, is dynamically loading the OpenCL.DLL rather than a normal dynamic link (this is why FPGA-only rigs can run the Windows binaries). Do you implement the current git for reducing network load from cgminer? No, this release is based on CGMiner 2.3.4. I plan to merge Con's latest improvements into our git tree soon. When I want to do this I get the error no OPENCl is installed? You should be able to ignore it unless you want GPUs mining. |
|
|
|
Not that it matters much in the event of an arms race, of course, but I just wanted to state publicly that while I have a lot of respect for luke-jr's work and I *love* the name (which was kano's idea, I believe), my money is on cgminer for now. Reasoning is: - No one knows the core better - As ztex worker maintainer I prefer a high entrance price development style, i.e. one where all my commits are verified - I cannot possibly work on two code bases at once - I have committed myself to supporting other devices on cgminer I do think that ckolivas lack of interest on FPGAs is a negative point, but honestly so as long as he keeps doing the great job he has done so far (and I'm sure luke-jr will still help cgminer development as he's building on top of it) it just doesn't matter. I do however understand luke-jr and others frustration, I just don't share it  I don't consider it an "arms race", and if peoples' changes are compatible with CGMiner, I encourage doing development there. |
|
|
|
I've looked at your Icarus code and I have a question, the epoll is only available on Linux, right? I don't see any epoll.h includes in my MinGW?
Am I missing something? If it works on Windows, that is great, I won't have to code overlapped I/O equivalent.
epoll is Linux-only, and optional. It doesn't have any practical improvement yet, but when done it will enable a quicker response to longpolls. If someone familiar with Windows's WaitForMultipleObjects (or something else like epoll) wants to help out on that end, I'd appreciate it  |
|
|
|
- so the software overhead of closing and opening it every time isn't there except when the error occurs - because: You forgot to mention there isn't any actual overhead to this workaround at all. |
|
|
|
|
FWIW, the difference between CGMiner 2.3.4 and BFGMiner 2.3.4 consists of (with the rename filtered out) 3252 3259 added lines, and 392 399 removed. If it was just a rebranding, I'd have a much easier time figuring out what caused that administrator requirement on Windows. :/
|
|
|
|
Will you be merging / cherry-picking from ckolivas' cgminer or will I need to support ztex on the two code bases separately? I'm trying to minimize conflicts, so I can continue merging cgminer into BFGMiner. I'm also trying to do my own development with cgminer parent commits, so Con can continue to pick-and-choose which parts he adds into cgminer. |
|
|
|
BFGMiner is forked, starting with 2.3.4. Comments etc welcome, but let's not clutter up the CGMiner thread.
|
|
|
|
NEW VERSION 2.3.4, APRIL 26 2012This version is mostly identical to CGMiner 2.3.4, but has a number of fixes and improvements that aren't included in CGMiner. Since I only develop on Linux, I have completed cross-compling support for creating Windows binaries. While they have had a bit of testing, there is always a chance I missed something. Please report any issues you have. Also, since this is a FPGA/GPU miner, without the central focus on GPUs that CGMiner has, I made sure to make the Windows binaries so they can be used on FPGA-only mining rigs in addition to FPGA+GPU rigs (CGMiner Windows binaries require *some* OpenCL implementation). Full changelog: - New maintainership of code with modular FPGA/GPU focus, under BFGMiner name
- Complete working support for cross-compiling Windows builds on Linux.
- Fix usage of low --scan-time settings so it doesn't busy-loop
- JSON API: Add new 'devdetail' command to get fixed device information
- JSON API: Implement driver abstraction for extra device status
- Icarus: Use epoll to wait for serial port input properly, when available
- Icarus: Workaround buggy USB-UART that causes Icarus to stop mining rarely
- Icarus: Estimate mining hashrate correctly, calibrated from real-world data
- Icarus: Parallelize work setup with Icarus hash search improving performance
- Icarus: More reliable detection and runtime
- OpenCL: Move GPU-specific data fetching from JSON API to OpenCL driver
- OpenCL: Dynamically load OpenCL library, to be more vendor-independent and allow use without actually having OpenCL (i.e. FPGA-only rigs).
|
|
|
|
I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves. Yep, it does. There have been a few minor API changes since then, but I've tried to retain compatibility. Some ways to do so I can think of : - an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
- a binary API that would allow a dynamic library load
A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code. Ok, it's not too easy (for end users) to add/remove drivers right now. Adding support for that is mostly trivial, though (a dlopen and a driver registration function). This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things : - defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)
I think this is already possible, but I haven't tried it yet. - passing information from the hardware to the display/log layers of the code in a common way.
Yep, this is completely done already. Doing so for JSON API data is also written, but Kano refuses to merge it because he doesn't want outside code providing new stuff for the JSON API or something silly like that. Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short. Sure, here is the current driver interface, the original refactoring, and the first FPGA driver. The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface). Would a properly maintained cgminer fork be sufficient? |
|
|
|
Yeah, and that's exactly what I did. What's your point? |
|
|
|
If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices. The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality? Duly ignored. Sorry, I think people have a right to know if their donations really won't affect the status quo of regression you've adopted. I don't know any other way to interpret your response than "I want people to donate to me, but I don't want to change the status quo". Get someone to write a plugin for it. Want Luke and Kano to stop fighting? Let them write their own separate plugins.
The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare. I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins). I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating? |
|
|
|
Well, you could withdraw support from cgminer... but I think the better course of action is to modularize all of the processor types and abstract them from the cgminer core. Yes, that's what I did when I added FPGA support originally. The code is still in the same tree, however. |
|
|
|
If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices. The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality? |
|
|
|
I am confused... Anyone have any idea what's up? You "forgot" to re-run autogen. For some reason, cgminer's Makefile doesn't do it. |
|
|
|
Wrote code to append a file with this format: timestamp,disposition,target,pool,dev,thr,sharehash,sharedata Will edit-in an example to this post when I get a chance to test (currently doing an all-day test of some other code). If you want to test it before me, here's a paste of the code. It at least compiles for Windows. Zero checking on Linux so far. It compiles on linux but doesn't work. The output is happening, but not to a file (it appears on screen no matter what I have tried to pass to the command line param) for each share there is also this error: [2012-04-24 17:59:54] sharelog fwrite error Try this one. |
|
|
|
I have a requested enhancement (see below for the bounty). I have a need to log all of the shares that are found by cgminer (for statistical analysis purposes) and the existing information that is output is almost enough but In order to do my calculations, I need to know the target for the work that resulted in the share since I mine on pools that don't have a fixed share difficulty. The current output looks something like this: [2012-04-24 14:27:39] Accepted 00000000.131be987.c9501e82 PGA 0 thread 0 pool 1
My request is for some option to add in the target for the share. To save output space, it would be preferable for it to be displayed as the equivalent difficulty and not the massively verbose hex target. So as to not bother other cgminer users or those that are already parsing the current output, perhaps it should be optional (based on a new command line parameter, etc)? I'm imagining something like: [2012-04-24 14:27:39] Accepted 00000000.58373f06.7b5f26c7 (0.999985) PGA 1 thread 1 pool 1
[2012-04-24 14:27:44] Accepted 00000000.4534557e.a78f6b4a (2.314230) PGA 1 thread 1 pool 1
[2012-04-24 14:27:44] Accepted 00000000.db937fb0.34751330 (4.000000) PGA 1 thread 1 pool 1
[2012-04-24 14:27:44] Rejected 00000000.ca984202.8376eec0 (0.999985) PGA 1 thread 1 pool 1
[2012-04-24 14:27:47] Rejected 00000000.714a3646.4348042c (0.999985) PGA 0 thread 0 pool 1
Or some other equally parse-able format that includes the timestamp, accepted/rejected, the share hash (or at least as much as is currently included), the difficulty/target, which device it was, and which pool it was (for cases where there are multiple pools configured). It's fine if it also includes the thread (as shown above), but I don't need that information, myself. Wrote code to append a file with this format: timestamp,disposition,target,pool,dev,thr,sharehash,sharedata Will edit-in an example to this post when I get a chance to test (currently doing an all-day test of some other code). Example: 1335313090,reject,ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000,http://luke.dashjr.org/tmp/code/earlyshare.json,CPU3,3,6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000,00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498f681634a4f1f63d01a0cd43fb3380000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 If you want to test it before me, here's a paste of the code. It at least compiles for Windows. Zero checking on Linux so far. |
|
|
|
What commit was this based on? |
|
|
|
Might it have something to do with the fact that <n> in COM<n> has 2 digits instead of 1? Has anyone else run into this issue? Yes. You need to use the full path if it's more than 1 digit. |
|
|
|
In the past he hasn't tested (or even compiled) some of the changes he requested, Kinda hard to test GPU mining when I didn't have any working GPUs; I think I did the best reasonably expected given those circumstances. That's solved now (I have 1 working GPU, and another on the way). having to argue with him about why a code bug is a bug is a complete PITA. I added work-restart support to the Icarus driver, and you started demanding I had to refactor the (admittedly broken-by-design) internal structure that it used. Just because I'm touching a piece of code doesn't mean I want to refactor the existing code it's using (and when/if I do, it certainly doesn't belong in the same commit). As I told you, I wanted to talk to Con before changing it, since I wasn't very familiar with it. As it turns out, this particular code goes back to Jeff Garzik and cpuminer, and Con seems fine with the refactor you suggested. But a real code bug that he put in as a pull request - he thinks that's not possible.
(until later he sees exactly what I've told him is already on his own screen - he just didn't test it properly) Sorry, I had no reason to expect that fixing the hashrate measurement in the Icarus driver would somehow break the actual share-finding. It was a subtle bug, one you admit would only be noticable after hours of mining with it. I'm sure this will not affect anyone, but I'll take a break from the code for a day?, week?, month? and see how this latest set of changes mess things up ... or wait for them to disappear. I finished writing that JSON API refactoring I proposed to you, and was kindof hoping you could look it over and see why I think it's a good idea. Feel free to take your time; it'll just be sitting there waiting for your input when you get back, not merged until you give it a thumbs up. |
|
|
|
|
Show Posts
