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

[wolfey2014]

G'day yall!

I found 2 of my miners dead when I checked them this morning. A comm port reset (disable/enable) took care of it, thank goodness!
But after running for weeks upon weeks without any drop out issues, this is very disconcerting. I don't need pod disconcert in my life! GO AWAY! 

So this didn't happen until I reverted to the previous version of Sandor111's latest updates.
Oh, and I see pretty much the same issue with this version where sticking at over 1200MHz happens too.
Perhaps they kicked off line after being pushed too hard for so long. Not sure. Or it's just a uP fart caused it. Who knows. I am not looking forward to having keep an eye on the drop out issue again, dammit!

The previous update version has the same 'stuck at 1225+' problem as the current one does.
Have you corrected this issue Sandor? I see you've been busy correcting the TUI issue.
Perhaps I missed an update while catching up on this thread.

I just fixed the scrolling issue. Like the others did, I simply resized the window, restarted and voila!
Now if we can just get auto-tune fine tuned and the red/green color indicators back....
I would have loved to see right off the bat which miners were dead in RED. But I could obviously tell because they were showing 000 speed, so.........
Miners hashing = GREEN / Miners not hashing = RED
It needs to work a little bit better where lowering clock speeds goes. I thought it was finding a good balance before in a couple versions back but I am not clear on which one now. I want to keep my miners mining / making profits so I'll wait for Sandor to sort it out. Thanks Sandor!

Thanks!

[1714756056]

1714756056

[1714756056]

1714756056

[1714756056]

1714756056

[1714756056]

1714756056

[1714756056]

1714756056

[Kergekoin]

Yes, thanks wolfie.
So heres how you see scrolling info + all your devices if you have many of them.
1. launch cmd
2. drag your cmd window longer
2. navigate to your minerd
3. type your minerd.bat and enter.
 

[wolfey2014]

Yes, thanks wolfie.
So heres how you see scrolling info + all your devices if you have many of them.
1. launch cmd
2. drag your cmd window longer
2. navigate to your minerd
3. type your minerd.bat and enter.
 

Right.
I actually just right clicked the top of the TUI and reset length then restarted it so it will be the same setting every time from now on by simply running the bat.
No biggie.

[csmflynt3]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

[wolfey2014]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

Sounds like a common problem solved by:
If you're using Win7 or later, try turning off FIFO buffers in your comm port (advanced) settings in device manager.

[csmflynt3]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

Sounds like a common problem solved by:
If you're using Win7 or later, try turning off FIFO buffers in your comm port (advanced) settings in device manager.

Yes I definitely did this when you first brought it up in one of the other forums. That was a good call for sure. Its not a big deal I will just stick with the older version on my blades for now. I am sure it something screwed up with my hardware/drivers if no one else has this issue. I will keep playing around with it though.

[sandor111]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

A full miner log would help here.

[ryen123]

Noticed when running the latest TUI build, when I use the --debug flag the miner stops running after 12+ minutes. Running normal without --debug flag everything running fine. My pc running win7 x64.

[wolfey2014]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

A full miner log would help here.

please clear something up for me, why the loop? Normally, in both instances, those commands only need to be run once, then it's off and running, right?
tanks

[csmflynt3]

My 5 Chip gridseeds run for hours without any issues and with TUI enabled, but my blades have a lot of issues. For some reason they just stop hashing on this version after 30 minutes or so even with the TUI disabled. They worked fine on your previous version (cpuminer-GC3355-win32-sandor111) so not sure what I am doing wrong. I just have 2 separate bat files for the 5 chip and blades.

This is for the blades I tried it with auto tune enabled/disabled with no difference. I lowered the Frequency from 838 to 825 to 800 and does not seem to be related to the freq setting.

:loop
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://us-east2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18  --url=stratum+tcp://us-west2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
minerd-gc3355 --freq=825 --gc3355=\\.\COM17,\\.\COM18 --url=stratum+tcp://eu2.multipool.us:7777 --userpass=XXXX.XXXX:X --retries=1
goto loop
pause

What happens is I see cpuminer still dispatching work , but no response from the blades anymore.

Thanks

please clear something up for me, why the loop? Normally, in both instances, those commands only need to be run once, then it's off and running, right?
tanks

I thought the loop was needed for the failover pools I think i saw this in the readme

[sandor111]

There is a major bug (typo) in the current build that is affecting mining and HW errors, I will provide a fix ASAP.

[fivejonnyfive]

This is working great for me on a raspi. I just ordered 2 more gridseeds...

Would the syntax for my new script have this in it:

Code:

--gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2

I'm just a little confused because in the readme you mention ttyACM1 and ACM2 being blades - but I'm not sure if I have to tell cpuminer whether the hardware is a blade or a mini. If I understand the documentation correctly it auto-detects the number of chippys.

Anyway - great work, thanks for the help. Expect a tip.

[unamis76]

i keep getting failed to open /dev/ttyACM0

I am running on Raspberry pi:
./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5,/dev/ttyACM6,/dev/ttyACM7 --freq=1000 --gc3355-autotune --url=stratum+tcp://usa-1.liteguardian.com:3335 --userpass=cxxx:x --retries=5

I have the same problem ... I'm using Kernel ... 3.10.37+

I don't have any ttyACM0 in my dev folder ... got 9 Blades connected thru 2 x 10 port usb hubs ... working well with cgminer ...

Having exactly the same issue, am I forgetting something or is there a workaround?

IIRC cgminer uses a different driver than cpuminer/bfgminer. Try modprobe cdc_acm and see if that helps.

Thank you, will try when I have time available to play with my rig.

I had the same problem trying to use cpuminer after having just used cgminer. Could not get a listing of any ttyACM devices. Quick fix was to reboot and start cpuminer without first using cgminer.

Already tried it, did not work, but thanks

Running it as root should clear up that problem.

Already tried this also but it did not help but thanks anyway!

[sandor111]

Important! You MUST update to the latest binaries (Download on Github)

In this update the TUI code is rewritten, it accepts any window size and if the window isn't large enough, you can scroll through the stats using the UP/DOWN keys.
Fixed the biggest bug yet related to crashes/stuck/flooding of HW errors, it's really critical to update now!

This is working great for me on a raspi. I just ordered 2 more gridseeds...

Would the syntax for my new script have this in it:

Code:

--gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2

I'm just a little confused because in the readme you mention ttyACM1 and ACM2 being blades - but I'm not sure if I have to tell cpuminer whether the hardware is a blade or a mini. If I understand the documentation correctly it auto-detects the number of chippys.

Anyway - great work, thanks for the help. Expect a tip.

G-Blades are 2 boards, so 2 ttyACMx. No need to tell it, it detects which is which based on the firmware version thats on the MCU chip.

[wolfey2014]

Important! You MUST update to the latest binaries (Download on Github)

In this update the TUI code is rewritten, it accepts any window size and if the window isn't large enough, you can scroll through the stats using the UP/DOWN keys.
Fixed the biggest bug yet related to crashes/stuck/flooding of HW errors, it's really critical to update now!

This is working great for me on a raspi. I just ordered 2 more gridseeds...

Would the syntax for my new script have this in it:

Code:

--gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2

I'm just a little confused because in the readme you mention ttyACM1 and ACM2 being blades - but I'm not sure if I have to tell cpuminer whether the hardware is a blade or a mini. If I understand the documentation correctly it auto-detects the number of chippys.

Anyway - great work, thanks for the help. Expect a tip.

G-Blades are 2 boards, so 2 ttyACMx. No need to tell it, it detects which is which based on the firmware version thats on the MCU chip.

All miner types or just blades?
Link? Url? File name? Please?

[nst6563]

Important! You MUST update to the latest binaries (Download on Github)

In this update the TUI code is rewritten, it accepts any window size and if the window isn't large enough, you can scroll through the stats using the UP/DOWN keys.
Fixed the biggest bug yet related to crashes/stuck/flooding of HW errors, it's really critical to update now!

G-Blades are 2 boards, so 2 ttyACMx. No need to tell it, it detects which is which based on the firmware version thats on the MCU chip.

Thanks Sandor!  Testing it out now.

For those missing the link:  https://github.com/siklon/cpuminer-gc3355/  (It's also in Sandor's sig)

[RowanX]

Sandor, the topline stats are not updating in the new version? My screenshot:

http://snag.gy/D6aPH.jpg

They still show A:0 and 0 MH/s speed even after some time when shares have been accepted and mining is in progress.

[nst6563]

Sandor, the stats are not updating in the new version? My screenshot:

http://snag.gy/D6aPH.jpg

They still show 0 and 0 speed even after some time when shares have been accepted and mining is in progress..

I can confirm.  I'm seeing the same thing here.  The individual gridseed hashrates are updating, but the "total" at the top always says 0/0.  Sometimes there's a "-" in front, but always 0.

Edit:  Also looks like the Total number of accepted isn't updating past 1.  So far each gridseed says 10+ accepted but the total at the top still says 1.

[sandor111]

No idea why the top stat is bugged in Windows, seems to be some sort of memory corruption or bug in the library, the function that's causing it is "wprintw".
I'll have look in Valgrind.

[nst6563]

No idea why the top stat is bugged in Windows, seems to be some sort of memory corruption or bug in the library, the function that's causing it is "wprintw".
I'll have look in Valgrind.

If it helps any, it looks like the Total accepted is the same as total hw errors.  I've been periodically checking and happen to see both numbers change to the same number at the same time.