Topic: [GUIDE] BitFury Miner Support/Tuning - page 12. (Read 148049 times)

BFGMiner works perfectly, I'm not sure if cgminer even has support yet.

You can use set-device to change chip clock speeds:

"set-device" : ["BSB:osc6_bits=55"] sets all chips to speed 55.

"set-device" : ["BSB:osc6_bits=55","BSB2:osc6_bits=54"] sets all chips to speed 55 and all chips in slot 2 to speed 54.

"set-device" : ["BSB:osc6_bits=55","BSB2:osc6_bits=54","BSB2aa:osc6_bits=53"] sets all chips to speed 55, all chips in slot 2 to speed 54 and a certain chip in slot 2 to speed 53.

You can mix these common/slot/chip settings arbitrarily, though it might result in a very long config line.

I am looking for an alternative to chainminer and its proxy.
Whats software are best for BFSB hardware ?  BFGminer or CGMiner, other alternatives

Do CGMiner has been running stably Bitfury?
Is formed instruction on how to run CGminer on RasperryPi?

Thanks for the feedback.
With these values i still lose about 2% in wh errors (which are in fact software), but for me too any change makes it worse.
The problem (on my opinion) is that the driver is single thread and tries to guess when to send a new job to the chip (based on these values), which is not optimal as it also depends on the cpu load and varies with each cycle.

I implemented the pool switching using API and it seems to work very well, been running @159GH/s for a few hours now.

I also tried to use BFGMiner as getwork proxy for chainminer, but for some reason BFGMiner sees most of the shares as HW errors, only few get accepted. Dunno what's with that...

I tried to tune the scan delay multiplier and shift value, but they seems to be optimal already. When i set the shift value to 0x200000 (from default 0x1200000), speed sank about 5% or so... Currently running with all chips on speed 55, which seems to be 8GH/s better than the settings i use with chainminer.

I switched to imageUSB and it works quite well.  We've noticed that there might have been a 'bad batch' of SanDisk SD cards.  If you are writing a V3 image, also make sure to use an 8GB card as the 4GB ones will not write out fully.

I was having 'semaphore timeout' errors with win32diskimager in my Win7 64bit installation with 2 different (wrecked by the bitfury) SD cards and neither would format with SD CARD FORMATTER 4.0.

I loaded up my secondary Win7 32bit OS on the laptop (a Thinkpad T510) and was able to format and then image 1 SDS card. However, the second card would freeze up the formatting program around 90-100% and I got the same 'semaphore timeout' from Win32diskimager. I imagine this SD may be corrupt or damaged

I have heatsinks at the backs of the hcards and 3 12cm fans blowing, they shouldn't be too hot.

I use API to shut cgminer down, but i've seen cgminer hang randomly so it is possbile that the last stage kill -9 might shut it down wrong way...

Good all with API, i'll have to implement that later this week or weekend. For now i'll stick with stratum proxy and pools that work well with it (namely pools that allow manual difficulty setting for miners).

I don't think the chips are damaged if running at high speed ( but it also depends on the temp of course )
How do you stop cgminer?
If it is not clean shutdown - some chips may be left hashing (obviously old jobs) which may be the reason for them to remain undetected on the next start.

I don't see any reason to restart cgminer - you can enable or disable a pool from the API, so all you need to do is to feed the full list of pools/currencies on startup and disable the ones you don't want to use

I'll do some testing later. However, there was some problems with the cgminer. First, i'm running a multimining setup, which means i poll for most profitable coin from coinchoose or coinwarz and then switch miners to mine that coin. Not sure if this gives any advantage nowadays, but been tweaking it for some time. With stratum proxy this works fine, as chainminer is running uninterrupted, only the proxy is restarted. Or course there's some rejected shares when switching coins, but from chainminer's side it's mostly business as usual.

Now enter cgminer; restarting it means first shutting down the chips and then finding them again and reinitializing. This seems to crap out at some point and chips aren't found anymore. It got to a point where there was only one chip found for first board. So i shut down cgminer and fired up chainminer/stratum-proxy with previous best.cnf. Not going well, first and second boards were way below normal speeds, some chips showed only error results and speed was 0.0GH/s. Only after deleting best.cnf and /run/shm/.chip.cnf, i.e. allowing chainminer to autotune speeds, i got all boards running fine. Phew, thought i had blown something for a minute...

Anyways, some ideas what might have happened:
* constant reinitialization crapped spi or chips or something...
* this resulted some chips left in a bad state; telling them to run at the 55 speed wasn't resetting them properly
* only after setting all chips to 54 (apparently chainminer does this in autotune mode) the chips were revived and now back to hashing at previous speeds
* or could it simply be that running constantly with too high speed finally craps the chips for some reason?

So with cgminer something like first setting the speed to 54 (or maybe 50?) and only after that tuning them to full speed might keep them working properly?

That is odd.  I use the SD card formatter 4.0 for mine. It takes two passes to get the whole 4G card with overwrite but I can then re-image it just fine.

On mine, when the card fails it is ruined. I had to start with a new one both times.

hmm

also, ive been having 'semaphore timeout' errors when trying to write images with my sd card reader (internal) so i cant even reformat the bad card right now

I have a v1 M-board and I am constantly having SD corruption issues on reboot or shutdown. No fan headers here.  I just keep 3 images ready to go so I have little downtime due to software when I am messing around with the hardware.

I am getting fed up of the SD card issues. anytime the miner needs to be powered off the card seems to be wiped.

I *think* that there is a relation between the SD issues and using the fan slots on the board - it might be possible that having 2x230mm fans spin down when power is removed is causing a small amount of power to be backfed onto the RPi until the fans slow to a stop.

when i did not have fans, i could turn off the PSU without any effects on the SD card.

Thanks for the tip
If you get to much hw errors on some chips - you may need to fine tune the scan delay multiplier in driver-bitfury.c (line 210 - between 900 and 1200) and the shift value in libbitfury.c (line 631 - between 0x100000 and 0x200000) ... I think I got them right, but they may be for my specific hardware configuration

EDIT:  for per chip info check: if for some of the chips it shows different MHz on each run you will need to tweak those values above

Great, thanks. Going to leave this running for the night and see how it goes.

Also sent a small tip for your troubles.

Edit: now that i set the chip speeds as per best.cnf, i only get to 151GH/s. Oh well, just gonna run with 55 on all chips for now.

Looking at it too. Got the core dump at line 388 ... probably just uninitialised variable ... will see

EDIT: Fix committed - command line option working too

EDIT2: Now you can define the number of boards too so in bitfury-config.h for BFSB boards use:

Ah ok, i'll check the api. Btw, running at about 158.4GH/s average, using --bitfury-clockbits 55. This is right around the ballpark with chainminer and definite improvement to stratum-proxy/chainminer combo due to problems with some pools and difficulty. Great

Looking at the --bitfury-clockbits code, the slot (or bank) is needed also, as in api call, so the arg format should be like bank:chip:speed.

I am using the API to set clockbits as it can be done at any time, so i have fixed just that (not the command line options)
Run cgminer with --api-listen and use:
where the first number is the slot and the second is the chip

Allright, now it's working, thanks. Speed average 151 GH/s with the default chip speed of 42 i assume? How does this setting correlate to setting 54 in best.cnf for example? 54, scrolled down on the code 

Also i got the segfault by trying to set --bitfury-clockbits 0:55,1:55,2:55... etc. Seems the arg parsing fails? I do have ulimit set to unlimited, but all i get is this:


I'm running cgminer through shell scripts, should i run it directly to get the coredump?