[DIY] - Reward $100 | Antminer S1/S3 Blade on Raspberry Pi

[pekatete]

OK, just to clarify that we are all running these boards using the correct settings.
Having re-visited the cgminer site, I established that the --bmsc-options switch takes the following parameters:
--bmsc-options baud:miners:asic:timeout:freq

The parameter names are self explanatory, though I decided to take it upon myself to define miners as the number of boards; Thus, revisiting the Antminer S1 FAQ pdf file, I gleaned the settings for different hex frequencies / timeouts and added the respective string to the startup of cgminer (I am using version 3.8.5 under windows, but the same string should work on any platform).

Frequency	Initialisation string
200MHz	--bmsc-options 115200:1:32:94:0581 --lowmem
225MHz	--bmsc-options 115200:1:32:63:0881 --lowmem
250MHz	--bmsc-options 115200:1:32:56:0981 --lowmem
275MHz	--bmsc-options 115200:1:32:51:0A81 --lowmem
300MHz	--bmsc-options 115200:1:32:47:0B81 --lowmem
400MHz	--bmsc-options 115200:1:32:35:4F81 --lowmem

The frequencies / initialisation strings are by no means exhaustive, more importantly, the above initialisation strings assume you have one board connected! If you have more than one board, then change the number to match, i.e running 3 boards with the 400MHz string, change to:
 --bmsc-options 115200:3:32:35:4F81 --lowmem

I also wonder whether we can run a couple (maybe more) in parallel / serial off one connector by changing the number of asics, i.e, for the 400MHz string, rather than change the board number to 3, change the asics number multiplied by 3 e.g --bmsc-options 115200:1:96:35:4F81 --lowmem

[CHAOSiTEC]

OK, just to clarify that we are all running these boards using the correct settings.
Having re-visited the cgminer site, I established that the --bmsc-options switch takes the following parameters:
--bmsc-options baud:miners:asic:timeout:freq

The parameter names are self explanatory, though I decided to take it upon myself to define miners as the number of boards; Thus, revisiting the Antminer S1 FAQ pdf file, I gleaned the settings for different hex frequencies / timeouts and added the respective string to the startup of cgminer (I am using version 3.8.5 under windows, but the same string should work on any platform).

Frequency	Initialisation string
200MHz	--bmsc-options 115200:1:32:94:0581 --lowmem
225MHz	--bmsc-options 115200:1:32:63:0881 --lowmem
250MHz	--bmsc-options 115200:1:32:56:0981 --lowmem
275MHz	--bmsc-options 115200:1:32:51:0A81 --lowmem
300MHz	--bmsc-options 115200:1:32:47:0B81 --lowmem
400MHz	--bmsc-options 115200:1:32:35:4F81 --lowmem

The frequencies / initialisation strings are by no means exhaustive, more importantly, the above initialisation strings assume you have one board connected! If you have more than one board, then change the number to match, i.e running 3 boards with the 400MHz string, change to:
 --bmsc-options 115200:3:32:35:4F81 --lowmem

I also wonder whether we can run a couple (maybe more) in parallel / serial off one connector by changing the number of asics, i.e, for the 400MHz string, rather than change the board number to 3, change the asics number multiplied by 3 e.g --bmsc-options 115200:1:96:35:4F81 --lowmem

bmsc only takes 2 colon seperated options: baud speed, and timing

Code:

static void get_options(int this_option_offset, struct cgpu_info *bmsc, int *baud, float *readtimeout)
{
	char buf[BUFSIZ+1];
	char *ptr, *comma, *colon, *colon2;
	enum sub_ident ident;
	size_t max;
	int i, tmp;
	float tmpf;

	if (opt_bmsc_options == NULL)
		buf[0] = '\0';
	else {
		ptr = opt_bmsc_options;
		for (i = 0; i < this_option_offset; i++) {
			comma = strchr(ptr, ',');
			if (comma == NULL)
				break;
			ptr = comma + 1;
		}

		comma = strchr(ptr, ',');
		if (comma == NULL)
			max = strlen(ptr);
		else
			max = comma - ptr;

		if (max > BUFSIZ)
			max = BUFSIZ;
		strncpy(buf, ptr, max);
		buf[max] = '\0';
	}

	ident = usb_ident(bmsc);
	switch (ident) {
		case IDENT_ICA:
		case IDENT_BLT:
		case IDENT_LLT:
			*baud = BMSC_IO_SPEED;
			break;
		case IDENT_AMU:
			*baud = BMSC_IO_SPEED;
			break;
		case IDENT_CMR1:
			*baud = BMSC_IO_SPEED;
			break;
		case IDENT_CMR2:
			*baud = BMSC_IO_SPEED;
			break;
		default:
			quit(1, "Bmsc get_options() called with invalid %s ident=%d",
				bmsc->drv->name, ident);
	}

	if (*buf) {
		colon = strchr(buf, ':');
		if (colon)
			*(colon++) = '\0';

		if (*buf) {
			tmp = atoi(buf);
			switch (tmp) {
			case 115200:
				*baud = 115200;
				break;
			case 57600:
				*baud = 57600;
				break;
			default:
				quit(1, "Invalid bmsc-options for baud (%s) must be 115200 or 57600", buf);
			}
		}

		if (colon && *colon) {
			tmpf = atof(colon);
			if (tmpf > 0) {
				*readtimeout = tmpf/100;
			} else {
				quit(1, "Invalid bmsc-options for timeout (%s) must be > 0", colon);
			}
		}
	}
}

that options line, is correct for bitmain driver, but you cannot use it that way, since, as j4bberwock has figured out, all the chips are hardwired to a specific address, which is same on each board

[sobe-it]

I also wonder whether we can run a couple (maybe more) in parallel / serial off one connector by changing the number of asics, i.e, for the 400MHz string, rather than change the board number to 3, change the asics number multiplied by 3 e.g --bmsc-options 115200:1:96:35:4F81 --lowmem

I tried parallel running with no options and a bunch of options, couldn't set freq to start hashing. Some where I  this thread somebody said it wouldn't work because of duplicate chip I'd or something like that. Maybe it can be coded to work... not sure.

[pekatete]

bmsc only takes 2 colon seperated options: baud speed, and timing

that may be the case for later versions of cgminer, but most likely not for the pre-compiled 3.8.5 which I am using. I mentioned earlier in the thread that version 3.8.5 would throw an error if I gave it a fraction as a parameter to the --bmsc-options line, strangely, the error was that the option had to be greater than zero! So there goes ....

that options line, is correct for bitmain driver, but you cannot use it that way, since, as j4bberwock has figured out, all the chips are hardwired to a specific address, which is same on each board

I have already seen that observation made here and also had the same result when I tried it (can not try it for now as I only have one board to play with!).

I am not an electrical engineer, however, I believe that if 2 boards are connected in parallel and powered by the same PSU line (applicable to those who have undervolted), then given an increased resistance in the parallel connection from one board to the other (via the connection cable / line .... not sure how long ..), then the board furthest away should return different chip addresses from the nearest board. Again since I am not an engineer, I can not recall where I read this thus can't give reference material.

[pekatete]

I tried parallel running with no options and a bunch of options, couldn't set freq to start hashing. Some where I  this thread somebody said it wouldn't work because of duplicate chip I'd or something like that. Maybe it can be coded to work... not sure.

I know because I too tried running it in parallel and said as much, but having the option to set the number of chips / boards (at least in the earlier versions of cgminer), coupled with my distant memory of how addressing works with hardware, I believe this can be done (and that is why I tried it in the first instance).

Point is, if anyone can, give it a shot again and update the thread! I'll most probably be in a position to do this next week when I get my set of boards (and will update the thread).

[CHAOSiTEC]

bmsc only takes 2 colon seperated options: baud speed, and timing

that may be the case for later versions of cgminer, but most likely not for the pre-compiled 3.8.5 which I am using. I mentioned earlier in the thread that version 3.8.5 would throw an error if I gave it a fraction as a parameter to the --bmsc-options line, strangely, the error was that the option had to be greater than zero! So there goes ....

The problem with that, is the timing is in x times of 100 ms, that is one of the changes done to my git repo

that options line, is correct for bitmain driver, but you cannot use it that way, since, as j4bberwock has figured out, all the chips are hardwired to a specific address, which is same on each board

I have already seen that observation made here and also had the same result when I tried it (can not try it for now as I only have one board to play with!).

I am not an electrical engineer, however, I believe that if 2 boards are connected in parallel and powered by the same PSU line (applicable to those who have undervolted), then given an increased resistance in the parallel connection from one board to the other (via the connection cable / line .... not sure how long ..), then the board furthest away should return different chip addresses from the nearest board. Again since I am not an engineer, I can not recall where I read this thus can't give reference material.

It is possible to change the hardware adresses of the chips, but the problem is, you will need to do so, at a per chip basis, in hardware, since the chips are hardwired to a specific address at the pinouts, you will need to change that, for all of them, else the chip will not know it is not being "talked to" by the software.., or, if you add i micro controller in between board 1 and 2, that would translate the hardware addresses from a different range, but then we are back to using cp2102s moneywise.

increased resistance wont help, its a digital signal, which is either 1 or 0, if it was an analog one, you could

[pekatete]

bmsc only takes 2 colon seperated options: baud speed, and timing

that may be the case for later versions of cgminer, but most likely not for the pre-compiled 3.8.5 which I am using. I mentioned earlier in the thread that version 3.8.5 would throw an error if I gave it a fraction as a parameter to the --bmsc-options line, strangely, the error was that the option had to be greater than zero! So there goes ....

The problem with that, is the timing is in x times of 100 ms, that is one of the changes done to my git repo

that options line, is correct for bitmain driver, but you cannot use it that way, since, as j4bberwock has figured out, all the chips are hardwired to a specific address, which is same on each board

I have already seen that observation made here and also had the same result when I tried it (can not try it for now as I only have one board to play with!).

I am not an electrical engineer, however, I believe that if 2 boards are connected in parallel and powered by the same PSU line (applicable to those who have undervolted), then given an increased resistance in the parallel connection from one board to the other (via the connection cable / line .... not sure how long ..), then the board furthest away should return different chip addresses from the nearest board. Again since I am not an engineer, I can not recall where I read this thus can't give reference material.

It is possible to change the hardware adresses of the chips, but the problem is, you will need to do so, at a per chip basis, in hardware, since the chips are hardwired to a specific address at the pinouts, you will need to change that, for all of them, else the chip will not know it is not being "talked to" by the software.., or, if you add i micro controller in between board 1 and 2, that would translate the hardware addresses from a different range, but then we are back to using cp2102s moneywise.

increased resistance wont help, its a digital signal, which is either 1 or 0, if it was an analog one, you could

I was not speaking from a position of certain knowledge as clearly stated in my last post, but if you are then that is settled. However, if you are speculating, then there surely is no harm in trying (as I certainly will do when I can, unless / even if otherwise certified).
But you raise an interesting alternative, i.e an mcu between the boards ...... I wonder!

[CHAOSiTEC]

bmsc only takes 2 colon seperated options: baud speed, and timing

that may be the case for later versions of cgminer, but most likely not for the pre-compiled 3.8.5 which I am using. I mentioned earlier in the thread that version 3.8.5 would throw an error if I gave it a fraction as a parameter to the --bmsc-options line, strangely, the error was that the option had to be greater than zero! So there goes ....

The problem with that, is the timing is in x times of 100 ms, that is one of the changes done to my git repo

that options line, is correct for bitmain driver, but you cannot use it that way, since, as j4bberwock has figured out, all the chips are hardwired to a specific address, which is same on each board

I have already seen that observation made here and also had the same result when I tried it (can not try it for now as I only have one board to play with!).

I am not an electrical engineer, however, I believe that if 2 boards are connected in parallel and powered by the same PSU line (applicable to those who have undervolted), then given an increased resistance in the parallel connection from one board to the other (via the connection cable / line .... not sure how long ..), then the board furthest away should return different chip addresses from the nearest board. Again since I am not an engineer, I can not recall where I read this thus can't give reference material.

It is possible to change the hardware adresses of the chips, but the problem is, you will need to do so, at a per chip basis, in hardware, since the chips are hardwired to a specific address at the pinouts, you will need to change that, for all of them, else the chip will not know it is not being "talked to" by the software.., or, if you add i micro controller in between board 1 and 2, that would translate the hardware addresses from a different range, but then we are back to using cp2102s moneywise.

increased resistance wont help, its a digital signal, which is either 1 or 0, if it was an analog one, you could

I was not speaking from a position of certain knowledge as clearly stated in my last post, but if you are then that is settled. However, if you are speculating, then there surely is no harm in trying (as I certainly will do when I can, unless / even if otherwise certified).
But you raise an interesting alternative, i.e an mcu between the boards ...... I wonder!

Your more than welcome to try, no harm in that, ive tried myself, i even got 64 chips to speak back to me, and i thought well, im on to something, but then i started looking into the code, it sends out the  set clockspeed commands, but doesnt bother to register what addresses talk back, so it gets a ok from 64 chips, but when it comes to hashing, it would give me equal amounts of duplicate and accepted, basically to chips are hashing the same thing..

with a mcu it would be possible, but i think pricewise it would be overkill..

i would love to be able to piggyback my boards, since i have 15 that are not being used at the moment, only 5 hashing away (only have 5x cp2102s

[pekatete]

Your more than welcome to try, no harm in that, ive tried myself, i even got 64 chips to speak back to me, and i thought well, im on to something, but then i started looking into the code, it sends out the  set clockspeed commands, but doesnt bother to register what addresses talk back, so it gets a ok from 64 chips, but when it comes to hashing, it would give me equal amounts of duplicate and accepted, basically to chips are hashing the same thing..

You left out some pertinent facts there. I say thus because I did the same, and though I did NOT get exactly what you describe, aka equal amounts of duplicate and accepted, the way the code sends work to the chips is based on the number of chips the code thinks (assumes / knows) are there. And like you rightly point out, apart from the code acknowledging receipt of clockspeed setting from the different addresses, it does nothing with the returned addresses and does not send out work to those specific addresses. So, what are we missing there .... ?

with a mcu it would be possible, but i think pricewise it would be overkill..

i would love to be able to piggyback my boards, since i have 15 that are not being used at the moment, only 5 hashing away (only have 5x cp2102s

That is a very subjective statement, we don't know what the board being worked on will cost, and we also know MCU's do not cost an arm and a leg.

[CHAOSiTEC]

Your more than welcome to try, no harm in that, ive tried myself, i even got 64 chips to speak back to me, and i thought well, im on to something, but then i started looking into the code, it sends out the  set clockspeed commands, but doesnt bother to register what addresses talk back, so it gets a ok from 64 chips, but when it comes to hashing, it would give me equal amounts of duplicate and accepted, basically to chips are hashing the same thing..

You left out some pertinent facts there. I say thus because I did the same, and though I did NOT get exactly what you describe, aka equal amounts of duplicate and accepted, the way the code sends work to the chips is based on the number of chips the code thinks (assumes / knows) are there. And like you rightly point out, apart from the code acknowledging receipt of clockspeed setting from the different addresses, it does nothing with the returned addresses and does not send out work to those specific addresses. So, what are we missing there .... ?

with a mcu it would be possible, but i think pricewise it would be overkill..

i would love to be able to piggyback my boards, since i have 15 that are not being used at the moment, only 5 hashing away (only have 5x cp2102s

That is a very subjective statement, we don't know what the board being worked on will cost, and we also know MCU's do not cost an arm and a leg.

it does in fact send out work, specific to each chip, else they would all work on exactly the same, and therefor find the same solution

the problem is, that out of the address range, only the first 32 chips are correctly addressed, so if i send work to chip 8f-blade1 then that work would also arrive at 8f-blade2 and since we cannot address them directly apart from eachother, there would be no workable solution in  giving work to chip-blade1, but not the other chip-blade2.. hence the need for either mcu, or cp210x..

regarding price, i think i remember something like 15 - 20 dollars for 4 connecter, so lets say 25 dollars for the 8 connector, including assembly.. if we first had to develop, yet another solution, it would take even more time, and in this case, time IS money :-p

[pekatete]

the problem is, that out of the address range, only the first 32 chips are correctly addressed, so if i send work to chip 8f-blade1 then that work would also arrive at 8f-blade2 and since we cannot address them directly apart from eachother, there would be no workable solution in  giving work to chip-blade1, but not the other chip-blade2.. hence the need for either mcu, or cp210x..

I can fit that logic perfectly in my thinking, but my question (from an ignorant point of view, which I actually am), are you speculating / extrapolating regurgitated statements or stating facts there?

regarding price, i think i remember something like 15 - 20 dollars for 4 connecter, so lets say 25 dollars for the 8 connector, including assembly.. if we first had to develop, yet another solution, it would take even more time, and in this case, time IS money :-p

I actually think that this can be a solution to a multitude other scenarios, bitcoin mining wise, so the haste of time could be misplaced. And now that you mentioned the logic of the mcu, there is an out of the box solution that matches / suits this. I did mention in one of my earlier posts about the bifury protocol .....

[CHAOSiTEC]

the problem is, that out of the address range, only the first 32 chips are correctly addressed, so if i send work to chip 8f-blade1 then that work would also arrive at 8f-blade2 and since we cannot address them directly apart from eachother, there would be no workable solution in  giving work to chip-blade1, but not the other chip-blade2.. hence the need for either mcu, or cp210x..

I can fit that logic perfectly in my thinking, but my question (from an ignorant point of view, which I actually am), are you speculating / extrapolating regurgitated statements or stating facts there?

Well, ran out of cp2102 usbs





edit: now stable at 252 GHs
315 Watt / 252 GHs = 1.25 W/GH

Your prototype will be posted on wednesday. tomorrow will be bank holidays for end of WW1.
I had a look at a few things regarding the hardware of the blades.
Each chip have an address defined on 8 pins.
each board will have the following addresses:
00-08
10-18
20-28
...
F0-F8
Linking both boards in serial shouldn't work since there will be 2 chips with the same address.
And I'm not sure parallel would work for the same reason.
If I understand correctly, the chips aren't pushing the results but are waiting for the result to be read from them.
if you ask for chip A8 result, you will have 2 results returned, and I'm no sure it will be something readable by software or some random garbage mixed from both chips.
Initializing the chips might not work for the same reason, since you are expecting an answer from the chips.

regarding bifury protocol, im not familiar with it, so i will have to do some research

edit:
i see it runs spi, so you would still need an mcu to convert between ttl <-> spi interfaces for each board

hmm thinking out loud here, IF you could add a delay to each board, say 5 or 10 ms then it *Could* be possible, if the software was set up to recieve NumberOfBlades*results

but you would still need some logic to handle that, including a small cache since your asking the chips to read the data, and then get the first result, then the 2nd result etc

[pekatete]

<snip> ....  </snip>
I had a look at a few things regarding the hardware of the blades.
Each chip have an address defined on 8 pins.
each board will have the following addresses:
00-08
10-18
20-28
...
F0-F8
Linking both boards in serial shouldn't work since there will be 2 chips with the same address.
And I'm not sure parallel would work for the same reason.
If I understand correctly, the chips aren't pushing the results but are waiting for the result to be read from them.
if you ask for chip A8 result, you will have 2 results returned, and I'm no sure it will be something readable by software or some random garbage mixed from both chips.
Initializing the chips might not work for the same reason, since you are expecting an answer from the chips.

1. the chips do push the result, and should have the result within the timeout for the respective frequency. I know this because I run some tests via a com port under windows.
2. so you do NOT ask for a result, you wait for the result within the timeout of the freq, and that is where that golden nonce test comes in! You send the golden nonce which you know has a result, and if it does not return one, whilst the chip is still "cold", then abort on this golden HW!
3. We both know that when you connect 2 boards in parallel, you get frequency status confirmation(s) from both boards, so again there J4bberwock was mistaken
But more to the point, yes for now we are trumped by that very same issue and I think the mcu solution would address that.

regarding bifury protocol, im not familiar with it, so i will have to do some research

OK .....

[CHAOSiTEC]

1. the chips do push the result, and should have the result within the timeout for the respective frequency. I know this because I run some tests via a com port under windows.
2. so you do NOT ask for a result, you wait for the result within the timeout of the freq, and that is where that golden nonce test comes in! You send the golden nonce which you know has a result, and if it does not return one, whilst the chip is still "cold", then abort on this golden HW!
3. We both know that when you connect 2 boards in parallel, you get frequency status confirmation(s) from both boards, so again there J4bberwock was mistaken
But more to the point, yes for now we are trumped by that very same issue and I think the mcu solution would address that.

the problem is you need to assign the chips with new work,before they have finished the old work, else they would go idle, and the chips dont signal when they are done, you have to check that yourself, so you need to read the chips .. but yes, mcu would solve all these challenges :-p

[pekatete]

1. the chips do push the result, and should have the result within the timeout for the respective frequency. I know this because I run some tests via a com port under windows.
2. so you do NOT ask for a result, you wait for the result within the timeout of the freq, and that is where that golden nonce test comes in! You send the golden nonce which you know has a result, and if it does not return one, whilst the chip is still "cold", then abort on this golden HW!
3. We both know that when you connect 2 boards in parallel, you get frequency status confirmation(s) from both boards, so again there J4bberwock was mistaken
But more to the point, yes for now we are trumped by that very same issue and I think the mcu solution would address that.

the problem is you need to assign the chips with new work,before they have finished the old work, else they would go idle, and the chips dont signal when they are done, you have to check that yourself, so you need to read the chips .. but yes, mcu would solve all these challenges :-p

You are mis-understanding the context of that statement.
1. If the chip returns early, i.e within the timeout, then you can send new work. If the work is subdivided amongst several chips (as is the case with the S1 boards), then you need to wait until the timeout has expired. If one chip returns early, do NOT issue new work else it will cancel all the work still progressing on other chips. So you have to wait for the timeout to expire and let some chips sit idle if they returned a result early UNLESS you can send work to individual chips (which I have not seen / discovered yet in the cgminer code!).

And NO, you do not have to read the chip for the result, but it could be that you can read the chip; again, I have not yet disovered this code in cgminer, but if you have, please share.

[CHAOSiTEC]

1. the chips do push the result, and should have the result within the timeout for the respective frequency. I know this because I run some tests via a com port under windows.
2. so you do NOT ask for a result, you wait for the result within the timeout of the freq, and that is where that golden nonce test comes in! You send the golden nonce which you know has a result, and if it does not return one, whilst the chip is still "cold", then abort on this golden HW!
3. We both know that when you connect 2 boards in parallel, you get frequency status confirmation(s) from both boards, so again there J4bberwock was mistaken
But more to the point, yes for now we are trumped by that very same issue and I think the mcu solution would address that.

the problem is you need to assign the chips with new work,before they have finished the old work, else they would go idle, and the chips dont signal when they are done, you have to check that yourself, so you need to read the chips .. but yes, mcu would solve all these challenges :-p

You are mis-understanding the context of that statement.
1. If the chip returns early, i.e within the timeout, then you can send new work. If the work is subdivided amongst several chips (as is the case with the S1 boards), then you need to wait until the timeout has expired. If one chip returns early, do NOT issue new work else it will cancel all the work still progressing on other chips. So you have to wait for the timeout to expire and let some chips sit idle if they returned a result early UNLESS you can send work to individual chips (which I have not seen / discovered yet in the cgminer code!).

And NO, you do not have to read the chip for the result, but it could be that you can read the chip; again, I have not yet disovered this code in cgminer, but if you have, please share.

driver-bmsc.c:

// Bmsc doesn't send a completion message when it finishes
// the full nonce range, so to avoid being idle we must abort the
// work (by starting a new work item) shortly before it finishes
//
// Thus we need to estimate 2 things:
//   1) How many hashes were done if the work was aborted
//   2) How high can the timeout be before the Bmsc is idle,
//      to minimise the number of work items started
//   We set 2) to 'the calculated estimate' - BMSC_READ_REDUCE
//   to ensure the estimate ends before idle

[pekatete]

1. the chips do push the result, and should have the result within the timeout for the respective frequency. I know this because I run some tests via a com port under windows.
2. so you do NOT ask for a result, you wait for the result within the timeout of the freq, and that is where that golden nonce test comes in! You send the golden nonce which you know has a result, and if it does not return one, whilst the chip is still "cold", then abort on this golden HW!
3. We both know that when you connect 2 boards in parallel, you get frequency status confirmation(s) from both boards, so again there J4bberwock was mistaken
But more to the point, yes for now we are trumped by that very same issue and I think the mcu solution would address that.

the problem is you need to assign the chips with new work,before they have finished the old work, else they would go idle, and the chips dont signal when they are done, you have to check that yourself, so you need to read the chips .. but yes, mcu would solve all these challenges :-p

You are mis-understanding the context of that statement.
1. If the chip returns early, i.e within the timeout, then you can send new work. If the work is subdivided amongst several chips (as is the case with the S1 boards), then you need to wait until the timeout has expired. If one chip returns early, do NOT issue new work else it will cancel all the work still progressing on other chips. So you have to wait for the timeout to expire and let some chips sit idle if they returned a result early UNLESS you can send work to individual chips (which I have not seen / discovered yet in the cgminer code!).

And NO, you do not have to read the chip for the result, but it could be that you can read the chip; again, I have not yet disovered this code in cgminer, but if you have, please share.

driver-bmsc.c:

// Bmsc doesn't send a completion message when it finishes
// the full nonce range, so to avoid being idle we must abort the
// work (by starting a new work item) shortly before it finishes
//
// Thus we need to estimate 2 things:
//   1) How many hashes were done if the work was aborted
//   2) How high can the timeout be before the Bmsc is idle,
//      to minimise the number of work items started
//   We set 2) to 'the calculated estimate' - BMSC_READ_REDUCE
//   to ensure the estimate ends before idle

That is correct, and I am sure you read it in its proper context now.
1. It does not send a completion message (it only returns a result if it finds one) so you have to set a timeout.
2. You do not need a completion message if it returns (because that is the completion). With a single chip, simply send new work, but this is a chain, and that is why they calculate the estimate and factor in a reduction (maybe their tests showed that bitmain's timeouts were generous thus the BMSC_READ_REDUCE)
Most important is the context that I refered to in your last post and the cgminer code sets the BMSC_READ_REDUCE to reduce the timeout so the chip (really meaning the chain since this is in bmsc aka bitmain single chain mode) does not sit idle.
NOTE: That does not mean that individual chips within the chain never sit idle, e.g if chip 1 finds a result in the first item of its assigned range and returns, say within 8ms whereas the timeout is 20ms with a BMSC_READ_REDUCE of 3ms, then chip 1 will sit idle for 9ms.

[HerbPean]

Damm ! Already received my Cp2102 but I haven't remove the resistance and installed my potentiometer on my boards yet ! It's kind of tricky, i'm use to soldering and even my co-woker who are good to it find this manipulation tricky

tomorrow, I will try

EDIT: I just saw a photo where they don't remove the resistance ? Good idea or bad ?

[jeppe]

Finally got my boards!!
All nice and packed in anti static bags except two of them.
willing to let some of them go as i have 18 boards
Most of them are 2013s and some 2014s models
can include 6X heat sinks (in picture)



only need a few for my project.
Im in the us and can ship tomorrow, us only!
pm me how manny u want and at what price the more the cheeper!
would also trade some for a prototype board that supports 8+ boards
The more people who are into this project the faster it will go!
thanks,
JT

[HerbPean]

Wish you were in Canada