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
Topic: Unified miners communication protocol (Read 6261 times)
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.
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 theanswers 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 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
Do you guys see something wrong in the proposed protocol or something that is missing, needs some changes?
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 ...
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 ...
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. 
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.
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.
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.
But why couldn't you do that over one communication channel (per MS/MH) ?
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.
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.
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.
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.
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
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.
https://bitcointalksearch.org/topic/optimal-firmwarehardware-design-for-mining-with-cgminer-294499
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
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
@kakobrekla are you mining hardware or mining software developer?
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
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.
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
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
Example: You have 500 BF chips and you are given a single work (be it with MTime 300), but don't have nonce range division (HW limitation) and don't have NeedWork implemented. When you start you wait 1.2sec (with 200 chips idle), before sending nonces back. MS sees them coming fast and sends more, but still for 300 + a bit more until your full hashrate is reached.
So the first 5 seconds you run at half speed. Not a big deal over the lifetime of the equipment. And with 500 BF chips, you should have a better solution than running getwork to a single host anyway. 
Of more important note, I think I forgot to mention: There should probably be a single command to cancel all pending jobs ASAP, for use on block changes.
There are different kinds of cancellations however. It's useful to be able to distinguish "really, don't bother, anything more you have queued will be completely worthless, cancel even if its a pipeline flush that loses work" from "I have new work for you to start on as soon as you can without disrupting the pipeline". ... The latter you should be able to call as fast as the communication bus allows without losing hashrate as a result.
Omg, this is still going?
Jump to: