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

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: sobe-it on November 21, 2014, 11:11:39 PM

Quote from: CHAOSiTEC on November 21, 2014, 02:25:26 AM

Quote from: sobe-it on November 20, 2014, 06:52:46 PM

how do i check that? im a noob at this stuff. the board that hashes at 1/2 speed has no VDD on string 3 and it looks like its a bad tps53355dqpr, well R41 is only registering .08V so maybe thats it.

sounds like thats your trouble point, just switch it out with a new one, as klondike_bar said, you can often get them for free, or if you have to pay for them, just buy a new one, they are not expensive :-p

(what i meant was when you start cgminer, it will throw a bunch of lines with chip numbers on, and if you start from a power off to power on, each board should report back 32 answers, thats how you can see how many of the chips are responding)

i dont see anything like that.

ok, could you do the following:

add -D 2>&1 |tee ./cgminerlog.txt (if your running linux)to the end of your cgminer command line, and let it run for 30 seconds, then post it online and give me a link to the cgminerlog.txt file

else -D >cgminerlog.txt

sobe-it

sr. member

Activity: 453

Merit: 250

Quote from: CHAOSiTEC on November 21, 2014, 02:25:26 AM

Quote from: sobe-it on November 20, 2014, 06:52:46 PM

how do i check that? im a noob at this stuff. the board that hashes at 1/2 speed has no VDD on string 3 and it looks like its a bad tps53355dqpr, well R41 is only registering .08V so maybe thats it.

sounds like thats your trouble point, just switch it out with a new one, as klondike_bar said, you can often get them for free, or if you have to pay for them, just buy a new one, they are not expensive :-p

(what i meant was when you start cgminer, it will throw a bunch of lines with chip numbers on, and if you start from a power off to power on, each board should report back 32 answers, thats how you can see how many of the chips are responding)

i dont see anything like that.

HerbPean

legendary

Activity: 1638

Merit: 1005

So mod complete ... setup completed. CP2102 working great ... getting like 50gh/s with a blade ... but

[2014-11-21 21:45:08] Accepted 0f53d094 Diff 17/16 AMU 0
[2014-11-21 21:45:08] Accepted 08e7d4ca Diff 29/16 AMU 0
[2014-11-21 21:45:08] Accepted 0474ec74 Diff 57/16 AMU 0
[2014-11-21 21:45:12] USB init, open device failed, err -12,
[2014-11-21 21:45:12] You need to install a WinUSB driver for - CMR device 3:4
[2014-11-21 21:45:12] And associate - CMR device 3:4 with WinUSB using zadig
[2014-11-21 21:45:12] See README.txt file included for help
[2014-11-21 21:45:12] Bitmain detect (3:4) failed to initialise (incorrect device?)

having this like every 5 seconds poping up.

Any idea ?

EDIT : Got it, it's my old BFL running on BFGMiner Wink

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: sobe-it on November 20, 2014, 06:52:46 PM

how do i check that? im a noob at this stuff. the board that hashes at 1/2 speed has no VDD on string 3 and it looks like its a bad tps53355dqpr, well R41 is only registering .08V so maybe thats it.

sounds like thats your trouble point, just switch it out with a new one, as klondike_bar said, you can often get them for free, or if you have to pay for them, just buy a new one, they are not expensive :-p

(what i meant was when you start cgminer, it will throw a bunch of lines with chip numbers on, and if you start from a power off to power on, each board should report back 32 answers, thats how you can see how many of the chips are responding)

klondike_bar

legendary

Activity: 2128

Merit: 1005

ASIC Wannabe

Quote from: sobe-it on November 20, 2014, 06:52:46 PM

how do i check that? im a noob at this stuff. the board that hashes at 1/2 speed has no VDD on string 3 and it looks like its a bad tps53355dqpr, well R41 is only registering .08V so maybe thats it.

i had a TPS53355 go bad on an S1 months back (when RMA was possible), and it knocked out the section of chips. Not sure if the regulator is the point of failure, but you can actually order sample components from texas instruments (including this part) and they will often ship in nextday with fedex. (Its actually really awesome of them)

sobe-it

sr. member

Activity: 453

Merit: 250

how do i check that? im a noob at this stuff. the board that hashes at 1/2 speed has no VDD on string 3 and it looks like its a bad tps53355dqpr, well R41 is only registering .08V so maybe thats it.

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: sobe-it on November 20, 2014, 05:52:03 PM

well the 3rd of 4 boards has went down. so i am now forcing myself to troubleshoot to the best of my abilities. 2 boards just dont work at all and the 3rd hashes very slow, possibly just one string of chips hashing but no light flashing. it looks like we can put leds on pin 48 and pin 49 to check each chip status, the stock led on the s1 boards are connected to the last chip on the last string. more likely just pin 49 (RF) since thats all that blinks on the s1 board as far i have seen. any help would be great, i have voltage on the big caps in between chips and these were all pencil modded to ~.8V and the resistors still measure correctly.

how many chips report back about clocksetting when you start cgminer? (after a power cycle)

sobe-it

sr. member

Activity: 453

Merit: 250

well the 3rd of 4 boards has went down. so i am now forcing myself to troubleshoot to the best of my abilities. 2 boards just dont work at all and the 3rd hashes very slow, possibly just one string of chips hashing but no light flashing. it looks like we can put leds on pin 48 and pin 49 to check each chip status, the stock led on the s1 boards are connected to the last chip on the last string. more likely just pin 49 (RF) since thats all that blinks on the s1 board as far i have seen. any help would be great, i have voltage on the big caps in between chips and these were all pencil modded to ~.8V and the resistors still measure correctly.

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

J4bberwock:

ive added the beginnings of a driver, just need the hardware, but since i wont be home for the next 12 days i wont be able to do so much, but do try the the latest with standard --enable-bmsc to see if it will use your board with the cp2108s (when you have one to test with)

edit:

Plan is when i have it up and running, to migrate the driver to the official cgminer, or at least have a git that follows the official one

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: pekatete on November 19, 2014, 10:52:47 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:46:49 AM

Quote from: pekatete on November 19, 2014, 10:41:07 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:38:31 AM

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

So did you manage to figure out how the work division is done in cgminer (for bmsc), or did you not bother to look?

work devision is setup as 1 per chip/fpga (per default) but can be set to 1,2,4,8

it basically means should i send the whole work to 1 chip, or should i split it up for x number of chips (1,2,4,8)

edit: correction - fpga based assumes split work in 2 - but that doesnt matter in this case

Strange that ...! 1,2,4 or 8 only? The S1 board (last time I checked) has 32 chips. I am not inclined to recount them again now, but I better revisit that cgminer code ....

standard is to issue 32 work orders each for its own range, instead of splitting 1 work order up over all the chips

driver-bmsc.c uses each chip as if they where all individual usb connected (chip wise handling) (singlechain)
driver-bitmain.c issues work for each individual chip, in range of max 32 chips per blade (multichain)

my blades are within bitmaintechs stated hashingspeed for undervolting/underclocking S1 at 200 MHz (two of my blades: 101,6 GHs) bitmains estimates: 102.4 GHs (see: https://bitcointalksearch.org/topic/m.7031946)

so if your going to try with multichain, you might gain aprox 0.8 GHs (0.4 GHs per blade) IF there is no wiggleroom in bitmaintechs estimates

J4bberwock

hero member

Activity: 840

Merit: 1000

Quote from: pekatete on November 19, 2014, 10:52:47 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:46:49 AM

Quote from: pekatete on November 19, 2014, 10:41:07 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:38:31 AM

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

So did you manage to figure out how the work division is done in cgminer (for bmsc), or did you not bother to look?

work devision is setup as 1 per chip/fpga (per default) but can be set to 1,2,4,8

it basically means should i send the whole work to 1 chip, or should i split it up for x number of chips (1,2,4,8)

edit: correction - fpga based assumes split work in 2 - but that doesnt matter in this case

Strange that ...! 1,2,4 or 8 only? The S1 board (last time I checked) has 32 chips. I am not inclined to recount them again now, but I better revisit that cgminer code ....

yes, 32 chips, but used as multi chain mode. it isn't the same cgminer code

pekatete

hero member

Activity: 518

Merit: 500

Quote from: CHAOSiTEC on November 19, 2014, 10:46:49 AM

Quote from: pekatete on November 19, 2014, 10:41:07 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:38:31 AM

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

So did you manage to figure out how the work division is done in cgminer (for bmsc), or did you not bother to look?

work devision is setup as 1 per chip/fpga (per default) but can be set to 1,2,4,8

it basically means should i send the whole work to 1 chip, or should i split it up for x number of chips (1,2,4,8)

edit: correction - fpga based assumes split work in 2 - but that doesnt matter in this case

Strange that ...! 1,2,4 or 8 only? The S1 board (last time I checked) has 32 chips. I am not inclined to recount them again now, but I better revisit that cgminer code ....

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: pekatete on November 19, 2014, 10:41:07 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:38:31 AM

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

So did you manage to figure out how the work division is done in cgminer (for bmsc), or did you not bother to look?

work devision is setup as 1 per chip/fpga (per default) but can be set to 1,2,4,8

it basically means should i send the whole work to 1 chip, or should i split it up for x number of chips (1,2,4,8)

edit: correction - fpga based assumes split work in 2 - but that doesnt matter in this case

pekatete

hero member

Activity: 518

Merit: 500

Quote from: CHAOSiTEC on November 19, 2014, 10:38:31 AM

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

So did you manage to figure out how the work division is done in cgminer (for bmsc), or did you not bother to look?

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: pekatete on November 19, 2014, 10:34:38 AM

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

orders / work same same, please remember my english is non native

pekatete

hero member

Activity: 518

Merit: 500

Quote from: CHAOSiTEC on November 19, 2014, 10:32:52 AM

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

Ahem ...... when to issue new work, yes.

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: pekatete on November 19, 2014, 10:17:09 AM

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

that is exactly what the wait period is about, when to issue new "orders".

pekatete

hero member

Activity: 518

Merit: 500

Quote from: CHAOSiTEC on November 19, 2014, 09:48:59 AM

well, if your correct, then im looking forward to see what you can put together

I know I am correct, well until I am corrected!
Put together something? Who said anything about that ...? Only finishing off my very own windows bitcoin miner, and as miners go not exactly re-inventing the wheel (and it won't have chrome spokes either!). But yeah, when I feel there is anything to share, you'll be in the loop!

EDIT: By-the-way, I made a mistake in my single chip anology. Even when the single chip returns early, i.e finds a result early in its range, do NOT issue new work but wait for it to finish searching its assigned range UNLESS the result that was found is the holy grail, i.e its size is 40.3G as we speak (then of-course you've solved the block!). And the wait period is ....... the timeout.

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Ive updated the git repo with support for cp2108 (since i dont have anything to test with, its experimental) ;-p

CHAOSiTEC

legendary

Activity: 1358

Merit: 1002

Quote from: pekatete on November 18, 2014, 02:44:16 PM

Quote from: CHAOSiTEC on November 18, 2014, 02:29:27 PM

Quote from: pekatete on November 18, 2014, 01:15:58 PM

Quote from: CHAOSiTEC on November 18, 2014, 01:03:11 PM

Quote from: pekatete on November 18, 2014, 12:54:33 PM

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.

well, if your correct, then im looking forward to see what you can put together

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