Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 35. (Read 260035 times)

NEW VERSION 2.3.5, APRIL 28 2012

This release of BFGMiner addresses the source release's configure issues, and includes most of the changes from CGMiner 2.3.5.
One notable exception is that BFGMiner retains the --no-longpoll option, since I found it useful for testing/development.

Firstly the TL;DR version: I consider it unlikely for a project run by Luke-jr to continually spit out reliable code
That may mean that you wont have any problems so it may not matter to you.

The long version:
The base code in cgminer is the scheduling and threading of dealing with mining devices and pools
That was designed and written by ckolivas - who also wrote a linux kernel scheduler that eventually led to the linux kernel 'gurus' rewriting their's coz ckolivas was better.

The FPGA code in cgminer is not really that big a deal.
Anyone can write that - hell - even I can
Adding support for the latest greatest patch by 'Luke-jr' is rarely if EVER going to mean you will get more BTC than pico bit cents.
Of course getting those extra pico bit cents is good - but in my case, I'm more wary of bugs going into the code first then the pico bit cent gains can go in next when it's tested and debugged

There is definitely no problem with arguing about opinions.
My problem came when luke-jr argues about bugs being bugs due to the "I'm always right" issue he has.

I wrote changes for Icarus but hadn't tested them on Windows so I didn't put them up for a pull request
Xiangfu and I ran that code for a few weeks that I had discussed often in IRC also (but I didn't do a pull request as I said a few times in IRC coz I had no working Windows test environment to compile or run it)

Luke-jr submitted a pull request to ckolivas to do the same thing weeks after I wrote it and had it in my git

In my first look at the code there were 2 bugs (from simply just looking at the code) that I brought up with Luke-jr
I knew they were bugs because I had already written my own version of the code (as he knew)
That turned into a long running argument of him saying they weren't bugs and that I was wrong
Nowhere in that first discussion did he consider testing what I pointed out or consider that what I said was correct.

I was correct, they were bugs and he eventually changed it (not the end of the bugs ... read below)

The reason I ended up outright rejecting his Icarus code, and writing mine over it, was the Windows issue:
I finally did get my windows environment working again by deleting it and starting again using Sharky's windows script
(which I hadn't wanted to do but obviously was necessary since I was taking way to long to fix my windows test area for cgminer)
Next, I firstly tried to run Luke-jr's Icarus code since it was ALREADY committed into cgminer (and DIRECTLY admitted by him already that he had never tested it on windows)
His version just hanged cgminer in windows (stopped dead mid code and didn't report an error or exit or abort)
I tried my version (2nd) and found that it failed to detect the icarus (and the code said so) then of course said it found nothing to mine with and exited.
What this of course meant was the initial detection code had an issue and I next implemented changes like af_newbie had suggested to initialise the Serial-USB and found that fixed it.
That didn't fix Luke-jr version (that was already committed into cgminer) so I wasn't really all that interested in debugging his code (and having another argument with him about whatever the bug was), his code that he hadn't even tested in windows (as he had stated himself) so since my code worked and I had written it weeks before and run it for weeks on 43 Icarus devices in linux - I simply requested my pull request be committed directly into cgminer (effectively undo luke-jr's changes) since the current code in there didn't even work on windows and hung cgminer

I'm not sure what anyone else would have done, but after the issue with him the week before arguing about him saying the text saying "ICA" instead of "PGA" being a MAJOR BUG and he wouldn't agree to anything that he said he would agree to about that text, I was jack of it and just overwrote his non-working icarus code (that I had myself written weeks before him anyway)

What this fork will have is "He is always right" so he will allow any code he writes even if he hasn't tested it properly (or tested it at all)
If he says "no that won't happen any more" then why the fuck did it happen OFTEN before - and how has that suddenly changed when no one else is checking his code?

Lastly, you don't need to believe me - but I can supply IRC logs and pull request logs that clearly show all this.
(I'm just not really interested in spending hours to go through all that - though the pull requests are all there for anyone to see and the irclog of Freenode/#cgminer - well yeah I have a majority of the last 8 months of that ...)

aclocal is part of automake. Looks like autogen.sh somehow made the source tarball invalid. I'll be sure to check into it for next time :/

After 4h of sleeping i finally got somme time to sit with my brand new ztex "Y"
For last rew months here i was using cgminer 2.0.6 with 2x5870 (prebuilt) and now, i cant remeber haw to buit bfgminer on my own. I`m following README guide, but just like before - linux hates me too :/

i downloaded .zip, so ok, it`s not git.... ok... but:

any help here ??
ubuntu  11.04 10.10, sdk 11.6, sdk 2.4 - working perfectly with phoenix and cgminer 2.0.6

you can, but you shouldn't

plz don't stop maintaining cgminer. i love it. the only thing i would change about it is to add the option to mine with cpu.

Luke, I think we are on the same page here. I would also NOT like to see a fork. If the key developers cannot reach concensus then a fork may be unavoidable. Constructive arguments are one thing, but continual pointless bickering is just that.

Watching to see how this develops. Good luck regardless of your decision!

You do, when you choose what miner you use. Since CGMiner doesn't include the changes I consider necessary as a miner, my choices are to stick with what I get, or fork and make it work myself. As a programmer, I chose the latter.

  who decides what is necessary ? That's what i hate about over religious people. They think only their point of view matters.

If CGMiner "leapfrogs" by including all the fixups and enhancements in BFGMiner, then there'd be no reason to continue BFGMiner. The main reason BFGMiner exists is because CGMiner is not willing to include many necessary changes.

CGMiner has for the most part been a one-man show up until very recently. Kano added his API, but intentionally maintains it independently from CGMiner. I hopped on to refactor CGMiner for modular driver and FPGA support because I didn't want to be stuck using Ufasoft with my BitForce Single. I was also given an Icarus for the purpose of improving support for it. However, as of recently, Kano insists on continually breaking and undoing fixes I've made to the Icarus driver and refuses to learn how to develop as a team (eg, merging instead of overwriting others' changes), and Con seems content with him doing so. Therefore, forking in this scenario is better for miners who need reliable Icarus (and who knows what else in the future) support. If the scenario changes significantly, the conclusion may change too.

Edit: In short, I would prefer NOT maintaining a fork, but it sure beats spending hours arguing with Kano and eventually ending up with an unreliable miner due to my fixes being rejected.

It is coincidence.  He named after this: 

http://www.youtube.com/watch?v=FRgYtp3HfvY

I, too, am saddened to see this break develop. The community does not need 2 flavors of what has been (and is) a very robust, highly capable and compatible, and flexible miner. This split will weaken both in the long run.

I've evaluated both cgminer and bfgminer on my systems; for all intents and purposes they are identical. For my present and anticipated future needs, either one is already more than adequate. I do not look forward to having to follow both, just to see them leapfrog each other version after version. It is a pointless competition with little to no tangible benefit to the community.

There is great benefit in having a common pool of clever ideas and clever developers collaborating on a focused goal. It has resulted in cgminer. Breaking that team and pool apart is not in the best interests of cgminer users. I, too, believe that if this split is allowed to continue, long term it will result in too much divergence for the code to be easily shared. This will result in a dilution of programming talent, and a reduction in coding efficiency. Both of which are a disservice to the very people that are the end-customers: miners.

Certainly the more people you are trying to cater to, the more of them you cannot please. Forks do allow potentially better support for a smaller targeted subset of people. But there is a point at which the benefits of maintaining cohesion outweigh the benefits of breaking off a marginally refocused fork.

I believe in this specific situation the benefits of splitting are insufficient to justify doing/continuing it. cgminer is already doing a great job, and with developers' help it will continue to improve its gpu and fpga support as new firmware and devices show up. Do we really need a 2nd miner with equally great support?

From what I've seen Kano, Luke-jr, and the other developers are very clever and passionate people who are quick to add support for new devices/firmware and to act on user's requests. And ckolivas is well-grounded, level-headed, and careful about committing changes, all attributes making him an ideal resource to be 'piloting' the project.

Just give the situation some thought, and try to envision what we may have a year from now, before throwing your support towards (1) cgminer-only; (2) both cgminer and bfgminer; or (3) bfgminer only.

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

No, this release is based on CGMiner 2.3.4. I plan to merge Con's latest improvements into our git tree soon.

You should be able to ignore it unless you want GPUs mining.

Nah I was discussing a name in IRC with Sharky (March 1st) back when conman took his long break

Sharky said FGMiner and I immediately thought of BFGMiner and said that's what it should be changed to with 3.0
(luke-jr was connected at the time as usual but probably not watching coz he didn't comment)

That's when I thought of it and have mentioned it a few times in IRC since then

I suggested it again on 15-Apr in a discussion with conman and luke-jr (about another name for cgminer that someone else brought up)
luke-jr said cgfminer but I replied with bfgminer (and the BFG Doom name comment also)
(BFGMiner of course also meaning Bitcoin FPGA GPU Miner)

Ill be waiting I'm not a linux pro (somehow linux hates me ) but i can do basic things with it. In case u need to look for yourself i can offer Temvierwer ecess to it (and all the other 1.15x Boards; but i could separate them in a different VM if needed)

It isn't supported yet, no. But I am going to take you up on that offer soon Chances are I'll be able to provide you with a version to test, and with a little patience from you I won't need remote access at all, but I'll let you know when the time comes.

Is the 1.15y supported by this? If not i could offer u remote access to one (windows, but i can setup linux aswell if u need it).

Ok, so visit http://libusb.org/wiki/windows_backend and grab yourself the zadig utility (just fing zadig on that page).
Using Zadig, find the ztex device (it's either 221A:0100 or "ZTEX Module") on the drop down (You may need to use the "List All Devices" menu option) and install the WinUSB driver. That should be enough to make it work.

If you need to later upgrade firmware or use BTCMiner again you'll need to, using Zadig again, install the libusb-win32 driver on your device and you should be set.

If the device appears as 221A:0100 you must edit the name to "ZTEX Module".

Let me know how that goes.

i see..
well: Specs:
Windows7 x64
ZTEX 1.15x   (1x)

Used a prebuilt windows binary.

More details needed; what OS, did you build it yourself?

On windows there are a few extra steps that I haven't found the time yet to document, but you'll need to remove the libusb-0.1 driver used on BTCMiner and install the libusb-1.0 (WinUSB) driver instead. I'll try to come up with some draft of the instructions if that is the case.