[GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 20.

RowanX

member

Activity: 86

Merit: 10

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: sandor111 on May 08, 2014, 05:49:53 PM

Can you try the latest commit, I think I just fixed that.

Yes, works now. Major props!

kskwerl

full member

Activity: 322

Merit: 100

I have 16 Gridseed blades and they restart quiet frequently how does everything look to you guys?

http://imgur.com/SePdnpg

I'm using this controller

http://www.gawminers.com/gaw-miners-server-mining-controller/

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: Zeta0S on May 08, 2014, 06:35:41 PM

Is this True?
https://www.youtube.com/watch?v=CjTcdhzfKIc

Can scrypt miners be that fast !?

Yes it's real...but I would skip it. They want too much for it ($10k) and for that cost you will soon have 300Mh+

wolfey2014

sr. member

Activity: 378

Merit: 250

Quote from: wolfey2014 on May 08, 2014, 06: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! Angry

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

Sandor, its rejecting again... "reject reason job 1215 not found"- and it keeps repeating this over and over....
whats the bug?
Can you correct this in ver 0.09i ?

Love the TUI etc, HATE the bugs!

sandor111

hero member

Activity: 616

Merit: 500

Quote from: fivejonnyfive on May 08, 2014, 06: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.

--debug to keep track of how much steps are left before it changes the frequency.

Zeta0S

legendary

Activity: 1890

Merit: 1031

Is this True?
https://www.youtube.com/watch?v=CjTcdhzfKIc

Can scrypt miners be that fast !?

fivejonnyfive

sr. member

Activity: 294

Merit: 250

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

wolfey2014

sr. member

Activity: 378

Merit: 250

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! Angry

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

sandor111

hero member

Activity: 616

Merit: 500

Can you try the latest commit, I think I just fixed that.

CartmanSPC

legendary

Activity: 1270

Merit: 1000

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

Code:

*** 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:

Code:

sudo ./minerd --gc3355-detect --freq=850 --gc3355-autotune --gc3355-timeout=1800 -o stratum+tcp://xpool.net:9555 -u KitKat -p x

edonkey

legendary

Activity: 1150

Merit: 1004

Quote from: sandor111 on May 08, 2014, 04:01:25 PM

cpuminer-gc3355 v0.9g

* Failover pool strategy is supported
* Low reject rate (--no-refresh -> disabled)

Code:

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

reactor

sr. member

Activity: 420

Merit: 250

Quote from: sandor111 on May 08, 2014, 05:18:34 PM

Quote from: reactor on May 08, 2014, 05:10:13 PM

Quote from: sandor111 on May 08, 2014, 04: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.

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

sandor111

hero member

Activity: 616

Merit: 500

Quote from: reactor on May 08, 2014, 05:10:13 PM

Quote from: sandor111 on May 08, 2014, 04: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.

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

sr. member

Activity: 420

Merit: 250

Quote from: sandor111 on May 08, 2014, 04: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.

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.

wolfey2014

sr. member

Activity: 378

Merit: 250

Quote from: sandor111 on May 08, 2014, 04: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.

Sandor,
I knew I was re-joining the debuggers club! Cry

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 Wink

More profits! Yeah!
I want more!! Grin

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

Thanks
W

RowanX

member

Activity: 86

Merit: 10

Quote from: sandor111 on May 08, 2014, 04:48:27 PM

Quote from: RowanX on May 08, 2014, 04:47:08 PM

Quote from: sandor111 on May 08, 2014, 04: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.

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?

sandor111

hero member

Activity: 616

Merit: 500

Quote from: RowanX on May 08, 2014, 04:47:08 PM

Quote from: sandor111 on May 08, 2014, 04: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.

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

Activity: 86

Merit: 10

Quote from: sandor111 on May 08, 2014, 04: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.

Thanks, tried this with 0.9g but it says:

minerd-gc3355: unrecognised option `--no-refresh' Try `minerd --help' for more information.

ny2cafuse

legendary

Activity: 1582

Merit: 1002

HODL for life.

Quote from: sandor111 on May 08, 2014, 04: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.

+1, kudos!

-Fuse

Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 20. (Read 308847 times)