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. |
|
|
|
I'm going to be getting some BFL (FPGA) miners soon and am worried about the frequency of LONGPOLL on merged mining. If I mine on the bitcoin only address ( http://us.ozco.in:8331 Bitcoin Only) will I get a reduced number of LONGPOLLS? Once every 10 minutes on average? Yes, and you can also do merged mining with just the bitcoin longpolls as well on a per-worker basis at ozcoin. |
|
|
|
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. |
|
|
|
Much appreciated, thanks  |
|
|
|
|
By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.
|
|
|
|
- Initial Ztex support 1.15x board.
|
|
|
|
|
First cgminer release (2.3.4) with limited ztex support for 1.15x is out.
|
|
|
|
|
NEW VERSION - VERSION 2.3.4, 25 APRIL 2012
The release archive for this is much bigger because of included firmware for ztex boards. The version number is only a minor increment because it is mostly bugfixes for any features already working, and extra features should not affect existing working code.
Human readable summary:
Status window fixes for >8 devices.
Ztex support
Information at startup if config file is loaded
(advanced) gpu-map option for when OpenCL and ADL disagree on device numbering
API thread will restart properly if cgminer is restarted from the menu, and this hopefully will fix the ADL deciding to stop reporting fanspeeds by successfully restarting cgminer.
More information is given off with -n on the command line now.
You can increase the queue much more than 10 now if so desired.
Updated miner.php
Better Icarus support
First ZTEX FPGA support.
Full changelog:
- Extensively document the cause of GPU device issues and the use of --gpu-map.
- Support for share logging
- Detect poorly performing combination of SDK and phatk kernel and add verbose
warning at startup.
- Icarus update to new add_cgpu()
- Icarus driver working with Linux and Windows
- api.c fix unused variable compile warning
- Display all OpenCL devices when -n is called as well to allow debugging of
differential mapping of OpenCL to ADL.
- Add a --gpu-map option which will allow arbitrarily mapping ADL devices to
OpenCL devices for instances where association by enumeration alone fails.
- Increase upper limit on number of extra items to queue as some FPGA code can't
yet reliably keep many devices busy.
- Display configuration file information when -c option is passed and only when
file exists on loading default config file.
- Display configuration file loaded, if any, and debug output if configuration
file parsing failed.
- Add missing ztex header to Makefile for distribution.
- Document long-form COM port device names on Windows, required to specify
serial ports above 9
- Include ztex bitstreams firmware in distribution and install if configured in.
- Style police on driver-ztex.c
- work_restart should only be changed by cgminer.c now
- Shut down the api cleanly when the api thread is cancelled. This should allow
the api socket to be closed successfully to next be reopened with app_restart.
- Make a union for cgpu device handles, and rename "device" to "device_ztex"
since it's Ztex-specific
- Initialise name variable.
- Remove unnecessary check for variable that always has memory allocated.
- Bugfix: Missing "break" no-op in default case
- Make the status window and log window as large as can fit on startup,
rechecking to see if it can be enlarged after the fact. This allows any number
of devices to be displayed provided the window is made long enough without
corrupting the output.
- Style police on libztex.c.
- API add removepool like the screen interface
- api.c escape required characters in return strings + pools returns the
username
- Set lp_path to NULL after free for consistency.
- Removing dmalloc import left behind by mistake
- Fixing leak in resp_hdr_cb
- miner.php warning highlight GPU stats if they are zero (e.g. ADL not enabled)
- miner.php highlight any device that isn't 'Enabled'
- miner.php highlight any Status that isn't 'Alive'
- miner.php optionally support multiple rigs
- Initial Ztex support 1.15x board.
|
|
|
|
I paid luke 5BTC for the share log solution: http://blockchain.info/tx/7732db071b843e378b458b447c4962b0ffb22d638da77096238cd266fc847eefckolivas, if you don't like the share log idea and want to do something else officially, I'm willing to still pay you the original 15 BTC since I should have anticipated the fact that someone else might have created a solution in the short time between when I posted the request and when you saw the bounty and decided to do something else. Just let me know what you prefer. It's only money and you've already given some of it to luke who did the work. Why should I make you pay more than you originally offered? Luke's code is fine, but if you want me to include it, it'll have to be a proper pull request and fully documented as well since he'll get even more bounty according to your original offer if I include the code. Gotta be quick to get the quick bucks it seems. I'll go back to the boring slow grind work instead  I commented on a couple of minor issues with his code, he modified it, and I've included it in my git tree now. |
|
|
|
I paid luke 5BTC for the share log solution: http://blockchain.info/tx/7732db071b843e378b458b447c4962b0ffb22d638da77096238cd266fc847eefckolivas, if you don't like the share log idea and want to do something else officially, I'm willing to still pay you the original 15 BTC since I should have anticipated the fact that someone else might have created a solution in the short time between when I posted the request and when you saw the bounty and decided to do something else. Just let me know what you prefer. It's only money and you've already given some of it to luke who did the work. Why should I make you pay more than you originally offered? Luke's code is fine, but if you want me to include it, it'll have to be a proper pull request and fully documented as well since he'll get even more bounty according to your original offer if I include the code. Gotta be quick to get the quick bucks it seems. I'll go back to the boring slow grind work instead |
|
|
|
I can do it. Just trying to decide if it should be this way for everyone. Be aware that rejects are almost always rejected while meeting the target. They're rejected for other reasons.
Ok. I'm fine with either adding the difficulty to the normal output as I originally suggested or creating a share log file as luke coded it (assuming we can get it working). And I wouldn't expect this to change the reasons why shares appear as rejected. I expect rejected shares are shares that cgminer thinks meet the target but that the pool rejected for whatever reason (e.g. they were stale). That's fine. How would you want the difficulty displayed? I'm not really sure I understand the (0.999985) type value you're displaying in your sample. |
|
|
|
Can multiple devices be specified in the config file?
i.e. the equivelent on -d0 -d1 -d3 -d4 -d5 on command line in the config file is ?
I might have to restructure that input as it predates my ability to parse multiple inputs with the one argument. I should change it to -d 0,1,3,4,5 . Not even sure if you can put multiple -d on the config file, but if so, you'd just put in each -d entry on a separate line. |
|
|
|
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. I have looked at the code and I don't think this is super difficult, but I am not a skilled enough C/C++ programmer to do the enhancement myself with any confidence, so I will put up a bounty for it instead. I know ckolivas is busy and/or on a break, so I don't mind if someone else does it and provides a patch. That said, I'd prefer to see it incorporated into the mainline source code so that I don't have to worry about it breaking in the future, so I'm going to include some incentive for it to be merged as well. Here are the bounties I am willing to pay: - 5 BTC to the author of a working patch against the current git cgminer source.
- 5 BTC to the author of the patch if and when it gets merged into the cgminer source. This obviously means the change has to be done well enough that ckolivas is comfortable merging it.
- 5 BTC to ckolivas if he merges the patch.
So that is 15 BTC to ckolivas if he does it all himself, or if it is done by someone else up to 10 BTC to the author and 5 BTC to ckolivas for merging it. I can do it. Just trying to decide if it should be this way for everyone. Be aware that rejects are almost always rejected while meeting the target. They're rejected for other reasons. |
|
|
|
|
The dependencies listed are for release versions, not for compiling from git. Autotools are required only for git development versions of cgminer. It is assumed anyone brave enough to be compiling from git actually knows a thing or two of what he's doing, especially since incremental versions may be broken before the final release.
|
|
|
|
I will repeat my last comment I made (that ckolivas mightn't like either ) I'd guess if this project went ahead and ckolivas got an FPGA also, he'd take interest in the FPGA code in cgminer ... He doesn't have any FPGA hardware, and I think if he did it would be better for all I still have trouble caring about FPGAs, and am happy to leave that to outsiders to work on. GPUs are far more interesting to me. (No I wasn't trying to start a debate about the relative pros/cons of each as we're all well aware of them by now). |
|
|
|
By ignoring your statement that you don't want to do it, it forces you to do it.  I know that goddamnit LOL. |
|
|
|
I'm really sorry but I'm going to have to backtrack on this as I've realised I don't have the time to dedicate to getting this working. I'd still like to see the x6500 support in cgminer, so you should put it back as a generic bounty as you originally planned and open it up for tenders again.
This still stands by the way. However if you really can't find anyone and manage to put together the bounty, I will still do it, but there may be some delay in getting the support since I'll be busy and intermittently away. Why hasn't anyone responded to this comment? I'm trying to say I'd prefer not to do this as I can't guarantee any reasonable time frame. |
|
|
|
Hmm - I was given an Icarus for free for helping debug and get it working on cgminer. (though that was a rather difficult thing to do without any hardware at all or the ability to even run the code ) I'd love to know a reason why larger developers consider that too much ... (I also bought a full price 2nd one a few days later since it seemed to me a good idea to support Icarus also - I just didn't have enough BTC when I first helped with the Icarus.c code - and also thought that getting 2 sent together would be a good idea when I did have enough just after that) ... and an aside on that - xiangfu has the latest best Icarus code for cgminer. The one that went into cgminer the other day is ... well ... not optimal. (and I got really pissed off about having to argue with Luke-jr about why his icarus bugs were bugs - including the one that reduced the actual hash rate of the hardware - and have thus taken a break from cgminer software work for a while ... due to issues about the importance of FPGA mining code and it's reliability in cgminer ... and other issues ...) I'd guess if this project went ahead and ckolivas got an FPGA also, he'd take interest in the FPGA code in cgminer ... I thought you might be interested in coding up this x6500 support instead of me. I did not expect you to come here and complain about your relationship with Luke-jr, as this is not the thread for it. As far as I was aware he addressed everything you told him to address and have included his code on that expectation, while withholding his code that touched your API code unnecessarily. If you wish to discuss this further, talk to me in private, or in another thread. No point taking your frustration with Luke-jr out on this thread. |
|
|
|
First of all, MPBM is not a product of FPGA Mining LLC, but of me personally. And it does support all kinds of monitoring as well. The X6500 being supported by cgminer would surely not be the end of MPBM development, and MPBM development is not paid by FPGA Mining LLC.
The only real advantage of cgminer is GPU mining support, and possibly also a bit lower CPU usage than MPBM. On the other hand, MPBM has lots of features that cgminer can't offer (yet). It also doesn't support the X6500 exclusively, but it does support all FPGA boards that are currently available on the market (except for the newest ztex firmware, which broke compatibility basically overnight without any prior notice, but this will be fixed soon). It almost looks like you're taking this to heart too much, as though it's a vote against MPBM, which it isn't. I could ask precisely the same question about GPU mining apps as to why people use anything but cgminer, but I don't. People just want options, and one person's idea of what fits is never going to be the same for everyone. Almost certainly, the vast majority will want it to consolidate their software with GPU+FPGA miners, but it could just be they like cgminer and it fits. I do understand why some people prefer some other software, and I do think alternatives are a good thing. This particular guy, however, has asked me (or rather the company) several times now to just throw away MPBM and go cgminer-only ("consolidate"), which is of course unacceptable, not just to me, but probably to many other MPBM users. (I already had some long, troll-ish discussion with him in the GPUMAX thread, and I'm just tired of him. He seems to not even have seen some of the stuff he's talking about, and spreads a lot of FUD against both our company and MPBM.) Anyway, we are willing to support cgminer, the company with a bounty, and me personally with knowledge and assistance where necessary. I missed all of that so cannot pass judgement on it. |
|
|
|
I'm really sorry but I'm going to have to backtrack on this as I've realised I don't have the time to dedicate to getting this working. I'd still like to see the x6500 support in cgminer, so you should put it back as a generic bounty as you originally planned and open it up for tenders again.
This still stands by the way. However if you really can't find anyone and manage to put together the bounty, I will still do it, but there may be some delay in getting the support since I'll be busy and intermittently away. |
|
|
|
|
Show Posts
