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. |
|
|
|
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. |
|
|
|
<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 ..... |
|
|
|
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 ..... |
|
|
|
Can this possibly be expanded to more significant digits?
Your Contribution to the Pool < 0.01%
My number is so low!
Yep, it seems this number is simply truncated rather than rounded. I have seen my contribution stated as 0.02 then without any change to my hardware changed to 0.01 within a few hours. So there .... EDIT: Of course I know this is also dependant on the pool hashing power, but still ... |
|
|
|
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. |
|
|
|
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! |
|
|
|
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). |
|
|
|
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. |
|
|
|
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:freqThe 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 |
|
|
|
Suggestion: mobile app so we can see statistics. I'm always having to go on the website and login to check stats. I'd like to just pull it up on a app and see the details.
There has been an app for quite a while now for IOS called Bitcoincz. Go to the new developer corner and vote for a mobile app! There's already a vote on it. |
|
|
|
I can't find the statistics tab on the new site? Rewards tab ooops! Slush has the answer below! |
|
|
|
From what I saw, platinum isn't that much more efficient than gold.
M
So are you on a 110-120V or 220-240V power source? |
|
|
|
Both the C1 and S2's are in the same room, right next to each other, so the ambient temp is the same. The C1 clock speeds are the default of 250. The S2's are overclocked to 250. So, both comparison have 4 hashing boards running at 250Mhz. I'm using the exact same power supply in the tests. I just swapped the power supplies. I had the 1300W connected to one, and the 1000W connected to the other, then swapped.
I am not disputing your results, simply stating the theoretical obvious and trying to pin down the possible cause of the extra consumption. Don't forget the PSU for the C1 config is also powering the water cooling unit, which is the pump plus 3 fans.
Assuming the fans each gobble up 2 Amps each @ 12V, and so does the pump, then the extra would be 72 watts, i.e 2 fans and 1 pump, and that would also affirm your test with the 1300 supply. EDIT: Actually, it validates both tests, give or take for PSU efficiencies or lack thereof. Still, I wonder how far the C1 can be pushed ..... |
|
|
|
I have 2x S3+ that run well at 250Mhz, and I have some C1's. So I did a power comparison and am sharing my results.
Configuration MHz Setting Avg Gh/s Watts Efficiency W/Gh PSU Model
2x S3+ 250 1000 903 0.90 1000W Coolmax 80 Plus Bronze
C1 250 1000 984 0.98 1000W Coolmax 80 Plus Bronze
2x S3+ 250 1000 821 0.82 1300W Rosewill Lightening 80 Plus Gold
C1 250 1000 881 0.88 1300W Rosewill Lightening 80 Plus Gold
Notes: Actual GH/s is close to 1000. 2x S3+ averaged 504Gh/s each. The power usage for the C1 includes the "ANT C1 Mining Cooling Kit" from syscooling.com.
I wonder how far an OC'd C1 can be pushed though .... seeing it is stock rated for ~1Gh/s @ 250 (and the S3+'s were never rated that high, albeit for bitmain's assertion that most will hit 500 Gh/s), that liquid cooling may have some mileage still, what with ramping up that solo fan via the blue wire hack in tandem ........ just a thought. I was thinking that too. However, at what cost? Just because it can run at say, 1.2 TH/s, would you want to? Would the additional power usage really not make it worth while? If an S3+ overclocked to the highest uses less power than a C1 at base speed, then C1 power usage might be off the chart for OCing. M I don't think I agree with you there. Essentially a C1 is four S3 boards and the only way it can theoretically (I know we have empirical evidence above!) consume more power than 2 S3+'s at the same freq has to be something that can be rectified by a user, possibly heat handling (aka loose paste or the liquid cooling being inferior to the S3+'s, which I doubt) or voltage setting (the new firmware has this, do both the S3+ and C1 compared above have the same setting, if at all?). |
|
|
|
I have 2x S3+ that run well at 250Mhz, and I have some C1's. So I did a power comparison and am sharing my results.
Configuration MHz Setting Avg Gh/s Watts Efficiency W/Gh PSU Model
2x S3+ 250 1000 903 0.90 1000W Coolmax 80 Plus Bronze
C1 250 1000 984 0.98 1000W Coolmax 80 Plus Bronze
2x S3+ 250 1000 821 0.82 1300W Rosewill Lightening 80 Plus Gold
C1 250 1000 881 0.88 1300W Rosewill Lightening 80 Plus Gold
Notes: Actual GH/s is close to 1000. 2x S3+ averaged 504Gh/s each. The power usage for the C1 includes the "ANT C1 Mining Cooling Kit" from syscooling.com.
I wonder how far an OC'd C1 can be pushed though .... seeing it is stock rated for ~1Gh/s @ 250 (and the S3+'s were never rated that high, albeit for bitmain's assertion that most will hit 500 Gh/s), that liquid cooling may have some mileage still, what with ramping up that solo fan via the blue wire hack in tandem ........ just a thought. |
|
|
|
Not anywhere that I have seen.
Neither have I, but I never tried as I was content with the windows binary. I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:
....
Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.
You've got somewhere then with bfgminer! You probably need to set some initialisation strings to reduce / get rid of the errors. (I have to mention here that even with the "working" cgminer, errors are still abundant!) |
|
|
|
Yep, the segmentation fault is a platform specific thing ..... I don't have any insight. Try running the Bitmain S1 binary rather than compiling one yourself, there's a link in this thread to it. Are you referring to the Windows binary? This one? https://github.com/AntMiner/AntGen1/blob/master/cgminer/cgminer-run-windows-20131224.zip?raw=trueBit of a pain as I have no bare-metal install of Windows. Might try USB pass-through on my virtualbox vm today. Cheers and thanks for the help! Unfortunately I have essentially no coin to tip. That was the release I was refering to but assumed / thought they had binaries for linux as well as openwrt and windows. |
|
|
|
If you can turn off your extra debug switch(es) then I'd be in a better position seeing where you are at, can not make sense of that for now. But yes, I bet you have not seen any of thatproverbial purple smoke yet, and aren't you glad you tried it? Ha, yep! Here's the full output, no sudo but in the proper usb groups. It hangs here, no change. Green LED on board is flashing, no hashing, no further messages. As I speak, I'm compiling on the rpi to try it there too. I've tried one of the PL2303s too, same behaviour. I wait until cgminer fully starts up (displaying the full console) before I plug in the USB. [2014-11-15 10:17:49] Started cgminer 4.7.0 [2014-11-15 10:17:49] No devices detected! [2014-11-15 10:17:49] Waiting for USB hotplug devices or press q to quit [2014-11-15 10:17:49] Probing for an alive pool [2014-11-15 10:17:50] Pool 0 difficulty changed to 16 [2014-11-15 10:17:51] Network diff set to 39.6G [2014-11-15 10:18:01] -----------------start freq------------------- [2014-11-15 10:18:02] Send frequency 82098110 [2014-11-15 10:18:02] Send freq getstatus 84000400 And after some time, it segfaults out with classic "Segmentation fault (core dumped)". Yep, the segmentation fault is a platform specific thing ..... I don't have any insight. Try running the Bitmain S1 binary rather than compiling one yourself, there's a link in this thread to it. |
|
|
|
|
Show Posts
