Pages:
Author

Topic: [DIY] - Reward $100 | Antminer S1/S3 Blade on Raspberry Pi - page 16. (Read 82179 times)

legendary
Activity: 1358
Merit: 1002
hero member
Activity: 840
Merit: 1000
Allright after futher talking with co-worker at my job. The capacitor on the board is a Tatalum 107A.

100uF 10Volt, it is not the same as the one on the schema. I guess I have an older rev of the board.

I'm back to "work" after some serious troubles with my laptop.
8 or so years old, freezing every now and then, throwing it at the wall, stepping on it and a few other things didn't help. Screen was tunring off every 7 minutes, so I ordered a new one that I just got yesterday.
https://translate.google.com/translate?sl=fr&tl=en&js=y&prev=_t&hl=fr&ie=UTF-8&u=http%3A%2F%2Feshop.asus.com%2Ffr-FR%2Fproduits-reconditionnes%2Fordinateurs-portables-reconditionnes%2Fasus-g750jh-ordinateur-portable-reconditionn-17-3-intel-core-i7-4700hq-32gb-ram-750gb-hdd-256gb-ssd-eur-fr-fr-90nb0182-m01700.html&edit-text=

Time to reinstall everything needed, and windows 8 is absolutely not straightforward when you come from 2003 or vista like me.

Back on our topic, if you haven't ordered them yet, I have some, either from a 2013 rev S1 board that will be stripped to chips anyway, or maybe even new somewhere in my component racks.
They can be sent in a simple enveloppe for cheap.
When Kicad will be fully working on this new machine, I'll go back to the 8 ports prototype, hopefully, I'll be able to order a first PCB batch by the end of this week.
it will use almost the same layout, but with 2x CP2108 instead of 2x cp2102
some revised (and probably final) 2 ports boards were supposed to reach me at the beginning of this week, but as usual, once in France, they can take up to 10 days to reach me...
In the next few days, I will be able to cut mylar stencils for the SMD projects, so if anybody wants a "kit" for the controller boards later to have fun soldering it, it will be possible to have board + all components + stencil. The only thing I won't be able to provide in small quantities for cheap will be solder paste.

I'm also trying to get the 8 way flat cables manufactured for cheap. worst case would be to buy flat cables, connectors, crimp pins and DIY.
full member
Activity: 238
Merit: 100
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 Tongue

tomorrow, I will try Wink

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

As far as I know everybody see much easier and safe to undervolt with pensil. Try that way first if You unsure and do not want to break anything.
legendary
Activity: 1638
Merit: 1005
Wish you were in Canada Tongue
sr. member
Activity: 434
Merit: 251
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
legendary
Activity: 1638
Merit: 1005
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 Tongue

tomorrow, I will try Wink

EDIT: I just saw a photo where they don't remove the resistance ? Good idea or bad ?
hero member
Activity: 518
Merit: 500

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:

Quote
// 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.
legendary
Activity: 1358
Merit: 1002

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:

Quote
// 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
hero member
Activity: 518
Merit: 500

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.
legendary
Activity: 1358
Merit: 1002

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

hero member
Activity: 518
Merit: 500
....  
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 .....
legendary
Activity: 1358
Merit: 1002
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
hero member
Activity: 518
Merit: 500
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 .....
legendary
Activity: 1358
Merit: 1002

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
hero member
Activity: 518
Merit: 500

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.
legendary
Activity: 1358
Merit: 1002
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
hero member
Activity: 518
Merit: 500
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!
legendary
Activity: 1358
Merit: 1002
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
hero member
Activity: 518
Merit: 500
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).
hero member
Activity: 518
Merit: 500
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.
Pages:
Jump to: