Bitcoin Forum

As you may know, the BFL single, while being a great mining asset, cannot be used efficiently with P2Pool. The reason for this is that P2Pool has a share time of 10 seconds, on average, and the BFL single scans a whole 2^32 nonce range before reporting results. This means it constantly ends up doing stale work. Scanning a whole nonce range on a BFL single takes about 5 seconds.

Here are the firmware modifications that would be required to use BFL singles on P2Pool:

• Add a new "ZDX"-like command that accepts a nonce range to scan, this would add communication overhead, but would allow the mining software to control the maximum work change latency. This would work pretty much like the cgminer -I "intensity" to control the work batch size. This would also allow splitting a single getwork across multiple devices. While not perfect in isolation, this modification should be simple enough and would make mining on P2Pool at least possible.
• Make the new "do work" command abort and replace the current work. This would lower the reaction time to a longpoll significantly. Somewhat harder to implement than the previous change, but should still feasible with the current hardware (taking a guess here).
• Once a nonce that hashes to an acceptable value, report the finding to the host immediately instead of waiting for the end of the work batch. This change is much harder than the others, since it requires modifying the hashing inner-loop and would break the current protocol. This would reduce stales significantly.

I would greatly appreciate if someone from BFL can ring in on this and tell us if it is at all possible.

These changes would preferably only require a firmware change, but I don't know if this is possible as the BFL hardware is a black box (pun intended).

Any and all comments welcome.

I might note that your second point is already possible, but when that option is exercised the results are thrown away instead of being transmitted the host. Therefore, the third point is the bare minimum to make it compatible, and the first point would be a "nice to have" feature.

Agreed, option 1 is really in the "only do this if it is the only option" category.

Also, the "replace work" command would need to be sure any results are queued up to be sent to the host as you pointed out.

Just so you know ...
I (and others) have brought this up before.
Also Sonny (at BFL) has had it brought to his attention a few times also.
Again recently.
I suspect they will change this soon - but when? No Idea.
I get the impression they do at least now understand that it needs to be done.
Though BFL may have even started to or even done something about it already.
Anyone have some info on when they might be releasing 'some' changes?
(and what they are?)

+1

New commands (Including new job-issuing command and new status-read command) will be added
to the future firmware. This will include nonce-range selection and other changes/improvements that
we decide to present.

Full specification of new commands will be published as soon as they are finalized.


Good Luck,
BF Labs Inc.

Well at least that post wasn't completely pointless - it will have nonce range processing ... one day ...

It's good enough for me. Now we are only missing a linux firmware update utility. :P

Whatever you do, try to avoid having the host poll the BFL device like crazy, try to be somewhat asynchronous if you can.

Polling over sychronous was chosen for several reasons:

1) Unit can respond to other commands while it's processing other data/tasks
    (e.g. Temperature-reading, new job request while the previous one hasn't finished, etc)

2) Polling is very easy to implement in opensource softwares. Synchronouse design
    will face all kinds of different challenges during development/debug cycle.

3) And most important of them all, designing multi-thread applications that can
    communicate with BFL units operating in an asychronous environment is a lot easier
    than designing the same system in a synchronous environment.

Please let me know if you have other questions.


Good Luck,
BF Labs Inc.

Will it be possible to upgrade BFL units that are already out in the "field" or do they need to be sent back to BFL for reprogramming?

Does anyone else find it rather ironic that BFL signs their posts with "Good Luck"?

Well ..... although 'luck' isn't something that can affect the future, looking at your history of hashing is only looking at your 'luck' and nothing more.
i.e. did you get more than expected or less than expected or pretty close to expected.
That is of course meaningless in any term other than how many BTC you gained, since it has NO effect on what you will gain in the future.
But again - it is looking at your 'luck'.

The irony I saw was more in regards to the content of their posts; i.e. "good luck" that we'll implement this feature, or "good luck" that your unit will come soon. ;)

Hmm I think I remember seeing in another thread that their (soon to be? 4-6weeks?) windows app did that also.
Hopefully they are not so short sighted as to not make a linux one also.

Yes, I do.   :P



Supposedly my BFL is on its way to me.  I use P2Pool for my cards.  Guess I need to, at least for now, hook it up to a traditional pool like slushs? 

How is this still in GPU forum ???

Move this BS to FPGA, please !

It was in the "Mining" forum, not the GPU forum.

I moved it, no need to be a dick, mr. scammer.

what a scammer bulnula https://i.imgur.com/PgIVe.gif

Well - completely off topic - but since it seems to have come up all over the forum ...
If all the ranting that's been going on in the forum about it is correct, he's not a scammer.

I don't know who came up with that tag for him, but they really need to go read a dictionary.

Of course I agree that he should return the BTC, but sorry, English is just that, English.
And not returning money someone gave you buy THEIR own fault is not a scam.
He may be a liar if he said he would return it, but changed his mind.
His actions may be reprehensible to most people, yes, but a scam? No.

The element that would classify it as a scam would be to not put the advertising he said he would in his sig.
However, that's the forum mods who have turned it into a scam, not him.

I will add, anyone who says otherwise, please point out where I'm wrong or have misunderstood the situation.

Proper thread https://bitcointalk.org/index.php?topic=78386

There is a very small line between scamming and what he does. I do believe given an opportunity, he will just be one easily.

To me, they're all the same shiet, different pile.

Such shameless POS should rot in hell.

Please rant in the correct thread, not this one. Also, no matter how much you hate someone, STOP FOLLOWING THEM AROUND THE FORUM, because all that does is fuck up everyone else's threads. Thank you.

Who said i'm following him around? I replied to Kano who seems to disagree with scammer tag.

Thats a rant?

Thanks for stating the obvious, which is off topic. Sure as hell Kano knows this. The fact that you quote my post as a rant is laughable. Feel so good huh?

Could you then add a "wait for end of work" command (with an optional timeout) that could be used alternatively to asking "are we there yet" repeatedly ?

It is possible, but what will be the gain? The latency of a kernel-wait object (or read) can be several milliseconds.
It won't be much different from the polling. However, I'm interested to know how it can help. Please give me a few
examples.


Regards,
BF Labs Inc.

I wonder if BFL will ever answer this question?  Will using P2Pool with BFL always be a problem?

Most likely not.  With that easyminer software of theirs the field units can be flashed with these p2pool fixes and you should be good to go. Just waiting for both to be released.

Good to go ...
Yes well I wonder how good to go they will be.
Cgminer certainly wont be using the new firmware coz as far as I know they either haven't contacted any of us
or Luke-jr has the details and he's hiding them :P

But most likely there's no new firmware to be found for QUITE a while.

That easyminer thing screams of the kind of software lock in proprietary crap that is absolutely nothing like bitcoin, and doesn't even allow you to mine anywhere but one pool even. It's really disappointing and I hope people use something else more open... anything, it doesn't even need to be cgminer. I'd much rather whatever benefits were there in the software could be distributed out to other mining software, or they would work with the existing software developers instead of that ancient corporate proprietary model which has been proven time and again to be based on FUD and long-term ends up being a burden rather than a boon.

At this point I cannot see anyone using this software for anything other than firmware upgrades or that test feature.  Their software would really have to 'change the wheel' so to speak for there to be mass uptake from miners who already are using software they are comfortable with a la cgminer or whatever.

Completely agree with you there.

If I was BFL, what I would do:

• Make the mining interface low-latency.
• Document the mining interface in full.
• Document the firmware upgrade procedure.
• Create and release a simple CLI firmware upgrade tool under the GPL.
• Help the mining software authors add and improve BFL device support.
• Drop any single-platform/proprietary software for BFL devices.
• Concentrate on making the hardware and firmware as good as it can be.

As you may have noticed, this takes almost any software development out of the hands of BFL and can actually save them a lot of time and fiddling around.

I don't have a physical windows machine to do firmware bullshit anymore (been that way for years) and requiring windows for a device that can otherwise run exclusively with Free Software is quite silly.

Mostly I think we all agree with the points made above.  

EasyMiner is NOT meant to be a replacement for the professional miner.  It's primary function is product support via firmware update & diagnostics and therefore can't really be open source if we want to maintain proprietary company IP required to stay in business.  

The secondary function is as an ultra simple 'one click' miner for the novice so they don't have to deal with command lines, pool accounts & cryptic settings.  

By all means, please continue your respective miner software projects and we'll actively support you.  While I've got the mic, let me also thank you for the support you've collectively given us already.  It's really appreciated.

So ... can we get that document listing the commands.
They have existed for at LEAST 3 months now.
The only info available (that I know of at least) are the commands: ZGX, ZDX, ZLX and ZFX
(as I mentioned in the other thread)

Kano, the protocol document has been posted to the CGminer dev thread.  It's been updated a bit since then...  blink and temp.  If you write office @ butterflylabs and request, they'll send you an updated copy.

OK, so that indirectly answers my question.
Nothing new that cgminer doesn't already handle.
Thus the throttling identification done in EasyMiner is based on a slow reply
(not some command to identify the internal clock or a 'throttling' state)
And changing the throttling temperature isn't possible.
Pity.

But, I'll email also, just in case there is more ...

I believe those assumptions are correct.