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

[fivejonnyfive]

Thanks for answering the Q about multiple mini's!

Just sftpd the newest binary on there. Thanks for the update, I'll let you know if I see anything funky on RPI.

edit:I can confirm the top stats thing isn't an issue on rPi but it sounds like you had already isolated that as a windows only thing.

[naimc3243]

A few questions about the Sandor11 cpuminer when used with 5 chip gridseed

1. How do you know the Autotune has completed ? From what I understand Autotune will increase is small steps 25 Mhz if not more than 3 hardware errors are detected if this is the case it drop down by 25 Mhz.

I just see these type of messages

[2014-04-29 22:33:4.217] 8@0 850MHz: Got nonce 70fe0200, Hash <= Htarget!
[2014-04-29 22:33:4.219] 8@0: 2821 steps until frequency adjusts to 875MHz
[2014-04-29 22:33:4.232] 8@0: accepted 3/3 (100.00%) 72.0/143.5/2152.9 (Pool: 2391.5) KH/s

I've never seen any message about Autotune having  completed  how is the end result displayed

2. Is it possible to dual mine Scrypt and SHA256 using Sandor11 cpuminer, and or in conjunction with another miner.

3. I have one Gridseed miner that only has a red flashing LED, Green one never turns on. it seems to be working fine. this is a replacement unit from ZoomHash wondering if I have another lemon.

cpuminer-gc3355 - Started: [2014-04-29 22:32:07]
=============================================================================
(2s) | 0.00/0.00 MH/s | A: 0 R: 0 HW: 0
Connected to useast.wafflepool.com:3333 diff 512 with stratum as user 1.........
=============================================================================
GSD 0 | 850 MHz | 522.2/287.3 KH/s | A: 7 R: 1 H: 0

=============================================================================
[2014-04-29 22:40:00] Stratum detected new block
[2014-04-29 22:40:00] Dispatching new work to GC3355 threads (0x6280ca50)

thank you.

[surgexvb]

The previous update was working great, but the most recent after the TUI recode and stratum fix crashes after about 2 hours.  The previous version was running solid for 15 hours until I stopped to update.  I can still view the screen but all text has stopped updating on the worker is not online anymore.  Very similar looking crash to the update from 2 revisions ago, before the "TUI stuck" issue was addressed.  I'm sorry if this is no help.   

RBPi with 3.10.30+ kernel
All updates done
21 5 chip miners

[sunderstan]

The previous update was working great, but the most recent after the TUI recode and stratum fix crashes after about 2 hours.  The previous version was running solid for 15 hours until I stopped to update.  I can still view the screen but all text has stopped updating on the worker is not online anymore.  Very similar looking crash to the update from 2 revisions ago, before the "TUI stuck" issue was addressed.  I'm sorry if this is no help.   

RBPi with 3.10.30+ kernel
All updates done
21 5 chip miners

Have you tried running the program in background? (With -t option, TUI will be disabled)
Mine has been running for 8 hrs without problem, using the latest binary on RPi with -D and -t option.
However the drop out issue on Windows 7 seems still persist even with FIFO is disabled. So I'm sticking with PRi build now. With log output and web interface it's still manageable

[Kergekoin]

Yes, same for me. Two latest versions still freeze after some hours.
Im back to old version currently.

[gbyg]

The previous update was working great, but the most recent after the TUI recode and stratum fix crashes after about 2 hours.  The previous version was running solid for 15 hours until I stopped to update.  I can still view the screen but all text has stopped updating on the worker is not online anymore.  Very similar looking crash to the update from 2 revisions ago, before the "TUI stuck" issue was addressed.  I'm sorry if this is no help.  

RBPi with 3.10.30+ kernel
All updates done
21 5 chip miners

Have you tried running the program in background? (With -t option, TUI will be disabled)
Mine has been running for 8 hrs without problem, using the latest binary on RPi with -D and -t option.
However the drop out issue on Windows 7 seems still persist even with FIFO is disabled. So I'm sticking with PRi build now. With log output and web interface it's still manageable

Which webinterface you using for rassbery pi?

[PVmining]

love the single chip autotune function!
is there an easy way to write out the autotune result to use it the next start?

using current version on raspbian.


@sandor111 - great work!
it would be the perfect combination with scripta, or hashra...

[plzt]

Yes, same for me. Two latest versions still freeze after some hours.
Im back to old version currently.

I believe I'm 2 versions behind and have now been running stably on Win7 for over 24 hours without a problem (1 blade for now)

Just a suggestion though - might be worth putting a version number at the top, somewhere on the:
 cpuminer-gc3355 - Started: [2014-04-29 00:36:40]
line as then we could give you better debug feedback!

[sandor111]

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

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.

[ryen123]

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

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.

The binaries on github not updated yet?

[nst6563]

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

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.

Are the links to the binaries updated?  I downloaded the 'new' version and still have the same problem as before with the top stats - and the dropbox link says "13 hours ago".

[sandor111]

Try now, Dropbox behaving strangely.

is there an easy way to write out the autotune result to use it the next start?

For now, the best way is to turn on logging (--log), and CTRL+F "0@0: autotune stopped", "0@1: autotune stopped", ... Pretty tedious if you have lots of miners or G-Blades.
I'm going add a config generator to the autotune feature.

[wolfey2014]

Try now, Dropbox behaving strangely.

Checked my miners this morning. The whole smash is CRASHED!
NOT HAPPY! 
FIX IT PLEASE!

[Kergekoin]

New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .

[sandor111]

New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .

Sorry, some issues with Dropbox not updating the files, try re-downloading please.

[ryen123]

Just updated to the new binaries. Working great for me.

[sandor111]

New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .

I wish you'd tell me earlier about it only listing 30 miners, now I have to recompile again :|
Edit: Fixed + added miner version.

[nst6563]

Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method? 

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   

[RowanX]

I had no problems overnight running the first version compiled today (30 Apr) - windows version, that is. Now using the 3rd compile of today, v0.9a. Top stats are working.   Thanks as ever for your work.

[sandor111]

Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method?  

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory  

It's none of that. The curses TUI isn't thread safe, so I have to use pthread_mutex to keep stuff synchronized between threads. My shitty coding lead to some deadlocks I think, where one thread was waiting forever for a lock to release. I have no idea about the top stat on Windows though, the same code works perfectly fine on any Unix system I tested (Rpi, Ubuntu, OpenWrt) which are using ncurses lib, so I guess it's a bug in the pdcurses lib which Windows uses (specifically printw/wprintw).