Blue Fury Support Thread.

[bitterdog]

yup, I did... so, R15

how I reversed that... no fking clue...

R15 is the only one that needs swapped out?

Have you tried pencil modding it?

[mikejones]

Installation tutorials for compatiable mining software.

How do I know if I need to update my firmware for my redfury? It's currently working but I'm getting a 50% error rate or is that normal for these things?? I'm also using BFGMINER with minepeon

[philipma1957]

Installation tutorials for compatiable mining software.

How do I know if I need to update my firmware for my redfury? It's currently working but I'm getting a 50% error rate or is that normal for these things?? I'm also using BFGMINER with minepeon

what is hash rate?  if you hash over 2.2gh the error rate is not a problem. if you hash under 2gh it is something to try to fix

[mikejones]

CGminer 3.7.2 on Windows 7 - 32

https://i.imgur.com/A6N5bwb.jpg

So does this mean you have 0 HW errors??

[-ck]

CGminer 3.7.2 on Windows 7 - 32

So does this mean you have 0 HW errors??

and all shows about 2.1 ~ 2.2 with or without 60% hw error.

i dont think the hw error are real per say. 3.0.99 says 0 hw error and 3.4 says 60% but speeds are the sames 2.1 or so

Not really, the hw errors are real. There isn't much point even showing the hardware error count because 60% of the data returned is garbage. It's a design flaw and, alas, monitoring that percentage serves no useful purpose. Looking for subtle inefficiencies when the bulk of the data is garbage is futile, which is why I don't even bother trying to report a hw error rate in cgminer and only show the hashrate by extrapolating it from the valid share return rate. No point saying the hashrate is 5GH when you only get 2.3GH of shares...

[Beastlymac]

How do we install on minpeon using bfgminer??

Install minepeon 2.4 then do a git pull for the updates.

[Epinnoia]

btcguilds rationale behind diffs
2 (default)
4(4+ghs)
8(8+ghs)
16(16+ghs)
32(32+ghs)
....
to
1024 (1+Ths)



so diff roughly correlates with hash rate. and hist just happens to fall in the middle of 16 and 32. if he were to add hashing to put him at 33ghs or so it btcguild would bump him to diff 32

I didn't think btcguild automatically bumps him or anyone else.  It's a setting in the worker settings that has to be changed.  When you have 25ghps, and a diff setting of only 2, you're going to lose effective hashing power due to the increased congestion and overhead.  But if you set it too high, then your worker will lose effective hashing power due to the fact that un-submitted progress is lost on any current work once a block is found by the network.  That's pretty basic stuff.  But these Fury miners seem to do much better with work diff 2.  The longer they spend on a work packet, the more likely the entire packet will be discarded due to HW errors.  It's certainly something I would test before following any rules of thumb.   Those rules of thumb generally assume things....like non-tempermental hardware...lol

It's also wise to play around with the queue size setting when you have so much ghps.

[-ck]

Sorry you have some misconceptions about the effect of mining at different difficulty so let me clear them up once and for all: It makes no difference to these devices what difficulty you mine at in either hashrate, hardware error rate, or reject rate.

[Epinnoia]

Sorry you have some misconceptions about the effect of mining at different difficulty so let me clear them up once and for all: It makes no difference to these devices what difficulty you mine at in either hashrate, hardware error rate, or reject rate.

If those random hardware errors cause the entire current work unit to fail, then it's best to keep their effect to as small a portion of work as possible.  

Let's pretend that work diff of 64 takes about 10 mins, on average, to produce an accepted result.  If you have a single hardware error in that 10 minutes, you wasted the entire 10 minutes.  If you had broken it up into 8 units of 8 diff work, you would have only lost ONE of those work units, not all 8.  Instead of losing all 64, you get 7 of the 8, or 56.  56 is better than 0, yes?

And if you're churning away at solving a work unit diff 64, and only make it to halfway (32) before a block is found by someone else....you just wasted the progress you did have (32 -- which is 'halfway'), since you can't carry that work over into the next block.

I was basing it off of what I was witnessing with my fury in bfgminer 3.5.1.  3.2.0 doesn't report the errors.  Neither does your cgminer, as well you know.

There may be some sanity checking that allows partial recovery on a HW error, but I wasn't seeing it in bfgminer 3.5.1.  I saw much lower effective rates as I increased the work unit's diff.  And yes, I let it run long enough.

[zyk0]

Sorry you have some misconceptions about the effect of mining at different difficulty so let me clear them up once and for all: It makes no difference to these devices what difficulty you mine at in either hashrate, hardware error rate, or reject rate.

If those random hardware errors cause the entire work unit to fail, then it's best to keep their effect to as small a portion of work as possible.  

Let's pretend that work diff of 64 takes about 10 mins, on average, to produce an accepted result.  If you have a single hardware error in that 10 minutes, you wasted the entire 10 minutes.  If you had broken it up into 8 units of 8 diff work, you would have only lost ONE of those work packets.  Instead of losing all 64, you get 7 of the 8, or 56.  56 is better than 0, yes?

And if you're churning away at solving a work unit diff 16, and only make it to halfway ( before a block is found by someone else....you wasted the progress you did have (8 -- which is 'halfway').

I was basing it off of what I was witnessing with my fury in bfgminer 3.5.1.  3.2.0 doesn't report the errors.  Neither does your cgminer.  

No matter what your difficulty, most hardware will return nonces at a difficulty of 1 (or less) and is up to the mining software to not bother submitting anything less than the requested difficulty of the pool.  The value paid out will assume you're working and finding these lower target nonces at rate based on probability and credit you accordingly when you submit the higher threshold one.  Yes, if the hardware malfunctions during the one time it should have found that higher difficulty, you're probably out the work of that longer time-frame, but not every failure is going to be that one particular effort and guarantee wasting that time.  Yes, you're likely to lose out a bit from this, but it's not as drastic as you're thinking.

[Epinnoia]

Yes, you're likely to lose out a bit from this, but it's not as drastic as you're thinking.

I'm not saying it is 'drastic', just noticeable.  I'm just saying it seemed to affect me disproportionately more as I increased my work diff size.  

In theory, on extensive tests, I should see no benefit to mining at diff 2 vs. diff 8 over extended periods of time.  But in actuality, I was seeing poorer results in the neighborhood of 100-150mhps.  If I am going to lose credit for my current work, I'd much rather lose 2 or 4 than 8 or 16...or 512 or 1024.  Granted, those come up less frequently.  When blocks are timed to about 10 mins, you risk losing a lot of potentially smaller submissions with higher diff settings.

If I can come up with a better way of demonstrating it, I will.  Maybe there is some other explanation for what I was observing.  *shrugs*  

my good fury produced:

At work diff 2, effective 2.11ghps.  
At work diff 4, effective 2.03ghps.  
At work diff 8, effective 1.94ghps.

Why, then, is this happening?  I ran it longer than 2 hours on each.  I suppose it could be bad luck or network conditions, so I will try each again.

[zyk0]

In theory, on extensive tests, I should see no benefit to mining at diff 2 vs. diff 8 over extended periods of time.  But in actuality, I was seeing poorer results in the neighborhood of 100-150mhps.  If I am going to lose credit for my current work, I'd much rather lose 2 or 4 than 8 or 16...or 512 or 1024.  Granted, those come up less frequently.  

If I can come up with a better way of demonstrating it, I will.  Maybe there is some other explanation for what I was observing.  *shrugs*  

my good fury produced:

At work diff 2, effective 2.11ghps.  
At work diff 4, effective 2.03ghps.  
At work diff 8, effective 1.94ghps.  

Why, then, is this happening?  I ran it longer than 2 hours on each.  I suppose it could be bad luck, so I will try each again.

What you're seeing is one of the reasons I prefer to mine at lower difficulty if I can.  It also just appears to me that I'm disproportionately finding the lower difficulty values just at eyeballing the logs.

However the statement made in

If those random hardware errors cause the entire current work unit to fail, then it's best to keep their effect to as small a portion of work as possible. 

Let's pretend that work diff of 64 takes about 10 mins, on average, to produce an accepted result.  If you have a single hardware error in that 10 minutes, you wasted the entire 10 minutes.

to me made it seem like you were expecting with 50% hardware errors your effective utility halfing if you doubled your difficulty.

Sorry for my misinterpretation of your statement.

There is a chance you could waste that entire 10 minutes block, but 1 error isn't going to guarantee that is what I was clarifying.  In fact, it should approach a probabilistically smaller of a chance at higher difficulties.

[Epinnoia]

There is a chance you could waste that entire 10 minutes block, but 1 error isn't going to guarantee that is what I was clarifying.  In fact, it should approach a probabilistically smaller of a chance at higher difficulties.

That's what I thought -- that it all balanced out in the end.  Maybe the probability of a hardware error increases depending on the work it just produced, or is just about to produce.  Higher nonces might come at a price with the chip.  I could speculate all day, so hopefully we will learn more about the actual cause of the HW errors....and, even better, fix/control/mitigate it with firmware.

[loumatrix]

I disagree in regard to running -S bigpic:all.  I am running my single BF with bfgminer 3.5.1, with the 'alfa driver' provided by Beastlymac, through a batch file called #MINE.bat on Win7 64, the content of this batch file is
bfgminer.exe -S bigpic:all -o [pool url] -u [user name] -p [password]

You can use -S bigpic:all as long as you don't also have USB Block Erupters.  As has been discussed before, using -S bigpic:all will screw up erupters, and using -S erupter:all will screw up BFs.

Thanks Norby! I was trying to say that. I hope everything worked out for you Lou!


BTW G'morning all

Hi,

I got the driver installed on Win8.1 but none of the Blue Fury's are showing up in bfgminer 3.5.1 on my PC or MinePeon 0.24rc2(with git pull). Does anyone know what commands I should use to get them all to show. I have 4 of them on 2 usb hubs(2 each hub). I have tried plugging into USB 2.0 and 3.0 ports and a no go for both. Anyone have any ideas? I would prefer to use them on Minepeon.

This is what i'm using below for Minepeon.

Code:

#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer -S bitfury:/dev/ttyACM0 -S bitfury:/dev/ttyACM1 -S bitfury:/dev/ttyACM3 -S bitfury:/dev/ttyAMA0 -c /opt/minepeon/etc/miner.conf

This is the list of the devices listed using "ls /dev/tty*

https://i.imgur.com/ZHqSJN6.jpg

Thanks.

[Beastlymac]

I disagree in regard to running -S bigpic:all.  I am running my single BF with bfgminer 3.5.1, with the 'alfa driver' provided by Beastlymac, through a batch file called #MINE.bat on Win7 64, the content of this batch file is
bfgminer.exe -S bigpic:all -o [pool url] -u [user name] -p [password]

You can use -S bigpic:all as long as you don't also have USB Block Erupters.  As has been discussed before, using -S bigpic:all will screw up erupters, and using -S erupter:all will screw up BFs.

Thanks Norby! I was trying to say that. I hope everything worked out for you Lou!


BTW G'morning all

Hi,

I got the driver installed on Win8.1 but none of the Blue Fury's are showing up in bfgminer 3.5.1 on my PC or MinePeon 0.24rc2(with git pull). Does anyone know what commands I should use to get them all to show. I have 4 of them on 2 usb hubs(2 each hub). I have tried plugging into USB 2.0 and 3.0 ports and a no go for both. Anyone have any ideas? I would prefer to use them on Minepeon.

This is what i'm using below for Minepeon.

#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer -S bitfury:/dev/ttyACM0 -S bitfury:/dev/ttyACM1 -S bitfury:/dev/ttyACM3 -S bitfury:/dev/ttyAMA0 -c /opt/minepeon/etc/miner.conf

This is the list of the devices listed using "ls /dev/tty*



Thanks.

Try changing the bitfury to bigpic or bf1

[mikejones]

How do we install on minpeon using bfgminer??

Install minepeon 2.4 then do a git pull for the updates.

Anytime I reset my miners, reboot my pi, "quit" from Bfgminer my redfury stops mining and the only way I can get bfgminer to recongnize it is by pressing the reset button, go into manage devices, add a device, and do auto detect. I have to do this each time I reboot my miners in the webgui, quit from "screen -r", or reboot my pi. It's annoying as hell. I don't think minepeon/bfgminer automatically detects the red fury miner?? Thoughts??

[mikejones]

I disagree in regard to running -S bigpic:all.  I am running my single BF with bfgminer 3.5.1, with the 'alfa driver' provided by Beastlymac, through a batch file called #MINE.bat on Win7 64, the content of this batch file is
bfgminer.exe -S bigpic:all -o [pool url] -u [user name] -p [password]

You can use -S bigpic:all as long as you don't also have USB Block Erupters.  As has been discussed before, using -S bigpic:all will screw up erupters, and using -S erupter:all will screw up BFs.

Thanks Norby! I was trying to say that. I hope everything worked out for you Lou!


BTW G'morning all

Hi,

I got the driver installed on Win8.1 but none of the Blue Fury's are showing up in bfgminer 3.5.1 on my PC or MinePeon 0.24rc2(with git pull). Does anyone know what commands I should use to get them all to show. I have 4 of them on 2 usb hubs(2 each hub). I have tried plugging into USB 2.0 and 3.0 ports and a no go for both. Anyone have any ideas? I would prefer to use them on Minepeon.

This is what i'm using below for Minepeon.

#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer -S bitfury:/dev/ttyACM0 -S bitfury:/dev/ttyACM1 -S bitfury:/dev/ttyACM3 -S bitfury:/dev/ttyAMA0 -c /opt/minepeon/etc/miner.conf

This is the list of the devices listed using "ls /dev/tty*

https://i.imgur.com/ZHqSJN6.jpg

Thanks.

Try changing the bitfury to bigpic or bf1

How do you know which tty belongs to what miner?

[Beastlymac]

If you have 4 it should be the 4 acm devices

[Olly_K]

beastly, I received my 20 from OutCask and I believe one to be faulty. It hashes, it's just not at the rate the other 19 do:



HW errors are zero, just the hashrate is low. I don't really want to try a flash as I don't believe that to be the problem. What are my options ?

It's not my hubs/hardware as the other 19 work perfectly. Even in a machine on it's own it produces a low hash rate.

Thanks

[crazyearner]

Can anyone help

Problem installing drivers followed guide to install on Windows 7 getting following error on install