Bitcoin Forum
September 21, 2018, 11:06:22 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 »  All
  Print  
Author Topic: Unified miners communication protocol  (Read 5887 times)
kakobrekla
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


Psi laju, karavani prolaze.


View Profile
September 01, 2013, 08:50:14 PM
 #21

There's no benefit to ignore the rest of the nonce space.
+1 There is actually a drawback - you may miss a valid solution. It may not be important if you only care about your shares from the pool, which are always paid, but as a solo miner I DO CARE if i miss my chance, because of that

This is just stupid. There is no need to scan the entire range since nonces are found at random.

1537527982
Hero Member
*
Offline Offline

Posts: 1537527982

View Profile Personal Message (Offline)

Ignore
1537527982
Reply with quote  #2

1537527982
Report to moderator
1537527982
Hero Member
*
Offline Offline

Posts: 1537527982

View Profile Personal Message (Offline)

Ignore
1537527982
Reply with quote  #2

1537527982
Report to moderator
1537527982
Hero Member
*
Offline Offline

Posts: 1537527982

View Profile Personal Message (Offline)

Ignore
1537527982
Reply with quote  #2

1537527982
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537527982
Hero Member
*
Offline Offline

Posts: 1537527982

View Profile Personal Message (Offline)

Ignore
1537527982
Reply with quote  #2

1537527982
Report to moderator
1537527982
Hero Member
*
Offline Offline

Posts: 1537527982

View Profile Personal Message (Offline)

Ignore
1537527982
Reply with quote  #2

1537527982
Report to moderator
KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 01, 2013, 08:55:24 PM
 #22

This is just stupid. There is no need to scan the entire range since nonces are found at random.
Then why scan a range at all? Just pick one at random and stop [/sarcasm]

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
September 01, 2013, 08:58:02 PM
 #23

Why stop scanning at all? There's no benefit to ignore the rest of the nonce space.
It's a limitation of the hardware. The bitfury chips have 756 separate hashing cores, all working in parallel, with each core hardwired to search a fixed 1/1024th of the nonce space.
I don't see why that involves stopping. If anything, it would make stopping harder, as you'd have to tell the other cores to stop their part.

KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 01, 2013, 09:13:23 PM
 #24

I don't see why that involves stopping. If anything, it would make stopping harder, as you'd have to tell the other cores to stop their part.
I am not quite sure i understand this.
BF chips are not scanning all possible nonces in the range and they also can't cancel the calculation of a job, because of a hardware limitation.
What cscape meant is that it is hard to scan the missing nonces and they may not even be in some specific range which can be passed to another hardware, not that we should stop scanning.

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
kakobrekla
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


Psi laju, karavani prolaze.


View Profile
September 01, 2013, 09:40:33 PM
 #25

This is just stupid. There is no need to scan the entire range since nonces are found at random.
Then why scan a range at all? Just pick one at random and stop [/sarcasm]

You switched sarcasm with stupidity. It ain't the same.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
September 01, 2013, 09:48:57 PM
 #26

I don't see why that involves stopping. If anything, it would make stopping harder, as you'd have to tell the other cores to stop their part.
I am not quite sure i understand this.
BF chips are not scanning all possible nonces in the range and they also can't cancel the calculation of a job, because of a hardware limitation.
Oh, I hadn't noticed the former.

What cscape meant is that it is hard to scan the missing nonces and they may not even be in some specific range which can be passed to another hardware, not that we should stop scanning.
I'm confused as to what the original argument was then..
No reason to go out of your way to scan missing nonce ranges either, unless you're trying to produce work on a severely underpowered machine.
Considering how much is being invested in ASICs, it's silly to try to go super-cheap on the controller. Especially when mining rigs really should have their own full bitcoin node running. So this just reinforces that it's easier to generate more work, as cscape said.

cscape
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
September 01, 2013, 10:13:00 PM
 #27

+1 There is actually a drawback - you may miss a valid solution. It may not be important if you only care about your shares from the pool, which are always paid, but as a solo miner I DO CARE if i miss my chance, because of that
It makes no difference whether you scan 1 full range, or 2 half ranges. The only thing that matters is how many hashes per second you can do.

Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
kano
Legendary
*
Offline Offline

Activity: 2576
Merit: 1053


Linux since 1997 RedHat 4


View Profile
September 02, 2013, 12:38:46 AM
 #28

This is just stupid. There is no need to scan the entire range since nonces are found at random.
Then why scan a range at all? Just pick one at random and stop [/sarcasm]
Learn a little about statistics before replying again Smiley

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 02, 2013, 09:55:26 AM
 #29

Learn a little about statistics before replying again Smiley
What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.
From https://en.bitcoin.it/wiki/Nonce
"Since it is believed infeasible to predict which combination of bits will result in the right hash, many different nonce values are tried"

You can't assume for example that nonce 3861865442 will not be a valid solution for some block header and if you do so then block 255679 would not have been found from BTC Guild, but someone else, some time later

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
cscape
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
September 02, 2013, 10:16:56 AM
 #30

What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.
Instead of 'skipping', think of it as 'replacing'. The hardware is still looking for valid solutions, just using different combinations of coinbase/timestamp/nonce. You are just as likely to find a solution if you only search half the nonce space, increment timestamp, and search the same half again in the same time as another miner searches the whole nonce space once.

Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 02, 2013, 10:40:34 AM
 #31

Yes, i agree with that and that for low speed miners it doesn't matter if you increment timestamp or nonce, but for higher hashrates it will be more expensive to calculate new merkle root hash, once you have tried all allowed timestamps, because you have skipped some nonces, but that will be in the far future ...

It seems the general thoughts are that nonce range is useless, so i will remove it.

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
kakobrekla
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


Psi laju, karavani prolaze.


View Profile
September 02, 2013, 12:36:33 PM
 #32

Yes, i agree with that and that for low speed miners it doesn't matter if you increment timestamp or nonce, but for higher hashrates it will be more expensive to calculate new merkle root hash, once you have tried all allowed timestamps, because you have skipped some nonces, but that will be in the far future ...

It seems the general thoughts are that nonce range is useless, so i will remove it.

And remove yourself too cause you are talking nonsense.

kano
Legendary
*
Offline Offline

Activity: 2576
Merit: 1053


Linux since 1997 RedHat 4


View Profile
September 02, 2013, 12:51:20 PM
 #33

Learn a little about statistics before replying again Smiley
What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.
From https://en.bitcoin.it/wiki/Nonce
"Since it is believed infeasible to predict which combination of bits will result in the right hash, many different nonce values are tried"

You can't assume for example that nonce 3861865442 will not be a valid solution for some block header and if you do so then block 255679 would not have been found from BTC Guild, but someone else, some time later
Correct you cannot assume that ... as you cannot assume anything regarding which nonce values should be checked.

If you skip checking that last 1billion of each range, you will instead process 3/4 of 4/3 more nonce ranges ... which means you checked the same number of nonce values.

That is all that matters.
How many you check, not which ones you check.

The glaring error in your example is that you also could miss finding a block in some other work item that has a block in the bottom 3/4 of the nonce range, that you wouldn't have reached before the LP reset everything, if you were mining the full nonce range every time - since you would have only checked 3/4 as many different work items.

Both are just as valid possibilities of where a block may exist.

Neither possibility makes ANY difference to the chances of you finding a block.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 02, 2013, 02:43:41 PM
 #34

OK, any comments about the protocol proposal?

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
September 02, 2013, 03:07:51 PM
 #35

OK, any comments about the protocol proposal?
It's missing several things:
  • A way to know when a job has been started (and on which boards/chips) and completed (and how much of the nonce range was in fact scanned).
  • A way to know which specific slave board and chip found the nonce in question.
  • Access to temperature sensors.
  • Control of any LEDs.
  • Commands to get and/or control clock frequencies, voltages, etc.
  • Some way to get error checking information/feedback, to make dynamic clocking more accurate.

Additionally, "cancel" is misspelled. IMO there is no real value for asking the device for its current hashrate.
It might be nice if the protocol were prepared to handle non-Bitcoin POW algorithms too, but this could probably be done as an extension.

Finally, if any vendors are actually willing to implement this protocol, KNK should get a BIP number assigned by gmaxwell and post the draft on the Bitcoin wiki for further review.

KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 02, 2013, 03:52:58 PM
 #36

Thank You! This is exactly the type of feedback i was looking

The commands for get LEDs, temps and get/set clocks and voltages (listed in my second post here) will be added too, but i wanted to hear first if there is any preference for some of them to be optional or recommended for implementation.
Also i wanted to get some feedback about the EngineID idea as identification for each of them - not to replace the same text in each command later.
For the rest:

 "when a job has been started ..." - most of the MH will probably not have them implemented, but i will add them as 'Debug commands' section ... probably separate command for each one with "DebugXXX,1" for On and "DebugXXX,0" for Off

 "which specific slave board and chip found the nonce" - will add it as optional parameter for GotNonce (EngineID after timestamp)

 About error checking - good catch 10x ... the idea was that MS will verify the nonce and have it's own information, but at least for BF chips there is a need for the driver to test several nonces, so it will be double work to do that again ... maybe 'TestOK'/'TestNA'  as mandatory parameter with the returned nonce after JobID (before nonce) to indicate that the nonce was tested, so it can be hardcoded string
 For other errors like communication problems and bad nonces - also debug on/off or recommended for implementation as GotError,EngineID,ErrCode[.ErrDescr] with a list of default codes ?
 I think the later is better and maybe with status - triggered on/off or counter, but then it will be one way information only or may add GetErrors/ClearErrors ... will think a bit more on the subject and will see what i will came with

EDIT: instead of 'TestOK'/'TestNA', i think returning 0 or the share diff is a much better idea, as MS will still need it and will have to DblSha() anyway if ommited

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
cscape
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
September 02, 2013, 04:14:27 PM
 #37

Here we go....

The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.

And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.

Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway.  A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.

Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
September 02, 2013, 04:30:24 PM
 #38

Here we go....

The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.

And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.

Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway.  A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.
Rather, the driver is the non-common component here. Users don't want different applications and interfaces for each of their devices.
BFGMiner has this common driver abstraction already in place.

cscape
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
September 02, 2013, 04:55:02 PM
 #39

Users don't want different applications and interfaces for each of their devices.
That depends. If the two devices are completely different in their feature set, I'd rather have two applications open, than one common one that shoehorns everything into the same format that either throws away a lot of features, or requires an overly complex specification to capture all possibilities.

Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
KNK
Hero Member
*****
Online Online

Activity: 684
Merit: 501


View Profile
September 02, 2013, 06:26:35 PM
 #40

That's why VersionString was introduced as required field:
 Manufacturers will implement only Work and gotNonce, because that's all they care about, but ...
 Developers and users from the community will add more and more actions and logic behind them and if at at least some of the optional commands are available as direct translation to some registers based on EngineID translation - the software will be able to manage the hardware based on the VersionString, no matter how old is the driver implementation used from the user.

or at least that's the idea and end result i am aiming at Smiley

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
Pages: « 1 [2] 3 4 »  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!