Move this BS to FPGA, please !
Topic: P2Pool and BFL hardware - page 2. (Read 3971 times)
How is this still in GPU forum
Move this BS to FPGA, please !
Move this BS to FPGA, please !
Does anyone else find it rather ironic that BFL signs their posts with "Good Luck"?
Yes, I do.
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?
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.
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'.
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'.
Does anyone else find it rather ironic that BFL signs their posts with "Good Luck"?
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?
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:
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.
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.
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:
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.
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.
...
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 ...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.
It's good enough for me. Now we are only missing a linux firmware update utility.
...
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 ... 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.
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:
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.
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.
+1
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?)
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?)
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.
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.
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:
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.
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.
Jump to: