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

is there a special way to kill the fan? can i just cut the wire?

Thanks for getting back to me. I guess I can change rc.local to call a script that either implements a delay or calls something that waits for resources to be available.

Ahh I was wondering about that myself. Thanks!

That's not windows ready though right? I'd have to compile it myself from the binary which I'm not so keen on doing if it's been done already. The reason I need this is because I'm getting the 10 minute no-hash thing going where it just keeps getting new work_id but not submitting. I have the reset going but that takes awhile to ramp up to full speed and it happens way to often.

It's probably being started to early, when the filesystem and networking aren't fully initialized yet. One solution would be to add a sleep 30.

I'm using cpuminer v1.0a under Ubuntu 12.10. I've got the minerd application set to load via rc.local as part of a Minera installation.

I've got a problem after a reboot where minerd goes into a weird state where it doesn't hash anything. When I grab the stats with a python script I wrote, I see the following weirdness:


If I manually stop and start minerd, it starts working. But that kind of the defeats the purpose of the auto restart feature.

Any ideas what might cause this? Maybe minerd is being launched too early, where certain system resources are not yet available?

I posted this in the Minera thread, but it seems like this is an issue with cpuminer being started under rc.local.

I upgraded to 1.0b for CPUMiner and am experiencing a weird issue, not sure if anyone else is seeing this.

When running, I'll experience the occasional New job > Chips reset > Chips get new work and everything continues to process like awesomeness.  Everything is running very stable and all blades are averaging over 2.8MH per side, so I'm a happy camper.  But this morning I noticed a slight down-tick from my pool average so I went to investigate.

Long story short, every time one of these work resets happens I get a kworker.  They're matched to the usb locations of blade halves, so eventually I'll have kworker/0:2, kworker/0:0, etc., littering my processes.  And bogging down my RPi.  While doing this research and at some point after it hit eight kworkers (for the 4 blades on this pi) the cpuminer instance stopped reporting work, verified poolside.  So I killed my processes and went about restarting my mining loop and CPUminer just hung with no output.  Looked and sure enough all eight kworker instances were there, however I cannot 'kill' them whatsoever, even prevented a reboot from the command line.  Cold-rebooting my system cleared everything as expected, but now I'm running again and noticing the kworkers.  

I started the process when I began writing this post, right now I've got three kworkers going.  Will update if this keeps up, but may downgrade back to .9e (last place my blades lived happily without hassle).  Anyone else seeing this?

Edit: Since I'm now monitoring for this, just noticed I went from kworker/0:2, 0:0, 0:1 to just kworker/0:2,0:0 over the course of a few minutes.  So I'm not sure if these are processing that aren't terminating correctly or if there *should* be a kworker(s) sitting there threading out the work.

The first is the effective hashrate (pool hashrate), the second is the current hashrate. The first will tend to get closer to the second over time.

Current 'average' / Long 'average'

Not sure what span current covers, but when my miners start up the first value remains high and the second catches up over time.

Don't remember if someone asked for it here btw Minera image file for Raspberry PI is ready to be downloaded if you wanna give a try without the worry of install/ssh anything.

http://j.mp/minera-latest-img

Please refer to the README here.

Official forum thread is here: https://bitcointalksearch.org/topic/minera-v090-your-next-mining-dashboard-s9l3d3cpuminercgminerbfgminer-596620

Enjoy it.

Does anyone know what the 288.7 means?

Autotune once if using cpuminer of sandors.

once autotune is done

remove autotune from json.

start.

So I should autotune once, for several hours (maybe overnight) with the -debug and -log.

Then sift through the log to get all the values, plug it into the config, and start.

+1 - I agree with ya! Good observation! I concur!

Toxic0n, I've encountered a similar issue with my gblade, with 1.0a and b, on ltcrabbit.com. On a vardiff port, I was eventually pushed up to 512 diff and within hours, sometimes only minutes of hitting diff 512 I would get this connection issue. Ltcrabbit doesn't have any option for fixed difficulty, except a fixed 16 diff port. I've been using the 16 diff port for nearly 48 hours no with no issue at all. I'm looking for a good multipool that offers fixed diff settings now to test further... Hope this helps.

or

log.log will work as well

like

--log=log.log

"log" : "log.log"

amazing no one ever checks the helpfile....it's the little things that get ya

I got it by using the cmd line


so my .bat looks like


Ty, to nst6563 and reactor and --help LOl


I'm on my way to tuning.

---

Edit

lmao that was a difficult one for all three of us LOL. rofl. right in the --help file derp.

I tried cmd line way to.

C:\Users\Admin\Desktop\minerd-gc3355>minerd-gc3355.exe -c config.json --log
minerd-gc3355.exe: option `--log' requires an argument
Try `minerd --help' for more information.

C:\Users\Admin\Desktop\minerd-gc3355>pause
Press any key to continue . . .

K I will pm the json.

If you want to be super-safe, use Sandor's example config and just modify it, making sure starting/trailing braces are always there.  If you put the log at the end of the file, make sure it looks like so:

"log" : true
}
 
The } will be closing out the object.  I'm on right now, feel free to PM me the json and I can look at it for 'ya.