 Show Posts
|
|
Pages: [1] 2 »
|
4.9.0 x64 linux binary also crashes after spitting out
[2015-01-19 06:06:14] BMA1: Ran out of queued IDs after 7 of 8
*** Error in `./cgminer': double free or corruption (out): 0x00007fcab00405e0 ***
Aborted (core dumped)
Thanks that one is probably the culprit and the message is the hint, whereas the windows backtrace was unhelpful apart from suggesting it was a freeing issue. Can you try latest git please? So far it's running stable after 3+ hours. Did I need to run with -D to see LOG_ERR messages like (Free|Discard) work called with null work from ..., or was there something else that enabled that? |
|
|
|
cgminer-debug.exe caused an Access Violation at location 77cf32b0 in module ntdll.dll Reading from location 0482bef2.
Registers:
eax=00100000 ebx=048661f8 ecx=00000001 edx=000007ff esi=0482bef0 edi=00740000
eip=77cf32b0 esp=0338ab8c ebp=0338abb4 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
77CF32B0 ntdll.dll:77CF32B0 RtlImageNtHeader
77CF35B7 ntdll.dll:77CF35B7 RtlImageNtHeaderv
77CF34A2 ntdll.dll:77CF34A2 RtlImageNtHeader
773F98CD msvcrt.dll:773F98CD free
00404637 cgminer-debug.exe:00404637
0045D362 cgminer-debug.exe:0045D362
0045D91D cgminer-debug.exe:0045D91D
0045DCD4 cgminer-debug.exe:0045DCD4
004D7A8B cgminer-debug.exe:004D7A8B
77401287 msvcrt.dll:77401287 _itow_s
77401328 msvcrt.dll:77401328 _endthreadex
76DB338A kernel32.dll:76DB338A BaseThreadInitThunk
77CF9F72 ntdll.dll:77CF9F72 RtlInitializeExceptionChainu
77CF9F45 ntdll.dll:77CF9F45 RtlInitializeExceptionChain
4.8.0 win32 binary also crashes 4.9.0 x64 linux binary also crashes after spitting out [2015-01-19 06:06:14] BMA1: Ran out of queued IDs after 7 of 8 *** Error in `./cgminer': double free or corruption (out): 0x00007fcab00405e0 *** Aborted (core dumped) #0 0x00007fb45460ccc9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0 0x00007fb45460ccc9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 11428
selftid = 11459
#1 0x00007fb4546100d8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7fb44e02db90,
sa_sigaction = 0x7fb44e02db90}, sa_mask = {__val = {
140412379650640, 0, 4294967296, 140412379650648,
140412379650640, 8700951690291695954, 34359738369,
15020210604761758210, 140412379650648, 1173025764356111352,
8409057363769621645, 10048828393066491241, 12341603478805500196,
3845900113458748955, 10915808292373199057,
4028156633168234533}}, sa_flags = 1352422596,
sa_restorer = 0x80000000}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007fb454649f24 in __libc_message (do_abort=do_abort@entry=1,
fmt=fmt@entry=0x7fb4547586c8 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
ap = {{gp_offset = 40, fp_offset = 1475,
overflow_arg_area = 0x7fb44e02dba0,
reg_save_area = 0x7fb44e02db30}}
fd = 14
on_2 = <optimized out>
list = <optimized out>
nlist = <optimized out>
cp = <optimized out>
written = <optimized out>
#3 0x00007fb4546561fe in malloc_printerr (ptr=<optimized out>,
str=0x7fb4547587f8 "double free or corruption (out)", action=1)
at malloc.c:4996
buf = "00007fb42c02b4d0"
cp = <optimized out>
#4 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0)
at malloc.c:3840
size = <optimized out>
fb = <optimized out>
nextchunk = <optimized out>
nextsize = <optimized out>
nextinuse = <optimized out>
prevsize = <optimized out>
bck = <optimized out>
fwd = <optimized out>
errstr = <optimized out>
locked = <optimized out>
#5 0x000000000040897a in _free_work (work=0x7fb42c02b4d0) at cgminer.c:2005
No locals.
#6 0x000000000046556c in process_nonces (bflsc=0x1f6fe90, dev=0,
xlink=0x7fb44e02fde0 "", data=0x7fb4240009e1 "BD06,5C,0", count=5,
fields=0x7fb424000be0, nonces=0x7fb44e031e54) at driver-bflsc.c:1488
sc_info = 0x1f70230
thr = 0x1f3ac60
work = 0x7fb42c02b4d0
core = 88 'X'
nonce = 616981876
i = 5
num = 2
x = 0
tmp = 0x0
res = false
__func__ = "process_nonces"
#7 0x0000000000465cb6 in process_results (bflsc=0x1f6fe90, dev=0,
pbuf=0x7fb44e031eb0 "COUNT:8", nonces=0x7fb44e031e54,
in_process=0x7fb44e031e58) at driver-bflsc.c:1568
sc_info = 0x1f70230
items = 0x7fb424000fa0
firstname = 0x7fb424000cf0 "BD10"
fields = 0x7fb424000be0
lf = 0x0
que = 8
i = 7
lines = 11
count = 5
tmp = 0x0
tmp2 = 0x0
buf = 0x7fb424000e70 "INPROCESS:0\nCOUNT:8\nBD07,41,2,3EDE368B,81B58B6D\nBCFE,05,0\nBCF9,2C,1,CC9DFDA2\nBD18,4F,0\nBD0E,57,0\nBD06,5C,0\nBD09,33,1,05718BA4\nBD10,58,2,272FC9CC,24C66574\nOK\n"
xlink = '\000' <repeats 16 times>
res = true
#8 0x0000000000466205 in bflsc_get_results (userdata=0x1f6fe90)
at driver-bflsc.c:1640
ts_start = {tv_sec = 239291, tv_nsec = 213551388}
in_process = 0
bflsc = 0x1f6fe90
sc_info = 0x1f70230
elapsed = {tv_sec = 0, tv_usec = 50149}
now = {tv_sec = 1421676015, tv_usec = 940195}
oldest = 3.40282347e+38
f = 3.40282347e+38
buf = "COUNT:8\000S:0\nCOUNT:8\nBD07,41,2,3EDE368B,81B58B6D\nBCFE,05,0\nBCF9,2C,1,CC9DFDA2\nBD18,4F,0\nBD0E,57,0\nBD06,5C,0\nBD09,33,1,05718BA4\nBD10,58,2,272FC9CC,24C66574\nOK\n", '\000' <repeats 3939 times>
err = 0
amount = 157
i = 1
que = 10
dev = 0
nonces = 3
readok = true
#9 0x00007fb4549a4182 in start_thread (arg=0x7fb44e033700)
at pthread_create.c:312
__res = <optimized out>
pd = 0x7fb44e033700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140412379674368,
-3819750026809842330, 0, 0, 140412379675072, 140412379674368,
3861020365915809126, 3861041330569340262},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#10 0x00007fb4546d100d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
|
|
|
|
Using windows binary from http://ck.kolivas.org/apps/cgminer/cgminer-4.9.0-windows.7zkeep getting this error after several hours of running (exactly the same each time) Problem Event Name: APPCRASH
Application Name: cgminer.exe
Application Version: 0.0.0.0
Application Timestamp: 00119714
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.18247
Fault Module Timestamp: 521ea8e7
Exception Code: c0000005
Exception Offset: 0002e3be
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 Ran it with -T to rule out any ncurses issues, but that failed as well. Currently running with -D -T and stderr being logged, but these crashes sometimes take up to 12 hours to manifest. Is there anything else I should be trying to help diagnose this issues as well? Update: STDOUT Target: 0000000000400000000000000000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)
[2015-01-18 10:10:06] Generated stratum merkle 795b18ef82ca0aa789aa22c36cfb6b58ef98fb543ebb8500ce77c52c43ce0a5c
[2015-01-18 10:10:06] Generated stratum header 000000026a4f752f11c13c789f20d6dc966e75fcaecfb167091233a70000000000000000795b18e f82ca0aa789aa22c36cfb6b58ef98fb543ebb8500ce77c52c43ce0a5c54bbf65b1819012f000000 000000008000000000000000000000000000000000000000000000000000000000
[2015-01-18 10:10:06] Work job_id 1421604443 208895 nonce2 7468 ntime 54bbf65b
[2015-01-18 10:10:06] Generated target 0000000000000000000000000000000000000000000000000000400000000000
[2015-01-18 10:10:06] Generated stratum work
[2015-01-18 10:10:06] Pushing work from pool 0 to hash queue
[2015-01-18 10:10:06] BMA 1: Share above target
[2015-01-18 10:10:06] Proof: 0000000042cc5faab12fba05bae24a44876f3fe6e0bd830d3c05894fcd7535f5
Target: 0000000000400000000000000000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)
[2015-01-18 10:10:06] Got work from get queue to get work for thread 0
[2015-01-18 10:10:06] Successfully rolled work
[2015-01-18 10:10:06] Successfully rolled work
[2015-01-18 10:10:06] Discarded work
[2015-01-18 10:10:06] Selecting pool 0 for work
[2015-01-18 10:10:06] Successfully rolled work
[2015-01-18 10:10:06] Discarded cloned or rolled work
(5s):770.9G (1m):1.351T (5m):1.484T (15m):1.472T (avg):1.519Th/s
STDERR [2015-01-18 10:10:06] BMA 1: Share above target
[2015-01-18 10:10:06] Proof: 0000000042cc5faab12fba05bae24a44876f3fe6e0bd830d3c05894fcd7535f5
Target: 0000000000400000000000000000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)
[2015-01-18 10:10:06] Got work from get queue to get work for thread 0
[2015-01-18 10: [21001:50-60]1 -1S8u c1c0e:s1s0f:u0l6l]y Drioslclaerdd ewdo rwko
r [2015-01-18 10:10:06] Successfully rolled work
k
[2015-01-18 10:10:06] Selecting pool 0 for work
[2015-01-18 10:10:06] Successfully rolled work
[2015-01-18 [2015-011-01:81 01:00:61]0 :06]D isGceanredreadt ecdl osnterda tourm rmoelrlkelde wfo7r6k6f
f3b98a511d6019d0153ba6ae0d97f298561d97073da0849a44181eff57f
[2015-01-18 10:10:06] BMA 1: Share above target
[2015-01-18 10:10:06] Successfully rolled work
[2015-01-18 10:10:13] Generated stratum header 000000026a4f752f11c13c789f20d6dc966e75fcaecfb167091233a70000000000000000f766ff3 b98a511d6019d0153ba6ae0d97f298561d97073da0849a44181eff57f54bbf65b1819012f000000 000000008000000000000000000000000000000000000000000000000000000000
[2015-01-18 10:10:13] Proof: 0000000011af500a35b11e648f95d4e2f1eab536eb6f54087dc38d8ec4cf2c50
Target: 0000000000400000000000000000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)
[2015-01-18 10:10:13] Work job_id 1421604443 208895 nonce2 7469 ntime 54bbf65b
[2015-01-18 10:10:13] BMA 1: Share above target
Update2: The cgminer.exe in the temp directory still errors, but with a different application timestamp: Problem Event Name: APPCRASH
Application Name: cgminer-temp.exe
Application Version: 0.0.0.0
Application Timestamp: 0011c714
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.18247
Fault Module Timestamp: 521ea8e7
Exception Code: c0000005
Exception Offset: 0002e3be
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
|
|
|
|
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. |
|
|
|
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. |
|
|
|
|
Just bought one of these w/ bitcoin, worked great.
Thanks for the deal!
|
|
|
|
Since Vista SP1 Windows x64 requires drivers to be signed and you cannot permanently set testing mode. If reinstalling some other OS isn't an option I'd use VirtualBox and pass the USB devices through to either some linux distro or a 32bit windows guest OS.
I use VirtualBox a bit, I have never tried passing these devices though, does it really work ? That's currently how I have my Blue Furies running, Win7 x64 Host, Ubuntu Server 13.10 guest, bfgminer 3.5.1. |
|
|
|
Hi all,
I am running Windows 8.1 x64 and bfgminer 3.5.1 but I cannot get the computer to install the driver. I have included screenshots.
I followed the directions at the beginning of this thread. Can anyone provide me with any assistance?
It is greatly appreciated.
Thanks.
Since Vista SP1 Windows x64 requires drivers to be signed and you cannot permanently set testing mode. If reinstalling some other OS isn't an option I'd use VirtualBox and pass the USB devices through to either some linux distro or a 32bit windows guest OS. |
|
|
|
Twice now I have ended up with 5 of 6 BF sticks showing either 'Sick' or 'Dead' after an hour of hashing. Running in BFGminer on Win 7.
I ended up waking up this morning to find one stick that had been operating at 2.2GH/s showing 0.29GH average speed, apparently locking up hours ago. Hopefully I won't have to end up rewiring the reset line to a relay controlled by the serial port to manage these things remotely - but with all the problems with these things, It's seeming plausible. |
|
|
|
Weird, switched to bfgminer 3.5.1 and the reported error rate was way down: BPM0 | 5s: 2.21 avg: 2.21 u: 2.09 Gh/s | A:2431 R:16+1(.69%) HW:350/3.5%
BPM1 | 5s: 2.30 avg: 2.30 u: 2.17 Gh/s | A:2407 R:17+0(.70%) HW:382/3.7%
BPM2 | 5s: 2.29 avg: 2.29 u: 2.16 Gh/s | A:2465 R:12+0(.48%) HW:408/4.0%
BPM3 | 5s: 1.99 avg: 1.99 u: 1.88 Gh/s | A:2148 R:19+0(.88%) HW:312/3.5%
but now after flashing the firmware on the furies, they're back up again BPM 0: | 2.29/ 2.29/ 2.18Gh/s | A: 81 R:0+0(none) HW: 26/7.0%
BPM 1: | 2.21/ 2.21/ 2.19Gh/s | A: 79 R:0+0(none) HW: 72/ 17%
BPM 2: | 1.99/ 1.99/ 1.89Gh/s | A: 70 R:1+0(1.4%) HW: 44/ 13%
BPM 3: | 2.31/ 2.30/ 0.51Gh/s | A: 18 R:0+1(5.3%) HW:265/ 76%
and one of them is again being stubborn about giving good performance... I need to learn to leave well-enough alone. |
|
|
|
The USB should be yellow when it has power and red when it is plugged into a computer. When it is initialising it will turn organge and when it is working it will flash yellow/red.
So what does just a blinking red LED stand for? That is what my 5 miners are doing. It means they are hashing. It just means that you have stopped the mining software and not reset the device before starting the software again. When running cgminer, the yellow LED shuts off for me and they just flash red when hashing. Later switching to bfgminer doesn't not restore the yellow LED and will continue to only flash red when hashing. However, if I only use bfgminer from a fresh reset though. the yellow LED stays on even with the red LED flashing while mining. If the yellow LED is always supposed to be lit indicating power, then is WinUSB or cgminer doing something wrong that this yellow LED goes out, and if so.. why does the firmware allow this? |
|
|
|
As a reseller, I have not had any complaints yet, but I'm sure I will. I sold out today and the first orders are just getting delivered.
I calculated at 2.2 Gh/s vs. the promised 2.6 Gh/s there will be about $3.20 in lost mining revenue. This takes into account difficulty increases using the coinish calculator. Disappointing, but not enough to throw a stink over.
That's one way to try and minimize the over promised hash rate. On the other hand if someone payed 0.8 bitcoins and only got 85% of what they paid for, they're out 0.10 to 0.12 bitcoins at least.. which is a far cry from $3.20 at the moment. |
|
|
|
Ok just had a thought. Could be totally wrong here.
The chips are rated at 5gh.
So the hw errors we are receiving from 50-60 percent is the reduction of hash power.
That's why we are getting these hash speeds of 2.2gh
It's just a thought
What does everyone else think
Haven't looked into it, but I assumed the HW errors were just timing out or not returning valid data when no nonce was found. As for the chips being rated for 5GH, not under the 2.5W you can get out of a USB port (and don't forget the power for the supporting hardware besides the bitfury chip). |
|
|
|
60%ish hardware errors seem to be about normal
but...
[2013-11-05 09:03:46] BPM0 | 5s: 2.31 avg: 2.30 u: 0.54 Gh/s | A:66 R:0+0(none) HW:2252/ 89%
[2013-11-05 09:03:46] BPM1 | 5s: 1.99 avg: 1.99 u: 1.89 Gh/s | A:237 R:1+1(.84%) HW:1398/ 59%
[2013-11-05 09:03:46] BPM2 | 5s: 2.29 avg: 2.29 u: 2.16 Gh/s | A:287 R:2+0(.52%) HW:1607/ 59%
[2013-11-05 09:03:46] BPM3 | 5s: 2.21 avg: 2.21 u: 2.05 Gh/s | A:261 R:2+0(.76%) HW:1567/ 60%
seems like I got a couple duds.
@zyk0 & @ssinc What OS? As I've seen this before but after I recompiled BFG using 3.2.0, I haven't seen the issue since, so, I'm curious what OS you're using these on. Was originally using a custom cgminer 3.6.6-1 w/ win7 x64 after debugging with ck and getting him to remove the manufacture string check, but it's speeds were horrible and inconsistent, I instead switched to bfgminer under a ubuntu server 13.10 VM in VirtualBox w/ USB passthrough from the win64 host OS. Originally I was using the 3.0.99 repository compiled binary, but have switched to 3.4.0. I have also tried cgminer 3.7.0 and 3.7.2 win32 binaries but they are still not up to snuff. 1/2 the time w/ bfgminer 3.0.99 I'll see random garbage as part of the model name/serial, and I've seen corrupted output on the device name from cgminer's API stats as well. I'm hoping these are issues with only the firmware on these blue furies and we'll be getting a fix soon. Sadly... my stick which now is getting more HW errors than the others, used to be my top performing Blue Fury: [2013-11-05 07:17:33] BF10 BF1 15062915 | 5s:1.996 avg:1.993 u:1.895 Gh/s | A:8702 R:62+0(.70%) HW:0
[2013-11-05 07:17:33] BF11 BF1 15062B15 | 5s:2.302 avg:2.292 u:2.157 Gh/s | A:9907 R:78+2(.80%) HW:0
[2013-11-05 07:17:33] BF12 BF1 15040915 | 5s:2.314 avg:2.305 u:2.200 Gh/s | A:10102 R:66+0(.64%) HW:0
[2013-11-05 07:17:33] BF13 BF1 15062312 | 5s:2.215 avg:2.214 u:2.133 Gh/s | A:9795 R:72+1(.73%) HW:0
But serial no. 15040915 is now my worst one, and no amount of resetting, power cycling, cooling off, leaving unplugged for a while, etc.. is getting it back to where it was. Edit: Maybe it needed to "warm up", seems to have finally kicked in to normal after starting with a high HW error rate (unless the difficult change triggered it) Block: ...2df02926 #268145 Diff:511M ( 3.66Ph/s) Started: [13:39:08]
ST:2 F:0 NB:33 AS:0 BW:[ 62/ 55 B/s] E:33.63 I: 341uBTC/hr BS:85.6k
4 | 8.92/ 8.79/ 8.29Gh/s | A:6405 R:63+0(.97%) HW:37790/ 59%
--------------------------------------------------------------------------------
BPM 0: | 1.99/ 1.99/ 1.90Gh/s | A:1515 R:13+0(.85%) HW: 8501/ 59% <- still 10% slower than most
BPM 1: | 2.28/ 2.29/ 2.17Gh/s | A:1627 R:13+0(.79%) HW: 9817/ 59%
BPM 2: | 2.30/ 2.30/ 2.10Gh/s | A:1587 R:17+0(1.1%) HW:10027/ 61% <- back to working
BPM 3: | 2.22/ 2.21/ 2.13Gh/s | A:1677 R:20+0(1.2%) HW: 9450/ 59%
--------------------------------------------------------------------------------
|
|
|
|
60%ish hardware errors seem to be about normal
but...
[2013-11-05 09:03:46] BPM0 | 5s: 2.31 avg: 2.30 u: 0.54 Gh/s | A:66 R:0+0(none) HW:2252/ 89%
seems like I got a couple duds.
I have two units that are doing this as well. I don't suppose you were sent an extra 50% of units to adequately take care of your group buy customers... |
|
|
|
|
60%ish hardware errors seem to be about normal
but...
[2013-11-05 09:03:46] BPM0 | 5s: 2.31 avg: 2.30 u: 0.54 Gh/s | A:66 R:0+0(none) HW:2252/ 89%
[2013-11-05 09:03:46] BPM1 | 5s: 1.99 avg: 1.99 u: 1.89 Gh/s | A:237 R:1+1(.84%) HW:1398/ 59%
[2013-11-05 09:03:46] BPM2 | 5s: 2.29 avg: 2.29 u: 2.16 Gh/s | A:287 R:2+0(.52%) HW:1607/ 59%
[2013-11-05 09:03:46] BPM3 | 5s: 2.21 avg: 2.21 u: 2.05 Gh/s | A:261 R:2+0(.76%) HW:1567/ 60%
seems like I got a couple duds.
|
|
|
|
My results:  The Blue Fury hashing at 380MH/s is disturbing... I had similar issues with cgminer, I'd try using bfgminer for now. |
|
|
|
As a follow up on slow speeds w/ cgminer... cgminer version 3.6.6 - Started: [2013-11-03 01:02:47]
--------------------------------------------------------------------------------
(5s):6.425G (avg):6.640Gh/s | A:83266 R:176 HW:0 WU:93.4/m
ST: 2 SS: 0 NB: 120 LW: 153191 GF: 0 RF: 0
Connected to xxxxx diff 4 with stratum as user xxx
Block: 338ef766... Diff:391M Started: [15:42:36] Best share: 192K
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BF1 0: | 2.143G/2.129Gh/s | A:26540 R:24 HW:0 WU:30.0/m
BF1 1: | 2.046G/2.041Gh/s | A:25744 R:64 HW:0 WU:28.7/m
BF1 3: | 2.149G/2.141Gh/s | A:26982 R:68 HW:0 WU:30.1/m
BF1 6: | 332.7M/327.5Mh/s | A: 1072 R:12 HW:0 WU: 4.7/m
--------------------------------------------------------------------------------
Those 2GH/s were rare lucky occurrences. I ended up restarting them in efforts to try solving the problem and couldn't get more than 2 of them even close to 2GH/s again. Seems to be a cgminer problem, running them via BFGminer gets me 1.99 to 2.3GH w/o any effort or dinking around of resetting/unplugging miners. bfgminer version 3.0.99 - Started: [2013-11-03 20:17:48] - [ 0 days 01:44:34]
--------------------------------------------------------------------------------
5s:9.017 avg:8.810 u:8.460 Gh/s | A:3088 R:11+3(.45%) HW:0
ST: 2 GF: 0 NB: 11 AS: 0 RF: 0 E: 35.18 U:29.6/m BS:8.18k
Connected to xxxxx diff 4 with stratum as user xxx
Block: ...5b9747ba #267835 Diff:391M (2.798Ph/s) Started: [21:48:38]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BF1 0: BF1 15062915 | 2.000/1.995/1.953Gh/s | A:713 R:4+0(.55%) HW:0
BF1 1: BF1 15062B15 | 2.300/2.295/2.104Gh/s | A:768 R:1+1(.25%) HW:0
BF1 2: BF1 15040915 | 2.308/2.309/2.156Gh/s | A:787 R:5+1(.75%) HW:0
BF1 3: BF1 15062312 | 2.214/2.215/2.249Gh/s | A:821 R:1+1(.24%) HW:0
--------------------------------------------------------------------------------
But like everyone else, nowhere close to 2.6-2.7GH/s |
|
|
|
After some work with ckolivas, got cgminer working with my blue furies.
The manufacture string is BFMG instead of BPMC on the blue vs red, so next release is likely going to ignore that when attempting to use BF1 devices.
However, speed on my sticks hasn't been too great.
Will try resetting stick 15062915 once again I suppose.
...
also, that corrupted product string/version/missing serial on that first device is worrisome, hopefully that's just a software flaw (and hopefully just that debug build) that won't end up crashing cgminer.
Odd. Have you tried isolating that suspect card/unit such that you try mining with it and only it? Since 4-port unpowered hubs are common, I have to ask... Are you using a powered hub? Hadn't tried running on it's own yet but it's still not doing to well after a couple resets. cgminer version 3.6.6 - Started: [2013-11-03 01:02:47]
--------------------------------------------------------------------------------
(5s):6.425G (avg):6.640Gh/s | A:83266 R:176 HW:0 WU:93.4/m
ST: 2 SS: 0 NB: 120 LW: 153191 GF: 0 RF: 0
Connected to xxxxx diff 4 with stratum as user xxx
Block: 338ef766... Diff:391M Started: [15:42:36] Best share: 192K
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BF1 0: | 2.143G/2.129Gh/s | A:26540 R:24 HW:0 WU:30.0/m
BF1 1: | 2.046G/2.041Gh/s | A:25744 R:64 HW:0 WU:28.7/m
BF1 3: | 2.149G/2.141Gh/s | A:26982 R:68 HW:0 WU:30.1/m
BF1 6: | 332.7M/327.5Mh/s | A: 1072 R:12 HW:0 WU: 4.7/m
--------------------------------------------------------------------------------
Most common 4 port hubs don't have the spacing between ports to allow you to get usb miners in there, but the http://www.amazon.com/gp/product/B005NGQWL2 I'm using w/ it's 60w power adapter should have more than enough for these things. |
|
|
|
After some work with ckolivas, got cgminer working with my blue furies. The manufacture string is BFMG instead of BPMC on the blue vs red, so next release is likely going to ignore that when attempting to use BF1 devices. However, speed on my sticks hasn't been too great. Will try resetting stick 15062915 once again I suppose. cgminer version 3.6.6 - Started: [2013-11-03 01:02:47]
--------------------------------------------------------------------------------
(5s):6.704G (avg):6.647Gh/s | A:57670 R:132 HW:0 WU:93.2/m
ST: 2 SS: 0 NB: 91 LW: 106939 GF: 0 RF: 0
Connected to xxx diff 4 with stratum as user xxx
Block: ac3f2fff... Diff:391M Started: [11:23:51] Best share: 192K
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BF1 0: | 2.213G/2.124Gh/s | A:18324 R:20 HW:0 WU:29.8/m
BF1 1: | 2.132G/2.050Gh/s | A:18188 R:52 HW:0 WU:28.8/m
BF1 3: | 2.223G/2.146Gh/s | A:18406 R:56 HW:0 WU:30.0/m
BF1 4: | 345.3M/327.6Mh/s | A: 2724 R: 4 HW:0 WU: 4.6/m
--------------------------------------------------------------------------------
[STATS0] =>
(
[ID] => BF10
[Elapsed] => 37069
[Version] => 224
[Product] => ;└PI☺BF1
[Serial] => 00000000
[NonceRate] => 0.677997
[USB Pipe] => 2 0/0/0 1383501508
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 204427 50=1/70/70/60/10 100=0/0/0/0/0 500=0/0/0/0/0
)
[STATS1] =>
(
[ID] => BF11
[Elapsed] => 37069
[Version] => 1
[Product] => BF1
[Serial] => 15062312
[NonceRate] => 0.682141
[USB Pipe] => 10 0/0/0 1383505537
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 196265 50=12/65/672/759/4194 100=1/114/114/104/10 500=0/0/0/0/0
)
[STATS2] =>
(
[ID] => BF12
[Elapsed] => 37069
[Version] => 1
[Product] => BF1
[Serial] => 15062915
[NonceRate] => 0.122563
[USB Pipe] => 5 0/0/5 1383469931
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 2312 0
)
[STATS3] =>
(
[ID] => BF13
[Elapsed] => 37069
[Version] => 1
[Product] => BF1
[Serial] => 15062b15
[NonceRate] => 0.688453
[USB Pipe] => 6 0/0/0 1383483895
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 203386 50=4/633/655/234/2350 100=0/0/0/0/0 500=0/0/0/0/0
)
[STATS4] =>
(
[ID] => BF14
[Elapsed] => 37069
[Version] => 1
[Product] => BF1
[Serial] => 15062915
[NonceRate] => 0.121812
[USB Pipe] => 10 0/0/0 1383504731
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 147066 50=1/642/642/51/591 100=0/0/0/0/0 500=0/0/0/0/0
)
also, that corrupted product string/version/missing serial on that first device is worrisome, hopefully that's just a software flaw (and hopefully just that debug build) that won't end up crashing cgminer. |
|
|
|
|
