Blue Fury Support Thread. - page 29.

mikejones

newbie

Activity: 59

Merit: 0

Quote from: Beastlymac on November 09, 2013, 03:45:12 AM

Quote from: loumatrix on November 08, 2013, 11:57:07 PM

Quote from: jdkackley on November 08, 2013, 09:17:27 AM

Quote from: NorbyTheGeek on November 08, 2013, 08:18:56 AM

Quote from: kabopar on November 08, 2013, 04:15:27 AM

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*

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

Thanks.

Try changing the bitfury to bigpic or bf1

How do you know which tty belongs to what miner?

mikejones

newbie

Activity: 59

Merit: 0

Quote from: Beastlymac on November 08, 2013, 08:10:24 PM

Quote from: ?? on ??

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??

Beastlymac

hero member

Activity: 630

Merit: 501

Miner Setup And Reviews. WASP Rep.

Quote from: loumatrix on November 08, 2013, 11:57:07 PM

Quote from: jdkackley on November 08, 2013, 09:17:27 AM

Quote from: NorbyTheGeek on November 08, 2013, 08:18:56 AM

Quote from: kabopar on November 08, 2013, 04:15:27 AM

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

loumatrix

newbie

Activity: 12

Merit: 0

Quote from: jdkackley on November 08, 2013, 09:17:27 AM

Quote from: NorbyTheGeek on November 08, 2013, 08:18:56 AM

Quote from: kabopar on November 08, 2013, 04:15:27 AM

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*

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

Thanks.

Epinnoia

full member

Activity: 209

Merit: 100

Quote from: zyk0 on November 08, 2013, 11:26:51 PM

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.

zyk0

newbie

Activity: 33

Merit: 0

Quote from: Epinnoia on November 08, 2013, 10:23:46 PM

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

Quote from: Epinnoia on November 08, 2013, 09:54:59 PM

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

full member

Activity: 209

Merit: 100

Quote from: zyk0 on November 08, 2013, 10:14:11 PM

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

newbie

Activity: 33

Merit: 0

Quote from: Epinnoia on November 08, 2013, 09:54:59 PM

Quote from: -ck on November 08, 2013, 09:14:14 PM

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 ( Cool

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

full member

Activity: 209

Merit: 100

Quote from: -ck on November 08, 2013, 09:14:14 PM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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

full member

Activity: 209

Merit: 100

Quote from: Taugeran on November 08, 2013, 03:30:38 PM

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.

Beastlymac

hero member

Activity: 630

Merit: 501

Miner Setup And Reviews. WASP Rep.

Quote from: ?? on ??

How do we install on minpeon using bfgminer??

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: mikejones on November 08, 2013, 07:59:02 PM

Quote from: ssinc on November 05, 2013, 04:26:39 PM

CGminer 3.7.2 on Windows 7 - 32

So does this mean you have 0 HW errors??

Quote from: -ck on November 04, 2013, 03:19:37 AM

Quote from: x3maniac on November 04, 2013, 01:43:16 AM

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...

mikejones

newbie

Activity: 59

Merit: 0

Quote from: ssinc on November 05, 2013, 04:26:39 PM

CGminer 3.7.2 on Windows 7 - 32

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

So does this mean you have 0 HW errors??

philipma1957

legendary

Activity: 4256

Merit: 8551

'The right to privacy matters'

Quote from: mikejones on November 08, 2013, 06:12:54 PM

Quote from: Beastlymac on October 26, 2013, 07:32:56 PM

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

newbie

Activity: 59

Merit: 0

Quote from: Beastlymac on October 26, 2013, 07:32:56 PM

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

bitterdog

hero member

Activity: 728

Merit: 503

dApps Development Automation Platform

Quote from: tk1337 on November 07, 2013, 05:54:32 PM

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?

btljuice

member

Activity: 92

Merit: 10

Quote from: btljuice on November 08, 2013, 11:13:25 AM

Got my blue fury yesterday. Got it going with cgminer 3.7.2, it was hashing for several hours at 1.1-1.2GH/s, and when I woke up this morning it's not hashing at all. Below is what I'm getting now.

Code:

 [2013-11-08 11:10:36] Hotplug: bitfury added BF1 0
 [2013-11-08 11:10:36] BF1 0 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-08 11:10:36] BF1 0: Device disappeared, disabling thread
 [2013-11-08 11:10:36] BF1 0 failure, disabling!
 [2013-11-08 11:10:36] Thread 15 being disabled

Once I got the bluefury going again, after it's long zombie state... now it's only hashing at ~580Mh/s. Seems to be getting worse and worse as time goes on.

madpoet

sr. member

Activity: 448

Merit: 250

Well I finally got my BF and BE both working but only by using one on cgminer and one on bfgminer. *shrug* My BF is slow... 2.09. All in all fairly disappointing, well below the 2.5 I was expecting when I bought it. Hope additional tweaking ekes more out of it.

fizzmine

newbie

Activity: 38

Merit: 0

Just got an Ebay RedFury up and running. Working great so far. Here's my info - might help anyone having trouble:

RPi - latest Rasbian

BFGminer 3.5.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-x6500 --disable-modminer
make

lsusb | grep -i atmel
Bus 001 Device 006: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project

added to /etc/udev/rules.d/50-usb-hd.rules:
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"

After that a simple sudo ./bfgminer picked up my jally and the RedFury:

--------------------------------------------------------------------------------
BPM 0: | 2.42/ 2.41/ 2.36Gh/s | A: 392 R:1+0(.25%) HW:47/5.2%
BFL 0: 42.0C | 5.34/ 5.33/ 5.20Gh/s | A: 959 R:1+0(.10%) HW: 0/none
--------------------------------------------------------------------------------

once those launched, I fired up the block erupters with sudo ./bfgminer -S erupter:all and both instances of bfgminer are running great.

Topic: Blue Fury Support Thread. - page 29. (Read 89611 times)