I have a dumb question what do I put in to output the log in cpuminer?

I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips  Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .

It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.


I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is

minerd-gc3355 --freq=600  --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x

Thanks

Upload the full miner log (including debug output), maybe I can find something.
I haven't thoroughly tested on G-Blades, because I don't own one.

Thanks for your reply Sandor.  One thing I have always wondered about is when I have multiple gridseeds, or any other ASIC for that matter, do the ASICS actually work together to solve the work that the pool gives, or is each ASIC on its own trying to solve the work.

The reason I ask is I used to run individual cpuminer instances per ASIC, with each ASIC connected with its own worker name to the pool.  With that method, each worker had a low difficulty appropriate for its hashrate.  My hashrate was pretty consistent around 14,500 KH.  Never went much below or.above that.

Now, using your cpuminer, I have 21 gridseeds under one worker name, and since the hashrate is high, the pool gives them high difficulty.  This results in my hashrate fluctuating anywhere from 9,500 KH to 17,000 KH.

If each gridseed is indeed operating on its own, I would think the difficulty would be too high for a 340kh device and would be discarding work because it cannot solve it in time before the work becomes stale.

Any insight into this would be much appreciated.

I have been reading through the thread here and I have a couple problems I cannot seem to solve with the blades.
It starts out at over 12 mh/s but after and hour or two goes all the way down to 3.8 and stays there.  This is on clevermining, LTCRabbit and ScryptGuild.
This is with two Blades using CPUMiner.  I am not sure what to do.

Here is my argument.

I had tried with one Blade and autotune and got the same results.

I am not sure what I need to do to keep them running at full speed.

Any help would be appreciated.

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

That did the trick, thank you! I was googling and saw that article as well!

This command fixed my problems -- sudo usermod -a -G dialout myusernamehere

One other question...

My devices are running at 850mhz, and they are hashing at some oddball #'s according to the overview, are these #s correct? Via CGMIner they all hash around 360k each

GSD 0 | 850 MHz | 105.8/ 71.6 KH/s | A: 1 R: 0 H: 0
 GSD 1 | 850 MHz | 105.8/ 71.7 KH/s | A: 1 R: 0 H: 0
 GSD 2 | 850 MHz | 317.5/ 71.9 KH/s | A: 3 R: 0 H: 0
 GSD 3 | 850 MHz | 423.4/143.5 KH/s | A: 4 R: 0 H: 0
 GSD 4 | 850 MHz | 211.7/143.8 KH/s | A: 2 R: 0 H: 0
 GSD 5 | 850 MHz | 529.2/215.7 KH/s | A: 4 R: 1 H: 0

I am planning on switching over 50 gridseeds and running them on ubuntu. My raspberri pi's are piss poor and unreliable. They have constant kernel crashes and the onlything I can do to get them going again is to power them down manually and reboot them.

Here is my current config:

screen -dmS miner ./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5 --gc3355-freq=/dev/ttyACM0:850 --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=blah:blah --retries=1

I have 3 questions:

• 1. Is this running in dual mode or single? (I hope single scrypt mode -- lol)
• 2. Is it possible to run minerD with a config similar to cgminer (./cgminer -c miner.conf). I want to have multipools as failovers incase one goes down and its easier to run from a config file. I couldn't find any documentation on this at all.
• 3. If I plan on runnijng 50 devices, do I need to list every device in the command line to launch? IE: --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5/etc/etc/etc to 50

Thanks for your help and I hope that this runs more stable than CGMiner, if it does some donations will be due to you. I lose about 8 hours of mine time every day  when I am away and cannot hard power my rasp pis.

Sorry to jump in your thread..

I am having an issue with CPUminer myself on Ubuntu. I cannot get any of my miners to mine and I am getting an error that I don't have user privlidges to open /dev/xxx... Any ideas how to fix this?

 [2014-04-30 10:15:37] 4: Do not have user privileges to open /dev/ttyACM4
 [2014-04-30 10:15:37] 4: Terminating GC3355 chip mining thread
 [2014-04-30 10:15:37] 5: GC3355 chip mining thread started, in SINGLE mode
 [2014-04-30 10:15:37] 5: open device /dev/ttyACM5
 [2014-04-30 10:15:37] 5: Do not have user privileges to open /dev/ttyACM5
 [2014-04-30 10:15:37] 5: Terminating GC3355 chip mining thread

It's a work in progress, people shouldn't expect perfection with every release. 

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  

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

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

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

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.

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

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

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?