Bitcoin Forum
September 25, 2018, 04:09:37 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)
KNK
Hero Member
*****
Offline Offline

Activity: 684
Merit: 501


View Profile
September 25, 2013, 12:48:22 PM
 #61

@kakobrekla are you mining hardware or mining software developer?

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

Posts: 1537848577

View Profile Personal Message (Offline)

Ignore
1537848577
Reply with quote  #2

1537848577
Report to moderator
Make a difference with your Ether.
Donate Ether for the greater good.
SPRING.WETRUST.IO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537848577
Hero Member
*
Offline Offline

Posts: 1537848577

View Profile Personal Message (Offline)

Ignore
1537848577
Reply with quote  #2

1537848577
Report to moderator
1537848577
Hero Member
*
Offline Offline

Posts: 1537848577

View Profile Personal Message (Offline)

Ignore
1537848577
Reply with quote  #2

1537848577
Report to moderator
1537848577
Hero Member
*
Offline Offline

Posts: 1537848577

View Profile Personal Message (Offline)

Ignore
1537848577
Reply with quote  #2

1537848577
Report to moderator
KNK
Hero Member
*****
Offline Offline

Activity: 684
Merit: 501


View Profile
September 29, 2013, 10:23:53 AM
 #62

I have completed the 'debug errors command', which ended as InfoMsg. No changes for the rest of the document were made except fixing some spelling mistakes.

I have provided some more examples for the InfoMsg, to explain the Subsystem parameter.
Instead of having Voltage and Current - just Power is enough for both and the same for the rest of the subsystems (Temp+Fan=Cooling, Hashrate+Freq=Hashspeed) in order to limit their number

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

Activity: 2576
Merit: 1054


Linux since 1997 RedHat 4


View Profile
September 29, 2013, 12:36:53 PM
 #63

The draft is almost complete - there is something that bothers me with the debug errors command, which i'd like to think some more about, but the rest should be OK.
A review of the wording from a native speaker would be welcome as well as any other suggestions.
It will be great if some of the MS developers can provide a skeleton implementation for example with CPU mining or some other hardware

The fact remains, no one cares and no one will implement it, move along.
Yeah my thread is much more useful - it means: will the device mine optimally or not Smiley
https://bitcointalk.org/index.php?topic=294499.0

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
*****
Offline Offline

Activity: 684
Merit: 501


View Profile
September 29, 2013, 01:32:04 PM
 #64

Yeah my thread is much more useful
The two threads are for different aspects of the communication and implementation and so far as i can see there are no disagreements between them, but the opposite - they perfectly fit together or ... is there something that is impossible (or problematic) to do with the suggested protocol?
One of the most important things in both threads is the asynchronous workflow and i like your idea about the two communication channels ('2 pairs of end points') between MS and MH and as i was thinking not just about USB, but also for 'over the network' protocol it could be easily separated. I would prefer that it is done as an extension to the protocol for 2 TCP sockets or UDP/multicast communication later when there is a need for it.

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

Activity: 251
Merit: 250



View Profile
September 29, 2013, 05:15:30 PM
 #65

Why add unnecessary complexity with 2 pairs of endpoints, or 2 other connections? You can simply mix various kinds data in one channel, and sort it out in the application.

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

Activity: 684
Merit: 501


View Profile
September 29, 2013, 05:30:44 PM
 #66

On my opinion, latter when there will may be a need for a farm of network attached miners and proxies (or better name them Mining Managers), separation will be welcome.
For example MS/MM will multicast a work and each MH will only pick specific jobs (jobid%miners_total=miner_id) or process a specific mtime or nonce range, then it will multicast back it's messages, but there may be more than one MS/MM host to pick and process them in active/backup or similar jobs division (miner_ip%MM_total).
At that point in time there will be a need for inter nodes communication protocol (additions) too, but the same protocol can be used and simply extended as needed with new commands or parameters.

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

Activity: 251
Merit: 250



View Profile
September 29, 2013, 05:44:28 PM
 #67

But why couldn't you do that over one communication channel (per MS/MH) ?

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

Activity: 684
Merit: 501


View Profile
September 29, 2013, 06:05:11 PM
 #68

When you have many to many talking over multicast this can't be a single channel or MH will need to deal with message queue and retransmits to the backup manager etc. ... but lets think about that when the time comes - it is not part of the current protocol description.

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

Activity: 251
Merit: 250



View Profile
September 29, 2013, 06:12:41 PM
 #69

Wouldn't it make more sense to use directed data, and send each miner only the information he needs to have ? Multicast doesn't save bandwidth, because each miner needs different work anyway.

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

Activity: 2422
Merit: 1011



View Profile
September 29, 2013, 06:14:43 PM
 #70

Wouldn't it make more sense to use directed data, and send each miner only the information he needs to have ? Multicast doesn't save bandwidth, because each miner needs different work anyway.
Depends at what level you're working. If your miners are doing coinbase modifications, they could use a trick like stratum to share work.

cscape
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
September 29, 2013, 06:20:04 PM
 #71

Depends at what level you're working. If your miners are doing coinbase modifications, they could use a trick like stratum to share work.
That's true, but then they really use the exact same information, so a broadcast actually makes sense. KNK was describing a scenario where information is broadcast, but the miners only pick what's relevant to them. That's very much like your own directed traffic implementation layered over multicast.

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

Activity: 2576
Merit: 1054


Linux since 1997 RedHat 4


View Profile
September 30, 2013, 01:52:02 AM
 #72

Heh - mining using Muticast ...

I wrote/added Muticast support to cgminer a while back to supporting finding the cgminer APIs on a network.
Multicast isn't very reliable ... as is expected since it's UDP.

You'd use it for discovery, using it for sending the mining work out sounds like idle miners ...

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
*****
Offline Offline

Activity: 684
Merit: 501


View Profile
September 30, 2013, 08:18:37 AM
 #73

This was just an example and we moved talking about it instead of the protocol. Smiley

@cscape maybe if we say 2 working threads instead of 2 communication channels it will better fit. The idea is that you don't wait for the answer of your command i.e. asynchronous communication, so MS have 1 thread that 'fires and forgets' commands and then another one which is processing the answers received data no matter if it was or was not requested and maybe even not knowing what the other thread did last summer.

Do you guys see something wrong in the proposed protocol or something that is missing, needs some changes?

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

Activity: 251
Merit: 250



View Profile
September 30, 2013, 09:17:10 AM
 #74

I'll check out the protocol in more detail later, but one thing I'll ask right away... can you add the exact format for the work string and nonce/timestamp, with a few examples so people can test their implementation by feeding the same work and checking the results.


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

Activity: 684
Merit: 501


View Profile
September 30, 2013, 10:54:02 AM
 #75

It's a good suggestion, thanks.
I will add an examples section at the end with a full (virtual) 'session dump', or maybe it will be better to provide several small examples or both

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!