Will the CGMINER developer get a loaner unit from BFL?

[-ck]

I don't think people have yet realised how scalable and low overhead the cgminer code is. I basically wrote it like it was the core of an operating system, since my programming background is writing for the linux kernel. I estimate the current cgminer code for 2.4.4 can get 30TH of work out of every getwork every 30 seconds, and xiangfu has confirmed that 90 icarus FPGA devices (34 GH) still only uses 4% CPU, so scaling to ASIC hashrates will be  almost trivial, even for low spec hardware, even WITHOUT a getwork protocol change. Pool software, on the other hand, might be inundated by the amount of difficulty 1 shares returned so they really need to be looking towards higher difficulty shares (which I have posted about before here and cgminer already supports) to cope.

[P_Shep]

CGminer. The de facto standard in mining software.

[BFL]

Just to clarify for anyone who is not already aware.  As with current units, we will make units available for any software developer via remote access.  For example, Luke has recently logged in and out several times testing the Mini Rig in order to work on nonce range protocol support for BFG / CG miner.

[jjshabadoo]

It's laughable that anybody gives a shit what BFL does at this point and is going to "punish" them if they don't do this or that.

The mining community has spoken on this issue and their opinion is clear. All they want is to get their unit as quickly as possible and try to be as close to the top of this ASIC pyramid scheme as possible. They don't give a shit about bitcoin.

[KIDC]

CGminer. The de facto standard in mining software.

You're damn right son 

I think from reading ckolivas' post above that one thing I don't have to worry about anymore is cgminer handling huge hashrate. With nrolltime(sp?) I think the bandwidth issue will be resolved too.

Just to clarify for anyone who is not already aware.  As with current units, we will make units available for any software developer via remote access.  For example, Luke has recently logged in and out several times testing the Mini Rig in order to work on nonce range protocol support for BFG / CG miner.

CGminer developers, is this going to be enough to develop for BFL hardware? Or is a physical unit still necessary?

It's laughable that anybody gives a shit what BFL does at this point and is going to "punish" them if they don't do this or that.

The mining community has spoken on this issue and their opinion is clear. All they want is to get their unit as quickly as possible and try to be as close to the top of this ASIC pyramid scheme as possible. They don't give a shit about bitcoin.

I have no problem admitting that I'm mostly in this for mining. Making money working from home playing with cool hardware and getting paid over the internet? YES PLEASE 

[kano]

Just to clarify for anyone who is not already aware.  As with current units, we will make units available for any software developer via remote access.  For example, Luke has recently logged in and out several times testing the Mini Rig in order to work on nonce range protocol support for BFG / CG miner.

i.e. they are not interested in supporting the lead developer of cgminer, ckolivas, they are only interested in having cgminer support BFL for free.

Seriously, lame ass excuse for not sending a single device of any of the cheap ones and a single card of the rigs to him.
Cost for BFL - minimal - but they know they can get away with it coz they have already in the past.

Both myself and Luke-jr were sent a free Icarus.

I still don't even understand why they ignore ckolivas and wouldn't already have sent him a BFL Single and a single card from the rig.

Aside: we already have issues in the BFL code due to Luke-jr:

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]

Code:

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)

That 'any day now' was a month ago.

[Luke-Jr]

Having support for CGMINER greatly increases the value of these units for miners. I would think it would be in BFL's best interests to have CGMINER support ready to go and tested before the new ASIC units ship.

As the original author of CGMiner support for FPGAs, I intend to continue maintaining the driver(s) including implementing ASIC support as soon as possible.

P.S. Kano is trolling and a liar, just ignore him

[Xian01]

P.S. Kano is trolling and a liar, just ignore him

Do you deny having private code that increases performance, you are using it, yet you refuse to publish it because it would give BFL an out not to "properly" fix an apparent issue with interrupting stale shares ?

[Luke-Jr]

P.S. Kano is trolling and a liar, just ignore him

Do you deny having private code that increases performance, you are using it, yet you refuse to publish it because it would give BFL an out not to "properly" fix an apparent issue with interrupting stale shares ?

I wasn't referring to that specific point with regard to him being a liar, though even there he took things out of context...

My "private code" doesn't really increase performance, just avoids stales in a very hacky way. It doesn't make a big enough difference that I bother making an effort to add it in locally anymore. Part of the protocol updates for MiniRig should also provide a proper working mostly-solution. Adding the workaround to BFGMiner proper (or CGMiner) would require a few hours to try to clean it up, add a new option to enable it (--hacky-bitforce-workaround or something; note it doesn't work without causing other problems so simply enabling it all the time isn't reasonable), etc - which seems to me to be wasted effort when there's a proper mostly-solution right around the corner. Another important point Kano neglected to mention was that I also told him I would be more than happy to accept a cleaned up version of this workaround from him if he wanted to spend the time doing so; he told me he wasn't interested unless Con gave him complete control over the BFL driver.

[kano]

Again as I stated before, the BFL code gives 5x the stales of the GPU code and the Icarus code.

At the moment BFL sux with stales compared to Icarus and GPU.

ANYONE with both an Icarus and a BFL can see this buy simply using them both on the same pool (in my case ozcoin) and simply looking at the results.

Here's mine at any particular time:
http://207.36.180.49/miner.php?ref=0&pg=Mobile
(N.B. that isn't my miners, it's somewhere out on the net and it's real slow)
At the moment BFL is 25 times after 9.5hrs on my miner status page

I wrote the LP change in the Icarus code.
I asked Luke-jr to do the LP code in the BFL code.

Looking in the PUBLIC FreeNode IRC #cgminer channel
We could go back as far as:
28-Mar:
13:59 < luke-jr> con_: aborting work on BFL is ugly, and I want BFL to fix it in firmware.
Or 14-Apr:
00:31  * luke-jr hacked his cgminer to newblock-abort both BFL and icarus <.<
Or 3-May:
12:32 < luke-jr> I have a hack locally that aborts on real block changes
12:32 < luke-jr> but I want BFL to fix their crap right
Or 1-Jun one I posted above ...

I would not attempt to try and edit the BFL code, since the last time I made a MINOR indirect change that included the BFL code, he had it rejected from cgminer: https://github.com/ckolivas/cgminer/pull/215
(he has also since implemented in his fork the "ugly bug of a device type" as he calls it at that link)
So there's little chance of me spending the time writing code that he can reject by simply arguing about it for no reason.

[BFL]

If you guys are referring to firmware support of nonce range processing, this is in the Mini-Rig class products, but not in the Singles.  

Upgrading the firmware in the singles with these new calls is not possible via USB, so if you have a software side enhancement to give the same end result, I would have to say that's best so units already in the field can operate more efficiently.  Both Mini Rigs & SC based processors support nonce range.

If this hadn't been made clear before, Luke and you were waiting for a Singles firmware update... I apologize.

[kano]

If you guys are referring to firmware support of nonce range processing, this is in the Mini-Rig class products, but not in the Singles.  

Upgrading the firmware in the singles with these new calls is not possible via USB, so if you have a software side enhancement to give the same end result, I would have to say that's best so units already in the field can operate more efficiently.  Both Mini Rigs & SC based processors support nonce range.

If this hadn't been made clear before, Luke and you were waiting for a Singles firmware update... I apologize.

Oh that's a pity, even gigavps mentioned that he had passed this info onto you guys about 3 months ago ...
And luke-jr's "any day now" was his reason for only having his own version of a low-stale miner ... not everyone else having.
Oh well BFL sux when it comes to stales and sounds like that aint gonna change soon.

[Luke-Jr]

I probably shouldn't give his lies a response, but...

Again as I stated before, the BFL code gives 5x the stales of the GPU code and the Icarus code.

Here Kano is going just based on raw stale count. He should knew pretty well that the hack he's talking about actually hides most of these, rather than preventing them. The proper solution can actually prevent them.

I wrote the LP change in the Icarus code.

The truth is, I implemented LP support for Icarus in CGMiner. Anyone can see this in: 34f8641 Icarus: Abandon a scanhash early when work restart requested

FWIW, while Kano didn't introduce longpoll support, he has contributed a bit to the Icarus driver:

• Cosmetics: Change "PGA" to "ICA" and add himself to copyright header
• REMOVED epoll support (CGMiner performs worse than BFGMiner on Linux, because of this)
• Improve detection time with faster "golden nonce"
• REMOVED workaround for Icarus USB-UART dropping communication on some systems (because of this, CGMiner will not work with Icarus for more than a few hours on my system or anyone else affected by the hardware issue)
• --icarus-timing and automatic hashrate detection (this was an excellent improvement)
• General FPGA avoiding of harmless serial port open failures

It's important to note if you just look at the commit log that Kano reverted a number of my improvements in 80f4fbbdebb4a1c8cf356c2334cb73cd01925eed, and later added them back himself. Other additions, like fixing the MH/s display, I spent hours debugging to find the problem and fix for it, and Kano ripped it off without properly attributing me.

I would not attempt to try and edit the BFL code, since the last time I made a MINOR indirect change that included the BFL code, he had it rejected from cgminer: https://github.com/ckolivas/cgminer/pull/215

No, I told you to fix the bug you introduced with it. When you refused, I fixed it for you, and the actual improvement you made was merged - note that I even made sure to attribute you properly.

If you guys are referring to firmware support of nonce range processing, this is in the Mini-Rig class products, but not in the Singles.

Upgrading the firmware in the singles with these new calls is not possible via USB, so if you have a software side enhancement to give the same end result, I would have to say that's best so units already in the field can operate more efficiently.  Both Mini Rigs & SC based processors support nonce range.

If this hadn't been made clear before, Luke and you were waiting for a Singles firmware update... I apologize.

Unfortunately, it doesn't achieve nearly the same end result, and the minimal results it does get really don't justify the time (IMO) it would take to make something generally usable of it - obviously spending the time finishing up the protocol update (now limited to Mini Rigs) and getting Windows auto-detect are better uses

I wouldn't worry about Kano's trolling - he's taking a lot of things out of context and combining with outright lies to basically throw a fit. Ironically, I don't even remember what his original reason for throwing a fit this time was anymore

[-ck]

I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.

[crazyates]

I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.

How do you put up with their constant bickering? lol

[Luke-Jr]

Looks like Con's solution to his perceived problem of "BFL actually supports CGMiner pretty well, via the original developer of FPGA support and BFL driver - but that's not via me" is to get rid of me so they're left forced to give him stuff or not be supported. In effect, Con has decided that CGMiner will become/live on (how long?) as a de facto hostile fork of BFGMiner (which has continuity of maintenance). I'm disappointed Con has chosen to severe cooperation between CGMiner and BFGMiner, but I hope to continue pulling as many improvements from CGMiner as possible (Con hinted earlier tonight that he wasn't planning to accept the device API updates needed for better Mini Rig functionality - including p2pool compatibility - so there's an increased risk some changes might become impractical)

P.S. I won't speak for BFL, but they asked me to do the Mini Rig improvements for BFGMiner originally (I was doing the CGMiner backport mainly because it was possible). Hopefully this will finally be ready this week (waiting on BFL for some last things), and I expect to release a version of BFGMiner using it ASAP.

[-ck]

I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.

How do you put up with their constant bickering? lol

By ignoring them. I finally offered code to fix some BFL hardware and luke rejected it lol. I guess he was afraid BFL might realise they're betting on the wrong horse by supporting him instead of me. Whatever, I'm outta here, this is like a primary school playground and I'm no longer interested.

[Luke-Jr]

I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.

How do you put up with their constant bickering? lol

By ignoring them. I finally offered code to fix some BFL hardware and luke rejected it lol. I guess he was afraid BFL might realise they're betting on the wrong horse by supporting him instead of me. Whatever, I'm outta here, this is like a primary school playground and I'm no longer interested.

Correction: I didn't reject it, I found it didn't work and started to explain why not - and he rudely dismissed the possibility there was anything wrong with it (though he later decided to fix some of the more obvious issues).

[-ck]

Just go away already. I already told you I'm outta here. Take all the bfl stuff, I'm retiring.

[kano]

I probably shouldn't give his lies a response, but...

Again as I stated before, the BFL code gives 5x the stales of the GPU code and the Icarus code.

Here Kano is going just based on raw stale count. He should knew pretty well that the hack he's talking about actually hides most of these, rather than preventing them. The proper solution can actually prevent them.

The proper solution is to fix the fucking BFL bitstream.
Having to poll the stupid thing over and over again looking for a reply is so stupid it's unbelievable.
But the BFL guy told you - yes read between the lines - fuck off luke-jr they aren't doing that (even if they did say before they would)
Are you stupid or what?

I wrote the LP change in the Icarus code.

The truth is, I implemented LP support for Icarus in CGMiner. Anyone can see this in: 34f8641 Icarus: Abandon a scanhash early when work restart requested

FWIW, while Kano didn't introduce longpoll support, he has contributed a bit to the Icarus driver:

Look I am sick of your stupid lies.
You refer to your update above - yeah click on it - it's dated? 21-Apr when you wrote it.
My commit that I overwrote it with is dated 2 days later 23-Apr.
https://github.com/ckolivas/cgminer/commit/80f4fbbdebb4a1c8cf356c2334cb73cd01925eed
However that code came from my git.

Code:

commit 9ae94d0564168804ae666f961e087ec0f80de355
Author: Kano <root@mutsumi.paige>
Date:   Sun Apr 1 19:42:29 2012 +1000

    icarus.c reduce stales by aborting work on LP

I still have a copy of that git on my computer so I searched it to find that above.
Which is as I said to you above - 3 weeks before (well give or take a few days )
That branch doesn't exist any more - but even xiangfu copied it back then (a few times after that as I made changes) to run it on his Icarus farm, long before I put it into ckolivas git.
Now even more to that - if I check the FreeNode IRC #cgminer log
March 30:
18:37 < kanoi> hi xiangfu
18:37 < xiangfu> hi
18:37 < kanoi> got rid of stales
18:37 < kanoi> (icarus)
18:38 < kanoi> jst been letting it run for a while - not a lot of blocks/LP's this afternoon since I've been working on it
18:39 < xiangfu> sorry. cannot follow you.  you mean there is new code that can get rid of stales?
18:39 < kanoi> yes I've done that this after noon
18:39 < kanoi> I'll put it up on my git in a minute if you want
18:40 < kanoi> you got a minute now?
18:41 < kanoi> I'll put it up - you can grab a copy and then I'll remove it - I haven't tested it on windows yet so I can't leave it there for now
April 4:
17:16 < midnightmagic> kanoi: hey thanks for that icarus LP change. it's working very well.
April 12: (no missing lines between)
18:24 < xiangfu> I am using kanoi/master f15076697750fc17b2f6f32030497b1d6c27fb4e (April 5)
18:52 < a5m0> is that better than the ckovias one?
18:55 < kanoi> for Icarus it includes aborting work on an LP

I wouldn't worry about Kano's trolling - he's taking a lot of things out of context and combining with outright lies to basically throw a fit. Ironically, I don't even remember what his original reason for throwing a fit this time was anymore

Just like you don't remember facts, only spit out lies so often.
It's getting tiresome.
This is the first time you've actually tried to prove yourself right.
Well at least you tried to back your lies, you thought you were smart coz github no longer shows the history of my code, but you didn't realise I would still have a copy of that git or have the comments in IRC to prove you wrong.
I'm fucking sick of it - constantly saying 'you tell the truth' and 'I lie' - and each time I've shows it's the other way around.

Please stop wasting your time and write some useful code ...

Oh wait - no that's not possible either.
When I asked you to do the LP code in BFL you said that it couldn't be done without messing up something or other.
Yet today in a couple of hours ckolivas has written a few patches to your BFL code (without even having a BFL) and it does do LP abort properly and reduced my rejected shares in a major way.

Yeah so now you aren't the only one with low reject BFL code - everyone can have it now from the cgminer git and in the next release.