|
|
|
|
|
|
|
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
toxic0n
Member
 Offline
Activity: 413
Merit: 10
|
 |
May 08, 2014, 07:55:35 PM |
|
I actually gave it a try based off of Sandor's code. It's fairly easy to read. I was able to set the per chip frequency command but my Gridseeds wouldnt hash afterwards. I didn't bother looking into this further, if Sandor adds the failover functionality, I'm all set. |
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1009
|
|
May 08, 2014, 09:00:36 PM |
|
API access and JSON commands keep failing API: Client 192.168.1.9 connected
API: JSON decode failed(1): '[' or '{' expected near '/' (/x-xbitmap, */*;q=0.1)
API: Client 192.168.1.9 connected
API: JSON decode failed(1): '[' or '{' expected near '0.1' (0.1) any idea why? |
|
|
|
|
|
sandor111
|
|
May 08, 2014, 09:01:25 PM
Last edit: May 08, 2014, 09:41:09 PM by sandor111 |
|
cpuminer-gc3355 v0.9g * Failover pool strategy is supported * Low reject rate (--no-refresh -> disabled) --url=stratum+tcp://pool1:port --userpass=user1:pass1 --url=stratum+tcp://pool2:port --userpass=user2:pass2 --url=stratum+tcp://pool3:port --userpass=user3:pass3 Pool 1 is the main pool, if it is down, it will try to connect to the backup pool(s) and query the main pool until it is back up and switch pools automatically. Will add support for config file soon. Binaries have been updated. Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zipRaspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355 |
|
|
|
|
sandor111
|
|
May 08, 2014, 09:38:26 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
|
|
|
|
ny2cafuse
Legendary
Offline
Activity: 1582
Merit: 1002
HODL for life.
|
|
May 08, 2014, 09:45:28 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
+1, kudos! -Fuse |
Community > Devs
|
|
|
RowanX
Member
Offline
Activity: 86
Merit: 10
|
|
May 08, 2014, 09:47:08 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Thanks, tried this with 0.9g but it says: minerd-gc3355: unrecognised option `--no-refresh'
Try `minerd --help' for more information. |
|
|
|
|
|
sandor111
|
|
May 08, 2014, 09:48:27 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Thanks, tried this with 0.9g but it says: minerd-gc3355: unrecognised option `--no-refresh'
Try `minerd --help' for more information.I did a little update while I was uploading v0.9g, redownloading the binaries should fix it. |
|
|
|
RowanX
Member
Offline
Activity: 86
Merit: 10
|
|
May 08, 2014, 09:53:25 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Thanks, tried this with 0.9g but it says: minerd-gc3355: unrecognised option `--no-refresh'
Try `minerd --help' for more information.I did a little update while I was uploading v0.9g, redownloading the binaries should fix it. OK got the new version now. This however finds my gridseeds, sets their frequencies, but then shows 0 speed and there is no activity in relation to accepted shares. Very curious. Anyone else getting this? |
|
|
|
|
|
wolfey2014
|
|
May 08, 2014, 10:07:10 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Sandor, I knew I was re-joining the debuggers club!  My HW error is at an all time high of 10+%! Anything over 0.40 is too much in average with previous versions. Right now, overall stats show R: 5%ish and HW: 10%ish.... I'm mining a 26 seed farm now by the way  More profits! Yeah! I want more!!  Will upgrading to Ver 0.9G help handle this problem with the 5 chippers too? I would assume so but just want to be sure before I upgrade for the 2nd time in one day...  Thanks W |
I Modify Miners Professionally! PM me for details!
|
|
|
|
reactor
|
|
May 08, 2014, 10:10:13 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Still curious about the cores not restarting until cold booted. Here is another example: [2014-05-08 22:08:11] 0: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:11] 2: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:12] 1: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:14] 0@0: Work_id differs (004b5f34 != 004be11c) [2014-05-08 22:08:30] 0@0: Work_id differs (004b5f34 != 004be11c) Except they never come back, this is ~10 minutes after starting and I am still getting old work id messages. In fact, this is right after all three units restarted, reset frequencies, and got new work dispatched. For reference, this is with .9g and using the no refresh option as well, watching blocks, work_id differs, and work dispatch, just never a share makes it through. Edit: And for reference, unplugged all three 5chips, plugged 'em back in, updated my script to the new /dev/tty's, and now they are working just fine, shares accepted left and right. And like I said, totally didn't happen before like .9e. I think it has to do with the core restarts, I notice even when staying in the same cpuminer instance when the 5chips reset and come back I often don't see every core come back. |
|
|
|
|
|
sandor111
|
|
May 08, 2014, 10:18:34 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Still curious about the cores not restarting until cold booted. Here is another example: [2014-05-08 22:08:11] 0: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:11] 2: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:12] 1: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:14] 0@0: Work_id differs (004b5f34 != 004be11c) [2014-05-08 22:08:30] 0@0: Work_id differs (004b5f34 != 004be11c) Except they never come back, this is ~10 minutes after starting and I am still getting old work id messages. In fact, this is right after all three units restarted, reset frequencies, and got new work dispatched. For reference, this is with .9g and using the no refresh option as well, watching blocks, work_id differs, and work dispatch, just never a share makes it through. Tried without --no-refresh? Sounds like there is a loose connection somewhere, as instead of the work_id, it's sending back garbage. |
|
|
|
|
reactor
|
|
May 08, 2014, 10:21:00 PM |
|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
Still curious about the cores not restarting until cold booted. Here is another example: [2014-05-08 22:08:11] 0: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:11] 2: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:12] 1: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:14] 0@0: Work_id differs (004b5f34 != 004be11c) [2014-05-08 22:08:30] 0@0: Work_id differs (004b5f34 != 004be11c) Except they never come back, this is ~10 minutes after starting and I am still getting old work id messages. In fact, this is right after all three units restarted, reset frequencies, and got new work dispatched. For reference, this is with .9g and using the no refresh option as well, watching blocks, work_id differs, and work dispatch, just never a share makes it through. Tried without --no-refresh? I originally had this problem on 0.9e, have had it on f and g as well. Just did a quick run through all three versions for kicks and each time when I close the session and start a new one I get the old work problem. So the problem existed before --no-refresh, at least locally for me. Maybe my RPi is just cursed.  |
|
|
|
|
edonkey
Legendary
Offline
Activity: 1150
Merit: 1004
|
|
May 08, 2014, 10:21:47 PM |
|
cpuminer-gc3355 v0.9g * Failover pool strategy is supported * Low reject rate (--no-refresh -> disabled) --url=stratum+tcp://pool1:port --userpass=user1:pass1 --url=stratum+tcp://pool2:port --userpass=user2:pass2 --url=stratum+tcp://pool3:port --userpass=user3:pass3 Pool 1 is the main pool, if it is down, it will try to connect to the backup pool(s) and query the main pool until it is back up and switch pools automatically. Will add support for config file soon. Wow! You are amazingly responsive! Thank you so much! |
Was I helpful? BTC: 3G1Ubof5u8K9iJkM8We2f3amYZgGVdvpHr
|
|
|
CartmanSPC
Legendary
Offline
Activity: 1270
Merit: 1000
|
|
May 08, 2014, 10:27:19 PM
Last edit: May 08, 2014, 10:39:20 PM by CartmanSPC |
|
Built v0.9g on Ubuntu and --gc3355-detect no longer works. Also the serial numbers are gone? Works using gc3355=/dev/ttyACM0,/dev/ttyACM1,etc *** glibc detected *** ./minerd: double free or corruption (out): 0x0000000001a42640 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fef1a88bb96]
/lib/x86_64-linux-gnu/libtinfo.so.5(_nc_last_db+0x16)[0x7fef1abdb316]
/lib/x86_64-linux-gnu/libtinfo.so.5(_nc_read_entry+0x12f)[0x7fef1abe1fbf]
/lib/x86_64-linux-gnu/libtinfo.so.5(_nc_setup_tinfo+0x29)[0x7fef1abdd559]
/lib/x86_64-linux-gnu/libtinfo.so.5(_nc_setupterm+0x98)[0x7fef1abdd8d8]
/lib/x86_64-linux-gnu/libncurses.so.5(newterm+0x6b)[0x7fef1ae038eb]
/lib/x86_64-linux-gnu/libncurses.so.5(initscr+0x62)[0x7fef1ae00732]
./minerd[0x404333]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fef1a82e76d]
./minerd[0x4045f5]
======= Memory map: ========
00400000-0044b000 r-xp 00000000 08:01 3147781 /home/sandor_is_king/cpuminer-gc3355/minerd
0064a000-0064b000 r--p 0004a000 08:01 3147781 /home/sandor_is_king/cpuminer-gc3355/minerd
0064b000-0064d000 rw-p 0004b000 08:01 3147781 /home/sandor_is_king/cpuminer-gc3355/minerd
01a42000-01a84000 rw-p 00000000 00:00 0 [heap]
7fef10000000-7fef1002a000 rw-p 00000000 00:00 0
7fef1002a000-7fef14000000 ---p 00000000 00:00 0
7fef14b01000-7fef14b16000 r-xp 00000000 08:01 655404 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fef14b16000-7fef14d15000 ---p 00015000 08:01 655404 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fef14d15000-7fef14d16000 r--p 00014000 08:01 655404 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fef14d16000-7fef14d17000 rw-p 00015000 08:01 655404 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fef14d17000-7fef14d18000 ---p 00000000 00:00 0
7fef14d18000-7fef15518000 rw-p 00000000 00:00 0 [stack:1382]
7fef15518000-7fef15519000 ---p 00000000 00:00 0
7fef15519000-7fef15d19000 rw-p 00000000 00:00 0 [stack:1381]
7fef15d19000-7fef15d22000 r-xp 00000000 08:01 655378 /lib/x86_64-linux-gnu/libcrypt-2.15.so
7fef15d22000-7fef15f22000 ---p 00009000 08:01 655378 /lib/x86_64-linux-gnu/libcrypt-2.15.so
7fef15f22000-7fef15f23000 r--p 00009000 08:01 655378 /lib/x86_64-linux-gnu/libcrypt-2.15.so
7fef15f23000-7fef15f24000 rw-p 0000a000 08:01 655378 /lib/x86_64-linux-gnu/libcrypt-2.15.so
7fef15f24000-7fef15f52000 rw-p 00000000 00:00 0
7fef15f52000-7fef15ff0000 r-xp 00000000 08:01 791549 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fef15ff0000-7fef161f0000 ---p 0009e000 08:01 791549 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fef161f0000-7fef161f2000 r--p 0009e000 08:01 791549 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fef161f2000-7fef161f4000 rw-p 000a0000 08:01 791549 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fef161f4000-7fef161f5000 rw-p 00000000 00:00 0
7fef161f5000-7fef1623a000 r-xp 00000000 08:01 795843 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fef1623a000-7fef1643a000 ---p 00045000 08:01 795843 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fef1643a000-7fef1643c000 r--p 00045000 08:01 795843 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fef1643c000-7fef1643e000 rw-p 00047000 08:01 795843 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fef1643e000-7fef1643f000 rw-p 00000000 00:00 0
7fef1643f000-7fef1644d000 r-xp 00000000 08:01 795837 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fef1644d000-7fef1664c000 ---p 0000e000 08:01 795837 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fef1664c000-7fef1664d000 r--p 0000d000 08:01 795837 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fef1664d000-7fef1664e000 rw-p 0000e000 08:01 795837 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fef1664e000-7fef16676000 r-xp 00000000 08:01 795840 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fef16676000-7fef16875000 ---p 00028000 08:01 795840 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fef16875000-7fef16876000 r--p 00027000 08:01 795840 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fef16876000-7fef16877000 rw-p 00028000 08:01 795840 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fef16877000-7fef1687a000 r-xp 00000000 08:01 655687 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
7fef1687a000-7fef16a79000 ---p 00003000 08:01 655687 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
7fef16a79000-7fef16a7a000 r--p 00002000 08:01 655687 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
7fef16a7a000-7fef16a7b000 rw-p 00003000 08:01 655687 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
7fef16a7b000-7fef16a7e000 r-xp 00000000 08:01 655683 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fef16a7e000-7fef16c7d000 ---p 00003000 08:01 655683 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fef16c7d000-7fef16c7e000 r--p 00002000 08:01 655683 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fef16c7e000-7fef16c7f000 rw-p 00003000 08:01 655683 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fef16c7f000-7fef16c90000 r-xp 00000000 08:01 795815 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0
7fef16c90000-7fef16e8f000 ---p 00011000 08:01 795815 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0
7fef16e8f000-7fef16e90000 r--p 00010000 08:01 795815 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0
7fef16e90000-7fef16e91000 rw-p 00011000 08:01 795815 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0
7fef16e91000-7fef16ea1000 r-xp 00000000 08:01 795817 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.12
7fef16ea1000-7fef170a0000 ---p 00010000 08:01 795817 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.12
7fef170a0000-7fef170a1000 r--p 0000f000 08:01 795817 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.12
7fef170a1000-7fef170a2000 rw-p 00010000 08:01 795817 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.12
7fef170a2000-7fef170b6000 r-xp 00000000 08:01 795809 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7fef170b6000-7fef172b5000 ---p 00014000 08:01 795809 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7fef172b5000-7fef172b6000 r--p 00013000 08:01 795809 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7fef172b6000-7fef172b7000 rw-p 00014000 08:01 795809 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7fef172b7000-7fef172e8000 r-xp 00000000 08:01 795834 /usr/lib/x86_64-linux-gnu/libhcrypto Command line: sudo ./minerd --gc3355-detect --freq=850 --gc3355-autotune --gc3355-timeout=1800 -o stratum+tcp://xpool.net:9555 -u KitKat -p x |
|
|
|
|
sandor111
|
|
May 08, 2014, 10:49:53 PM |
|
Can you try the latest commit, I think I just fixed that.  |
|
|
|
|
wolfey2014
|
|
May 08, 2014, 11:28:20 PM |
|
Sandor, I'm running 0.09f and it's causing my workers to get banned from the same pool I've been mining for days without issues using 2.3.2 .... it says the reason for it is 'worker invalid percent: 100 xxx.xxx STILL BANNED! Damn! Banned again!  The dev says it is definitely being caused by my mining program... What can I do to cure this short of reverting back to 2.3.2 again and waiting for this all to be debugged and stable? HELP! Edit: pool also reports that my miners are submitting 'invalid job not founds' your program is still submitting shares for a job already done... Edit deux! - now it's submitting valid shares again. I did nothing. It just like, fixed itself and got itself unbanned and shares accepted.... dev says that its a known issue with bfgminer and some cpuminers ,, doesn't update jobs fast enough or something... |
I Modify Miners Professionally! PM me for details!
|
|
|
|
fivejonnyfive
|
|
May 08, 2014, 11:32:41 PM |
|
I'll let it keep running for a while but methinks autotune is not working in this build. An hour and all the cores still at baseline... Lets see what happens overnight.
EDIT: The exact second I post this, boom: [2014-05-08 23:32:41] 0@1: Set GC3355 core frequency to 875Mhz
Disregard.
|
|
|
|
|
|
|
|
sandor111
|
|
May 08, 2014, 11:46:12 PM |
|
I'll let it keep running for a while but methinks autotune is not working in this build. An hour and all the cores still at baseline... Lets see what happens overnight.
EDIT: The exact second I post this, boom: [2014-05-08 23:32:41] 0@1: Set GC3355 core frequency to 875Mhz
Disregard.
--debug to keep track of how much steps are left before it changes the frequency. |
|
|
|
|
