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.
Topic: Will the CGMINER developer get a loaner unit from BFL? - page 3. (Read 6228 times)
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.
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.
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 ?
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.
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 ?
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
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 ...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
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.
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.
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
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.
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.
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. The de facto standard in mining software.
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.
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.
Do you think Eclipse will be able to handle 100 TH/s ?
Solo-mining ! The way to go
Solo-mining ! The way to go
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.
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
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.
+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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Jump to: