Bitcoin Forum
December 09, 2016, 10:06:28 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: P2Pool and BFL hardware  (Read 3646 times)
jothan
Full Member
***
Offline Offline

Activity: 184


Feel the coffee, be the coffee.


View Profile
April 29, 2012, 09:40:57 PM
 #1

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.

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481277988
Hero Member
*
Offline Offline

Posts: 1481277988

View Profile Personal Message (Offline)

Ignore
1481277988
Reply with quote  #2

1481277988
Report to moderator
1481277988
Hero Member
*
Offline Offline

Posts: 1481277988

View Profile Personal Message (Offline)

Ignore
1481277988
Reply with quote  #2

1481277988
Report to moderator
1481277988
Hero Member
*
Offline Offline

Posts: 1481277988

View Profile Personal Message (Offline)

Ignore
1481277988
Reply with quote  #2

1481277988
Report to moderator
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 29, 2012, 10:31:25 PM
 #2

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
jothan
Full Member
***
Offline Offline

Activity: 184


Feel the coffee, be the coffee.


View Profile
April 29, 2012, 10:46:04 PM
 #3

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.

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 30, 2012, 04:27:13 AM
 #4

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
bitpop
Legendary
*
Offline Offline

Activity: 1932


https://keybase.io/bitpop


View Profile WWW
April 30, 2012, 11:44:43 AM
 #5

+1

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
BFL-Engineer
Full Member
***
Offline Offline

Activity: 227



View Profile WWW
April 30, 2012, 03:56:04 PM
 #6

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.

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.

BF Labs Inc.  www.butterflylabs.com   -  Bitcoin Mining Hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 30, 2012, 04:38:03 PM
 #7

...

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
jothan
Full Member
***
Offline Offline

Activity: 184


Feel the coffee, be the coffee.


View Profile
April 30, 2012, 04:58:09 PM
 #8

...

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

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
jothan
Full Member
***
Offline Offline

Activity: 184


Feel the coffee, be the coffee.


View Profile
April 30, 2012, 04:59:24 PM
 #9

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.

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.

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

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
BFL-Engineer
Full Member
***
Offline Offline

Activity: 227



View Profile WWW
April 30, 2012, 07:04:26 PM
 #10

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.

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.

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.


BF Labs Inc.  www.butterflylabs.com   -  Bitcoin Mining Hardware
bitcoindaddy
Hero Member
*****
Offline Offline

Activity: 481


View Profile
April 30, 2012, 07:17:39 PM
 #11

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?
BinaryMage
Hero Member
*****
Offline Offline

Activity: 546


Ad astra.


View Profile
May 01, 2012, 04:30:38 AM
 #12

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

-- BinaryMage -- | OTC | PGP
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 01, 2012, 05:11:20 AM
 #13

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
BinaryMage
Hero Member
*****
Offline Offline

Activity: 546


Ad astra.


View Profile
May 01, 2012, 05:13:38 AM
 #14

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

-- BinaryMage -- | OTC | PGP
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 01, 2012, 05:53:25 AM
 #15

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
ModusPwnd
Member
**
Offline Offline

Activity: 100



View Profile
May 01, 2012, 09:16:23 PM
 #16

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

Yes, I do.   Tongue



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? 
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
May 01, 2012, 09:59:58 PM
 #17

How is this still in GPU forum Huh

Move this BS to FPGA, please !
jothan
Full Member
***
Offline Offline

Activity: 184


Feel the coffee, be the coffee.


View Profile
May 01, 2012, 10:04:21 PM
 #18

How is this still in GPU forum Huh

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.

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
bitpop
Legendary
*
Offline Offline

Activity: 1932


https://keybase.io/bitpop


View Profile WWW
May 02, 2012, 03:26:16 AM
 #19

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

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 02, 2012, 05:24:22 AM
 #20

what a scammer bulnula http://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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!