Maybe they won't last 10 years.... Maybe only 7.... The useful lifetime of these boards is measured in months at this point...
OC FTW !
My thoughts exactly. I'm hoping for 12 months, but I am most definitely an optimist. If there was a way to OC, I'd be all over that.  There is, by replacing the regulator. Atleast one person so far has done this and has reported about 10% gains from it. It does void the warranty and does require a skilled professional to do, but is possible. |
|
|
|
 This is from the card that performs the worst. 5 Chips have problems. There are more "soldering curcuits" or whatever they are called, they appear on different spots.. any chance one could fix this? I mean a professional, but without too much work (not reironing)? Could one simply cut the pins free from each other? I don't want to damage anything, I'd rather stick with it as is, but I'm curious.. None of those are on the sides that matter. [edit] but the chip that is the other way around is something I dont know about. [edit2] I seem to have plenty of chips the other way around too and I only have one underperforming one in 32. |
|
|
|
Your cooler seems excessive, the general notion over at the Eu-thread is that the chips like to run hot, Even bitfury himself has stated this. Just for reference Im running mine without fans in 25-33c ambient. |
|
|
|
|
#bfsbsupport , sorry typo.
|
|
|
|
whats the IRC channel for bitfury ?
#bfsbsupport on Freenode seems like the english one. |
|
|
|
Yes, I do but do not see nothing wrong.
You have it pointing at a stratum capable pool and at a stratum port ? |
|
|
|
The file we want is /run/smh/.stat.log This is what they look like: http://pastebin.com/xN7t9WaHPlease note that: pastebin screws up the line lenght, all the info regarding a single chip is actually on one line. And secondly, this is a sample of that has two h-boards, the maximum is sixteen. Let me know if theres something else I can help with. [edit] btw since theres propably no nice way to time the data collection exactly when the new logs are generated (or perhaps there is, Im out of familiar waters here) I would suggest that you have the script pick up data every 330 seconds (5min 30 sec). OK, looks good. When copied over to one of my linux boxes it looks like this ( http://s15.postimg.org/z1kuze2l7/bfminer_log.jpg). I presume that there are no lines of whitespace at the beginning or end of the file. Does that look right? I was thinking that it might be better to have the script running as a cron job rather than building in a certain waiting period before sampling into the script itself, but we can do it the other way if you like. I can get the script to check the timestamp of the log file and sleep for 30 secs or so if it's the same as the previous data point in any case, so that data isn't double counted. Any preference on file format (was thinking comma separated text for easy input into excel - xml should be possible, but might take longer to get working)? Do you have any particular data headings in mind for the consolidated output? Personally I would just like larger samples of data to chew on, so hardly any preference here  |
|
|
|
What would be awesome is if someone whipped up a script that can collect larger samples of data by picking up each individual 5 min log and compiling them in to a longer one with averages. I'd personally prefer a one that shows info on every single chip.
Either this or an official statement about the need of fans and/or the temperature range which chips can withstand. spiccioli I have officially (punin said this) heard over irc that a chip was tested to hash untill the solder melted and it fell. The chip in question was heated with a soldering iron, while hashing. |
|
|
|
What would be awesome is if someone whipped up a script that can collect larger samples of data by picking up each individual 5 min log and compiling them in to a longer one with averages. I'd personally prefer a one that shows info on every single chip.
Hi Isokivi, I'd be happy to give this a go over the weekend (we do a reasonable amount of parsing of text files in bash, so it should be straightforward). However, we don't have any bitfury hardware yet (October can't come round soon enough  ), so would need some sample log files and some info on the file locations etc. Let me know if you're interested - somebody else may have done it already of course and may be able to share more quickly. The file we want is /run/smh/.stat.log This is what they look like: http://pastebin.com/xN7t9WaHPlease note that: pastebin screws up the line lenght, all the info regarding a single chip is actually on one line. And secondly, this is a sample of that has two h-boards, the maximum is sixteen. Let me know if theres something else I can help with. [edit] btw since theres propably no nice way to time the data collection exactly when the new logs are generated (or perhaps there is, Im out of familiar waters here) I would suggest that you have the script pick up data every 330 seconds (5min 30 sec). |
|
|
|
I have done 2 test runs ....
temperature was measured from the PCB.
without fans:
PCB @ 60° ... avg. Hashingrate around 41.5 GH
with fans:
PCB @ 41° ... avg. Hashingrate around 42.0 GH
So my conclusion is ... that they do work more or less the same cooled or uncooled ....
... maybee we should add some more information to the web gui ...
What would be awesome is if someone whipped up a script that can collect larger samples of data by picking up each individual 5 min log and compiling them in to a longer one with averages. I'd personally prefer a one that shows info on every single chip. |
|
|
|
What is wrong with my cards? It sometimes drops speed from 60-62 to 50 and sometimes even lower (right now its down to 40). Everything seemed fine, I switched everything back to autotune because the results were more or less the same. Stop/start doesnt help. Before restart I saw in putstat log instead of 0 qeued work numbers between 1 and 10, switchen positions randomly. After a restart it's back to: 0 1343 47 47 0 1323 39 39 [1]http://127.0.0.1:8333/ 0 1330 51 51 [2]http://127.0.0.1:8334/ any thoughts? Please note that your looking at a 5-minute sample, seems like normal variance to me. Does you pool have any stats you could use, with longer intervals ? |
|
|
|
Great answers! Thanks, Isokivi! I think the only one you missed is E) Oh, and on G) having 3 or a 9 value in the .putstat file, is that too small to be concerned or too bad? what's a reasonable range to have? The putstat.log seems to be constantly changing, for me it sits at 0 or 1 most of the time, but I have seen it as high as 40. I suppose the solution to this is to try out different pools, but I personally didnt bother moving: 1% fees and sub 0,1% rejects dont justify running to a pool with higher fees for me. |
|
|
|
When people talk about fixing "errors": A) Do they mean SPI or Miso-Errors?? Other errors?? B) Do they mean the errors shown at the bottom summary section of the log or in the upper, detail section of the log at the individual chip level?? C1) Do they mean looking at this file ---> /tmp/.best.log or at this file --> /run/shm/.stat.log ?? C2) What's the difference between these 2 files? D) Is this the file that ultimately needs to be manually edited --> /opt/bitfury/best.cnf ?? E) When I look at the file /tmp/.best.log, one of the chips I'm looking has this ChipID: "[E:F]" , what the heck does that mean? My board is numbered from 0-16 (I have m-board v1.0) and even if it was m-board v2.0, why is the second part of the ChipID a letter and not a number?? F) How do I fix each of the errors individually? Just by changing speed/auto-tunning and/or relocating boards? Which change fixes which errors? G) Punin said to verify that the queue size in /run/shm/.putstat.log to be zero. However, my file (see below) has 3 records/values (3, 0, 0) which one should I look at, only the last one?? Queue length Getworks Nonces found Nonces submitted Server IP 3 55762 32058 32055 [0]http://127.0.0.1:8332
0 0 0 0 [1]http://127.0.0.1:8333
0 0 0 0 [2]http://127.0.0.1:8334
Many thanks for clarifying these questions!!! I'm sure I'm not the only one trying to piece together all these little details.. A) In my posts and testing I have been assessing errors in general, I havent seen a large number of SPI or Miso errors at any point and havent seen changes in it. B) I've been looking at errors on a chip by chip basis when tweaking the speeds. C) the stat.log is a log thats being rewritten every 5 minutes, the best.log is the best results that autotune has reached. I started off by copying the best.log to /opt/bitfury/best.cnf, which is loaded when the miner starts. D) Yes. F) The boards with the most Miso errors should be the last ones on the 4-slot bus so they do not interfere with better boards. G) You appear to have one pool in the configuration now and it's the top one. |
|
|
|
|
I collected 68 5-minute samples of temperature, noncerate and errors yesterday and concluded that I should have enough data to reach a conclusion of some sort. But was too tired to analyse it right away. After a good night sleep I got to it. The highest measured temperature was 48.6c and the lowest measured temperature was 25.5c
To be honest after pondering over the results for a long time it would appear I've come up with a fairly decent rng.
The only concution I can reach that the boards would seem to appear to operate optimally when the air between them is 25-35c.
|
|
|
|
My power supply will not turn on and power the m-board and h-cards. It stays in standby...Any ideas?
Paperclip in use ? Green wire to black wire, any black. Needs to be in place always for the psu to run without being connected to a motherboard. |
|
|
|
I wanted to post something motivational for a change:  |
|
|
|
Are you sure? I'd say from my limited testing that stopping/starting the miner is enough for it to load a new /opt/bitfury/best.cnf
spiccioli
I can confirm this, with fairly extensive testing. |
|
|
|
I think they want to see the .stat.log, I will update my post shortly, did just a reboot to check if turning faulty chips (0 nonce, >1000 errors) off by switching from I to i, but this brought many chips offline. strg+z and now no chips working, needed to stop/start miner, ramping up again.
Obviously, but the interest is based on seeing at big number and not bothering to read the whole post. |
|
|
|
Anyway, I switched the last (good) hboard to the other two that didnt perform so well (16gh each), and the magic happend: 60gh coming out of these babies. Nice. Same settings for the first 32 chips (with autotune off, I tweaked it a little bit last night, but with not too good results). The third board is autotune on, performing 17.452GH/s, 19.9GH/s, 23.336GH/s. Still some more tweaking to be done, but I'm fine for now 60 GH/s? Whats your exact settings for this? H-boards. |
|
|
|
I have found that the best config is to set everything to:
aIfDSo 56
and don't care about errors. With higher speed even the bad chips find nonce sometimes.
Also setting speed to same with every chip in one bank seems to be better than setting them individually.
For me this produces about 2Ghs loss (49.x to 47.x Gh/s) when compared to the hand tuned configuration, "noncerateperchip": seems to stay 60-80 lower than what I allready had. |
|
|
|
|
Show Posts
