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

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.

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

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.

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.
 

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!

Hi,

I now have 20 5 chip miners (only 18 seem to work, 2 just won't hash. Even when connected individually) and 1 G-Blade (2x 40 chip)

I'm currently using 3 batch files: 1 that starts the 5 chip miners and 2 separate for the Blade (originally, both 2x 40 chip were in one file as default, but then only 1 would hash and be seen..)

Since it would be easier to have 1 batch for all: what should i put in the batch file? How to setup?
I run it from Windows (8.1), and it is setup to run at startup (in case my system restarts)

Ideally it would show the individual speeds of the miners in both cpuminer as the pool.
(Now each miner is identified as BTCaddress_miner1, .., BTCaddress_blade, BTCaddress_gpu for easy managing (this is how i found miner 18 and 20 do not show up)

Thanks,

Andre

Hahah, I figured this myself and even posted it here, but later i modified the post, because i thought it was silly... 
Anyway, thank you very much for the fix.

For what it's worth I don't have the problem of the missing scrolling data and I'm running Win 8.1.  No special command line arguments or settings  either.

Great!!! What command can i use to watch the TUI output of CPU miner while it is running in background? I m using RPI with Debian wheezy.

I have found the issue, it's when the terminal screen isn't large enough to display the stats/logs, hence that part isn't 'drawn' by curses. I will provide a fix that will automatically resize the terminal in case it's too small.

It's hardcoded that if there are 3 HW errors, it will decrease the frequency by 25 MHz and restart the counter. Any time the frequency decreases, that's the new limit and the frequency can't be set past that during autotune.
Btw I would suggest using the latest binary, it has a bugfix regarding autotune.

I've found some strange thing about auto-tune. I'm running the binary that built @ 26/4, will test the latest binary later and see if the same things happens. Let's take a look at the log:

[2014-04-29 08:19:31.024] 0@0 900MHz: Got nonce 4d582300, Invalid nonce! (1) (0x6074f142)
[2014-04-29 08:19:31.030] 0@0: 3596 steps until frequency adjusts to 875MHz
[2014-04-29 08:19:35.698] 0@1 875MHz: Got nonce 1eda5a33, Hash <= Htarget! (0x6074f142)
[2014-04-29 08:19:35.699] 0@1: 691 steps until step counter restarts
[2014-04-29 08:19:35.898] 0@1: accepted 4441/4461 (99.55%) 74.2/367.9/367.9 (Pool: 369.5) KH/s
[2014-04-29 08:19:38.873] 0@1 875MHz: Got nonce 5b725e33, Hash <= Htarget! (0x6074f142)
[2014-04-29 08:19:38.874] 0@1: 608 steps until step counter restarts
[2014-04-29 08:19:39.074] 0@1: accepted 4442/4462 (99.55%) 74.2/367.9/367.9 (Pool: 369.5) KH/s
[2014-04-29 08:19:42.882] 0@2 900MHz: Got nonce 158c9766, Hash <= Htarget! (0x6074f142)
[2014-04-29 08:19:42.883] 0@2: 276 steps until step counter restarts
[2014-04-29 08:19:43.081] 0@2: accepted 4443/4463 (99.55%) 75.7/367.9/367.9 (Pool: 369.6) KH/s
[2014-04-29 08:19:55.617] 0@2 900MHz: Got nonce 9260a666, Hash <= Htarget! (0x6074f142)
[2014-04-29 08:19:55.618] 0@2: 193 steps until step counter restarts
[2014-04-29 08:19:55.816] 0@2: accepted 4444/4464 (99.55%) 75.7/368.0/368.0 (Pool: 369.6) KH/s
[2014-04-29 08:20:0.446] New job_id: 38d2 Diff: 83
[2014-04-29 08:20:0.447] Dispatching new work to GC3355 threads (0x60b0d1af)
[2014-04-29 08:20:11.092] 0@0 900MHz: Got nonce e6200c00, Hash <= Htarget! (0x60b0d1af)
[2014-04-29 08:20:11.099] 0@0: 3513 steps until frequency adjusts to 875MHz

Core 0 Got an HW error in 900Mhz. However if looking at the bottom of the log, it's still running @ 900Mhz and counting down steps before backing down the frequency to 875Mhz. I wonder if too many HW error occurs will the next frequency decrease unrealistically instead of just backing down a step? Any idea guys?

with --text flag minerd window prints text correctly. Somehow default option of printing frequencys and info for each miner gets ignored. I dont know if its win8 issue since wolfey screenshot shows several devices listed.

I'll have per chip stats added soon, just thinking about the best way to display it, obviously trying to display stats of one G-Blade's chips isn't even going to fit on the console screen.
Serial number is tricky, that involves using the libusb lib which cgminer uses, I'll see if there is another way though.

Compiled and running...will check it in the morning. Do you think there is enough room at the top for per chip stats? Also if you could display the serial number that would be good for identifying miners. Just some suggestions

You can track my stats here: http://xpool.net:9555/
I'm currently the only miner there with 19 GS's. You can see just before I started using this new version I was testing dual mining there. It results in a lower scrypt hash rate and higher stale rate. Two of my miners are really slow on scrypt (50-120Kh/s) when dual mining. The rest are 300+. All of them are 360+ running just scrypt.

I am impressed with their SHA performance though. Get about 11.8 Gh/s each.

Running it as root should clear up that problem.


Thanks for the great work Sandor!  Sent  .04 btc your way!

That is strange, should work without enabling anything. I see Wolfey2014 has the same problem.
It might be related to Win 8, if you have a Win 7 machine you can try there.


Thanks for this, this will be helpful for others.

Testing, but still not getting more data  printed than the screenshot above. Should be enabled by default?

Have fixed the freeze/stuck when the TUI is enabled (atleast I hope so), Win/Rpi binaries have been updated. Also fixed the compiling issue some of you had with the curses libs.

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.