So while I appreciate Con's contributions, and would welcome his joining in on the FPGA/ASIC driver side, it isn't fair to say "the community doesn't care one bit about what software they're mining with" just because they don't see a need to buy hardware for a new
developer for what is already working fine and maintained. That being said, don't let this stop anyone from buying Con some FPGAs or ASICs - his contributions to CGMiner are more than worth what they cost.
- FPGA support in CGMiner has always been my work, and plan to keep maintaining it in any case
- Con's contributions to general CGMiner code (and GPUs!) is appreciated and great quality code; I'd love to have him contribute to FPGA/ASIC drivers in the future
- Please do donate to Con, including FPGAs/ASICs, for his past and possibly future contributions - but don't get the wrong impression that FPGA/ASIC support will change or degrade if you choose not to
Unfortunately, this is actually clearly an exaggeration to the point of being incorrect.
luke-jr wrote the first FPGA module which was support for the BFL.
Xiangfu wrote the first support for the Icarus based on Luke-jr's BFL code but even back then had to rewrite enough of it to make it work properly - back with the first release of the Icarus code my involvement was to help debug Xiangfu's code and get it working.
nelisky wrote the entire ztex support and luke-jr has had nothing to do with that at all.
By this point I had rewritten some of the Icarus code, extended it and also added the only performance gains to it so far: LP abort, 10x setup speed and optimising the abort time to reduce getworks
The only non-trivial change that luke-jr initiated for Icarus (even in his fork) was to close and re-open the serial port every time it sent work to the Icarus to avoid a problem with the serial port not working due to a problem with his linux kernel he was using - which I requested he instead determine when there was a serial port problem and then close and re-open it (since it was such a rare problem) - but he refused to.
I requested he change the BFL code to abort work on an LP to stop wasting work (on average half a nonce per LP) - of course only if the pool doesn't accept or need stale work - but again he refused to do it (and still hasn't)
The side affect for anyone mining on a pool that doesn't pay stale shares, is that the BFL code now gets 5x
the stale shares compared to GPU and Icarus when you factor in the MH/s speed
(i.e. if you incorrectly ignore the MH/s difference BFL is 10x the number of stale shares vs Icarus)
Feel free to view my rigs (2xICA, 1xBFL, 1x6950) to verify this:http://18.104.22.168/miner.php?ref=0&pg=Mobile
(N.B. that page is very slow to load and I will remove it from this post some time in the future)
His excuse for this was: June-1 GMT+10 log discussion:The next MOD that decides to remove this BETTER HELL ASK ME FIRST OR HAVE A GOOD EXCUSE
other than pandering to a bull shit request from Luke-jr and helping hide his lies ... got that gmaxwell?
The PUBLIC FreeNode IRC #cgminer channel that anyone can be in - including you have been in - is NOT private in any way
[Private log reposted without permission removed
12:50 < luke-jr> kanoi: Bitforce still can't interrupt work like Icarus can
12:50 <@kanoi> it can't abort work at all?
12:51 < luke-jr> not the same way Icarus does
12:51 <@kanoi> I know that
12:51 * luke-jr isn't really interested in working around BFL's screwups, especially when there's a proper fix coming "any day now"
12:51 <@kanoi> if the work isn't submit-stale and cgminer isn't submit stale then aborting the work will be a clear increase in performance
12:52 <@kanoi> very simple and obvious
12:52 < luke-jr> that's nice, but it isn't what I'm doing.
12:53 <@kanoi> you don't like obvious simple performance increases ... :P
12:53 <@kanoi> lol
12:53 < luke-jr> no, I do. I just don't push it upstream when it's an ugly hack that gives BFL a way out of fixing it properly.
12:53 < luke-jr> my private branch aborts BF jobs when the block hash changes
Still no sign of that 'private' code he wrote more than a month ago ...
So everyone using BFL on a pool that doesn't pay stale shares is getting 5x
the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x)
luke-jr wrote the support for MMQ
(I wont get into the issues with that code now ...)
luke-jr added support for the BFL Rig Box (similar to the BFL single)
Now for the actual commits in the commit log with our names on them I did:
git log | grep Author | grep -i (kolivas or kano or luke)
Matching the following words:
This of course includes git management by ckolivas, however, git management is just as important as writing code for the git
Now I wont make any exact meaning of those numbers - but feel free to analyse the results if you wish.
I clearly have trust issues with anything luke-jr says ... maybe others do too?