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

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

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

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

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.

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.

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.

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.

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.

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.

Thanks Sandor!  Testing it out now.

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

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

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.

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


Already tried it, did not work, but thanks


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

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:


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.

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

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

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

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.

A full miner log would help here.

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.