Unified miners communication protocol

[KNK]

@kakobrekla are you mining hardware or mining software developer?

[1714116551]

1714116551

[1714116551]

1714116551

[1714116551]

1714116551

[1714116551]

1714116551

[1714116551]

1714116551

[1714116551]

1714116551

[KNK]

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

[kano]

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
https://bitcointalk.org/index.php?topic=294499.0

[KNK]

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.

[cscape]

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.

[KNK]

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.

[cscape]

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

[KNK]

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.

[cscape]

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.

[Luke-Jr]

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]

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.

[kano]

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

[KNK]

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

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

[cscape]

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.

[KNK]

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