Re: [OPEN] Bitmine CoinCraft 28nm chip distribution (December W50, 42.5BTC/THps)
Folks, those of your considerations on chip price and their ROI potential are all valid points, but really: aren't they better placed in the mining speculation sub-forum? Let us please focus on the technical aspects here. If you don't see a potential for profitable mining rig based on this chip, by all means do not spent time or resources bothering and move on.
I am forwarding the feedback collected here to Bitmine and hope we will have an updated preliminary spec document available soon. I will also ask to put it on github, which at this state is only to keep the word given, since in its sole binary form it is not of much use being put into an SCM.
This is also some leftover from moving from a queue based work processing to the now proposed descriptor based with 4 individual work items per chip. Before, the idea was to signal the availability of results from chips within a chain by setting the RESP_BIT as long as there are results available in the output queue. With that, we would have to provide the winning nonce and some reliable ID to assign the nonce to the work items queued at host. This typically would be some hash of at least 32bit length to reduce risk of collisions. With that, we would need to provide 2x 32bit data with each READ_RESULT command.
The new approach is meant to reduce the data by those 32 bits required for the ID and with that communication delay. The JOB_ID fits into the command's spare bits, which moves the correct assignment of the winning nonce to cached jobs to the host.
So, to clarify: there is no RESP_BIT anymore, but 3 bits holding the JOB_ID for the returned result. If it is 0, there are no results available in this chain, otherwise the response provides winning nonce, JOB_ID and chip address.
A pseudo code sequence to process work and results would roughly look like this:
I am forwarding the feedback collected here to Bitmine and hope we will have an updated preliminary spec document available soon. I will also ask to put it on github, which at this state is only to keep the word given, since in its sole binary form it is not of much use being put into an SCM.
I have a question about the RESP_BIT. It seems it's only used for the 0x08 command.
[...]
Please clarify
[...]
Please clarify
This is also some leftover from moving from a queue based work processing to the now proposed descriptor based with 4 individual work items per chip. Before, the idea was to signal the availability of results from chips within a chain by setting the RESP_BIT as long as there are results available in the output queue. With that, we would have to provide the winning nonce and some reliable ID to assign the nonce to the work items queued at host. This typically would be some hash of at least 32bit length to reduce risk of collisions. With that, we would need to provide 2x 32bit data with each READ_RESULT command.
The new approach is meant to reduce the data by those 32 bits required for the ID and with that communication delay. The JOB_ID fits into the command's spare bits, which moves the correct assignment of the winning nonce to cached jobs to the host.
So, to clarify: there is no RESP_BIT anymore, but 3 bits holding the JOB_ID for the returned result. If it is 0, there are no results available in this chain, otherwise the response provides winning nonce, JOB_ID and chip address.
A pseudo code sequence to process work and results would roughly look like this:
Code:
reset_chip_chain();
for (int chip = 0; chip < chip_chain_length; chip++) {
for (int job = 0; job < 4; job++)
set_work(chip, job);
}
while (1) {
sleep_time = 2^32 / (chip_speed_in_hashes_per_second * chip_chain_length);
sleep(sleep_time);
while (1) {
result = get_result_broadcast();
if (result.job_id == 0)
break;
send_result(result);
set_work(result.chip_address, result.job_id)
}
}
for (int chip = 0; chip < chip_chain_length; chip++) {
for (int job = 0; job < 4; job++)
set_work(chip, job);
}
while (1) {
sleep_time = 2^32 / (chip_speed_in_hashes_per_second * chip_chain_length);
sleep(sleep_time);
while (1) {
result = get_result_broadcast();
if (result.job_id == 0)
break;
send_result(result);
set_work(result.chip_address, result.job_id)
}
}