[ANN] Bitfury ASIC sales in EU and Europe

[Isokivi]

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.

[dani]

Updated. I think as mickey mentioned my hboard didnt fit quite right in the first mboard, that would explain the chips coming back to life for no reason. I'll make a summary at the end of the day, when I got more time, maybe it's useful to other users.

[BTstarter]

I'm following this post longer than only today...
Thought he was doing 60 G's per board!
Thats why I was surprised about the 60 GH/s.
But if he's running on 3 boards, then I can place it.

[CryptoCluster]

My Kit has best performance after few minutes from start, before autotune starts messing with chip settings. After that everything falls down. Will it be ok to copy /run/shm/.stat.log to /opt/bitfury/best.cnf ? Or those files have different structure?

Also earlier when I have tried to modify settings I have fallen into problem. I have problem with using best.cnf for starting the miner. I made a copy of .best.log to best.cnf in /opt/bitfury directory, after that I have switched autotune off on few chips in .cnf file and saved the changes.
Then I have started the miner with console output in screen. After several minutes of mining if i open .stat.log all chips I have set to not use autotune, are set to autotune on, and have different speeds then those in /opt/bitfury/best.cnf file. Also there is no copy of best.cnf in /run/shm directory after miner starts. Am I suppose to copy best.cnf into /run/shm manually before starting the miner?

[MXRider]

My Kit has best performance after few minutes from start, before autotune starts messing with chip settings. After that everything falls down. Will it be ok to copy /run/shm/.stat.log to /opt/bitfury/best.cnf ? Or those files have different structure?

Also earlier when I have tried to modify settings I have fallen into problem. I have problem with using best.cnf for starting the miner. I made a copy of .best.log to best.cnf in /opt/bitfury directory, after that I have switched autotune off on few chips in .cnf file and saved the changes.
Then I have started the miner with console output in screen. After several minutes of mining if i open .stat.log all chips I have set to not use autotune, are set to autotune on, and have different speeds then those in /opt/bitfury/best.cnf file. Also there is no copy of best.cnf in /run/shm directory after miner starts. Am I suppose to copy best.cnf into /run/shm manually before starting the miner?

.stat.log and best.cnf have the structure. Keep in mind that .stat.log is changing. If I were you, I would copy the .best.log.

Restarting the miner does not work. You need to reboot the Pi (sudo reboot)

[CryptoCluster]

My Kit has best performance after few minutes from start, before autotune starts messing with chip settings. After that everything falls down. Will it be ok to copy /run/shm/.stat.log to /opt/bitfury/best.cnf ? Or those files have different structure?

Also earlier when I have tried to modify settings I have fallen into problem. I have problem with using best.cnf for starting the miner. I made a copy of .best.log to best.cnf in /opt/bitfury directory, after that I have switched autotune off on few chips in .cnf file and saved the changes.
Then I have started the miner with console output in screen. After several minutes of mining if i open .stat.log all chips I have set to not use autotune, are set to autotune on, and have different speeds then those in /opt/bitfury/best.cnf file. Also there is no copy of best.cnf in /run/shm directory after miner starts. Am I suppose to copy best.cnf into /run/shm manually before starting the miner?

.stat.log and best.cnf have the structure. Keep in mind that .stat.log is changing. If I were you, I would copy the .best.log.

Restarting the miner does not work. You need to reboot the Pi (sudo reboot)

Thanks for the answer. So if I understand you right, the /opt/bitfury/best.cnf will copy itself to /run/shm/best.cnf when I start the miner, but after modifying /opt/bitfury/best.cnf I must reboot the Pi?

[spiccioli]

My Kit has best performance after few minutes from start, before autotune starts messing with chip settings. After that everything falls down. Will it be ok to copy /run/shm/.stat.log to /opt/bitfury/best.cnf ? Or those files have different structure?

Also earlier when I have tried to modify settings I have fallen into problem. I have problem with using best.cnf for starting the miner. I made a copy of .best.log to best.cnf in /opt/bitfury directory, after that I have switched autotune off on few chips in .cnf file and saved the changes.
Then I have started the miner with console output in screen. After several minutes of mining if i open .stat.log all chips I have set to not use autotune, are set to autotune on, and have different speeds then those in /opt/bitfury/best.cnf file. Also there is no copy of best.cnf in /run/shm directory after miner starts. Am I suppose to copy best.cnf into /run/shm manually before starting the miner?

.stat.log and best.cnf have the structure. Keep in mind that .stat.log is changing. If I were you, I would copy the .best.log.

Restarting the miner does not work. You need to reboot the Pi (sudo reboot)

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

[Isokivi]

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.

[MXRider]

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.

Yep, seems to be working. My poor Pi, it has been rebooted several times for no reason

[Isokivi]

I wanted to post something motivational for a change:

[punin]

Update on H-card soldering issues.
I sent some H-cards to be examined and reworked, and most of them came out clean. The bridges seem to be caused by flux resin in over 95% of cases.

[CryptoCluster]

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.

Yep, seems to be working. My poor Pi, it has been rebooted several times for no reason

After rebooting best.cnf was copied into /run/shm. It looks like for first time after modifying /opt/bitfury/best.cnf you must reboot the device, and after that only miner process needs to be stopped and start again.

Thanks a lot!

[punin]

Some info on setup

Chainminer is compiled with encoded username and password that are hard coded in jobconnect.cpp. Currently miner is set to run three getwork threads to localhost 127.0.0.1:8332-8334.

Code:

hosts_t hosts[]={
		{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8332/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
		,{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8333/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
		,{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8334/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
};

If you want to use the miner without stratum proxy you may do so by setting it in the above place. However, you must first encode your miner credentials to be inserted there:

Code:

pi@bitfury01 /opt/bitfury/chainminer $ echo -n username:password | base64
dXNlcm5hbWU6cGFzc3dvcmQ=
pi@bitfury01 /opt/bitfury/chainminer $ 

Then you must copy these encoded credentials into jobconnect.cpp and rebuild the miner:

Code:

dXNlcm5hbWU6cGFzc3dvcmQ=

hosts_t hosts[]={
		{"Basic dXNlcm5hbWU6cGFzc3dvcmQ=","http://getworkpool:port/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} //
};

Save the file and make. Restart miner.

[dani]

Update on H-card soldering issues.
I sent some H-cards to be examined and reworked, and most of them came out clean. The bridges seem to be caused by flux resin in over 95% of cases.

That sounds promising, any chances one can get a dead chip caused by this error to work again by some simple process?

[CryptoCluster]

Update on H-card soldering issues.
I sent some H-cards to be examined and reworked, and most of them came out clean. The bridges seem to be caused by flux resin in over 95% of cases.

Should we follow this instructions: https://nuxx.net/wiki/Flux_Removal to clean all boards?

[spiccioli]

This is my worst performing card,

http://imgur.com/YMdcFdt,54T7aWB,8iOjWKl,Cp0EGFi

Chip 4F has a blob of semi-transparent material on one side, on I/O pins, nearly half of the chips have shorted VDD pins.

Half of the chips, 7-16, are dead and go to zero with auto-tuning while not hashing with manual tuning.

Any idea?

spiccioli

[-Redacted-]

The semi-transparent material is flux, which you might want to clean off - see up a message or two.  Shorted Vdd pins are not an issue as long as they are shorted to each other and not other pins.  Use a magnifying glass, look for solder bridges on both the front and back of the board.

[cscape]

Chip 4F has a blob of semi-transparent material on one side, on I/O pins

That's flux residue from somebody fixing a short with soldering iron.

[cscape]

Half of the chips, 7-16, are dead and go to zero with auto-tuning while not hashing with manual tuning.

Since the SPI signals form a long chain from chip to chip, there's probably a problem at chip 6 or 7. Check those extra carefully on the board. Note: the chips are numbered in white ink in the same order as in the software.

If the chips are mounted correctly, and one is broken, it could be that it prevents communication with next one in the chain. In that case, the chip could be removed, and the solder jumpers shorted. Beware: don't attempt to fix unless you've done stuff like this before.

[spiccioli]

Half of the chips, 7-16, are dead and go to zero with auto-tuning while not hashing with manual tuning.

Since the SPI signals form a long chain from chip to chip, there's probably a problem at chip 6 or 7. Check those extra carefully on the board. Note: the chips are numbered in white ink in the same order as in the software.

If the chips are mounted correctly, and one is broken, it could be that it prevents communication with next one in the chain. In that case, the chip could be removed, and the solder jumpers shorted. Beware: don't attempt to fix unless you've done stuff like this before.

Ok, I'll look at them more in depth.

I've never used a solder iron in my life, so I won't try to break it more than it already is

spiccioli