Bitcoin Forum

Will the developer of CGMINER (https://bitcointalk.org/index.php?topic=28402.0 (https://bitcointalk.org/index.php?topic=28402.0)) get a unit to facilitate the development and testing with the ASIC hardware? It would be nice to have working third-party software when the ASICs ship so we don't have expensive paper weights.

+1

Even if as much as 100 TH of new hardware is delivered all at once on release day, anyone able to immediately use the new hardware will recover about 25% of their investment in the first 2 days (if starting right after a difficulty adjustment).

If software isn't ready and tested in advance, it will be a mad scramble to figure it out as the first units arrive, and minutes will be significant. Please arrange for at least one mining program to be tested in advance and ready to be used the moment deliveries occur.

I would think that EasyMiner would work with them. You would make a decent amount of money just using Eclipse at that point.

You might want to check your math. BFL website says that block mining software is included.

Yes, I've seen it, no thanks. I don't want to be forced to mine another pool

If your one of the first to get your ASIC, solo mining seems pretty viable ;)

Do you think Eclipse will be able to handle 100 TH/s ?

Solo-mining ! The way to go :)

Agreed, but BFL's software won't do SOLO mining.

Who knows? I am sure Inaba would pay attention to the state of the software available and if the only thing is EasyMiner then my assumption would be he would try and prepare for it.

This is NAIVE. BFL will "test" all prepared units. At the time they start to ship and your HW will be delivered, the network difficulty will be already adjusted (multiple times up).

Remember my words.

From what I can tell, they don't actually test their products with live BTC mining for more than about 5-10 minutes. The network is not going to adjust THAT much before they start shipping.

They test them using their own algorithms, and checking whether the results match their expected results.

I wrote "test". You can call it burn-in. Or pre-mining.

If you would have 15 (100, 300?) TH at hands, you will definitely try to mine with them before you ship them out. So will do BFL.

Obviously the right thing to do on a moral and customer support basis is for the cgminer team (ckolivas primarily, probably luke-jr if needed and maybe kano too) should get early access to both the specification/protocol for BitForce SC as well as an early unit prototype or something so that full cgminer support will be available when the product line ships. My personal opinion is that BFL has a moral obligation to do this. However, clearly BFL is a for-profit company and may not wish to spend the time/funds to do this since they will have a market monopoly already.

I would like a BFL representative to make an official statement regarding this soon. If BFL isn't going to oblige then as a community we need to get together and help out the cgminer team continue with their constant hard work. I myself am willing to donate in this regard.

I'm sure me and the rest of the community won't forget BFL's decision on this - whichever way they decide.

This is my understanding from what they've said in the past;  as SgtSpike said, they test them using their own algorithms.  Then they do a small live mining test after that as a sanity check.

Not sure if that will change with the ASIC units or not, though (I'm not expecting it to).

+1 on what KIDC said.  I'll be disappointed if BFL doesn't work with the cgminer development team to make sure cgminer can support their new ASIC devices before customers start to receive them.

I'll give them the benefit of the doubt, and guess they haven't responded because they're swamped with order questions right now, it's still early (several months before they're shipping), and they don't have any actual units yet to test with/develop for anyway.

Even if there's other mining software available, the failover functionality of cgminer alone makes it really important.

Thanks guys. I'm watching BFL's movements closely on this one as it likely will determine what I'll be doing long term with bitcoin mining.

WHAT ? You don't want Inaba and EMC to do a 51% with all them juicy ASICs ?

Call me crazy but it sounds just perfect for me !

No cgminer needed. This is not GPU. CGMiner is perfect for GPUs.

ASIC will probably come with EasyMiner software and Inaba EMC 51% kill bitcoin switch sadly :'(

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.

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.

CGminer. The de facto standard in mining software.

:)

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.

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.

You're damn right son  ;D

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.


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


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

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

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

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.

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 :P

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.

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.

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

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 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 (https://github.com/ckolivas/cgminer/commit/34f8641)

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.

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 (https://github.com/ckolivas/cgminer/pull/227) - note that I even made sure to attribute you properly.

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

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

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.

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

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

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?

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

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.

Unbelieveable how much crap guys like Con have to go through to provide great free software and they get like what , 50 bucks in BTC ? lol

While profiteering douchebags like BFL and their cult of minions make a killing.

Anyone want to send ckolivas 50 BTC in advance for the next cgminer release? It will be available in 6 months, he promises <wink>

BTW, LUKE-JR =  fail

For the last ten or so months I have been following BTC it seems you are always in the middle of some type of shit storm. Wake up buddy. When you're always involved, the problem is likely YOU.

Kano and others have helped countless people here for free from everything including linux installs, etc.

You my friend just bitch and moan.

For the record, I don't know Kano or Con from Adam and what I posted is no representation of them in any way. Although you should all send Ckolivas a final BTC donation for his cgminer work and I guess Kano, although I'm not sure how their relationship works in this whole thing.

No one will need to work on ASIC so they deserve it for the GPU mining period.

+1 for this useful post.

+1 for ckolivas and his great software.

-1 for Luke-JR killing CLC coin and also ( supposedly ) doing LTC TX spam testing.

+1

Get your own thread, troll.

bulanula is allowed to +1, but he isn't?

Don't mind them, they are butt-buddies on IRC. ;D

My post was not simple spamming of "+1" crap.

I included some relevant information in there too ( the reasons for the votes ).

someone's jealous.

OK, kind of new I should have stuck to supporting kano and con for their cgminer work and just STFU on Luke.

Good call, my bad, carry on.

I honestly have no f'in clue what Luke does, so I won't comment about him again.

In regards to getting con mining gear, I have donated heavily towards the 2.5.0 release of cgminer. This should go a long way to helping con getting any equipment he may want or need.

I would also recommend others donate to him so that he can purchase some ASIC gear.

I took CGMiner, the GPU miner, and rewrote significant pieces to make it modular and support FPGAs additionally. Everything FPGA-related in CGMiner is based on that work, but Con has opted to fork it in CGMiner and force me to continue the original modular/FPGA project independently as BFGMiner. Don't buy into the trolls and their FUD. Despite Con's renewed interest in maintaining CGMiner as a fork of BFGMiner now that he realizes GPUs are history, the original (BFGMiner) is still better. ;)

You ought to be hanged from a tree for making it sound as though you were the original writer of cgminer. Quit using such weasel language.

The original author of the codebase was Jeff Garzik. Con added GPU support. I added FPGA support. Con then took the FPGA support into his, and eventually forked from the main FPGA codebase. As of right now, CGMiner as it is, is a fork of BFGMiner. That is the truth.

The original author of the codebase was Jeff Garzik. Con added GPU support. I added FPGA support. Con then took the FPGA support into his, and eventually forked from the main FPGA codebase. As of right now, CGMiner as it is, is a fork of BFGMiner. That is the truth.
[/quote]

Forking really is relative.  Selectively choosing which updates to pull while pushing your own doesn't make you a fork.

Forking is when the maintainer changes. In this case, BFGMiner has the same maintainers (Con still indirectly maintains the pool and GPU code, and I still maintain the FPGAs as I always have) and CGMiner has had a hostile change of maintainership (cutting me out of the loop because Con likes Kano better, initially, and more recently as a way to slander BFL by claiming they don't support the project).

Are you sure? Have you seen their software yet?

Unless they release a new version, their software is pretty limited.  Check it out on their website.

 Better watch out. Jesus doesn't like prideful statements like this.

I have. No examples / screenshots of their software. Only their hardware.
I'm very interested in the kind of software they use with their stuff (Yes I know EasyMiner is mentioned a couple of times, but no real user guides of this software)

Enough with all of your spam in the threads , why don't you each go your separate ways with your forks. Luke take all of conman's code out of your fork and then proceed from there. It should work fine, after all, you have stated:      https://bitcointalk.org/index.php?topic=90656.msg1015760#msg1015760

I can't find the exact picture, but BFL showed a picture of them testing a MR with CGMiner.

I can't find the one I'm thinking of, but here's a blurry shot:

http://www.butterflylabs.com/wp-content/uploads/2012/06/IMG_3148.jpg

This was me working on 2 minirigs remotely:

http://ck.kolivas.org/pictures/Mining/minirig.png

Will they give you early (remote) access to the ASICs before they're released?

Early access I don't think so. Timely access, likely. Hardware sponsorship guaranteed they will NOT. However gigavps has taken it almost entirely upon himself to donate as much as BFL themselves probably should have been doing (which is disappointing). His sponsorship has made me care where otherwise I was happy to leave this crap with luke behind forever.

 :D As much as I hate seeing BFL drop the ball, props to Giga for stepping up! I was very concerned CGMiner would not support ASICs, but this is very good news indeed.

It is my sole mission to make sure ASICs are supported by cgminer. Luckily con and I speak the same language.

Did you choose to point it at ozcoin? To you own address?

That should be pretty clear from the screenshot. Alas I only had access for less than a day.

Might as well, right?  ;)

Was just curious if they were okay with that. :)

Yes. That's the closest they came to "sponsorship" of the work.