Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 622. (Read 5805874 times)

Yeah there's been a few FPGA changes (and related pull requests) since the last release and ckolivas started his 'break'
There also needs to be more work done on the interaction between Icarus and Bitforce
(so that by default Bitforce doesn't die with an Icarus device plugged in - though Luke-jr has sent a pull 'work around')

yeah I might do that, I have a compiled luke-jr binary that shoes the temps right now i have the original version of cgminer running with gpu/bf and not just showing temps (it does throttle after all) but it would be nice to see the temps

thanks

I originally was running a single instance of cgminer, but I changed to two instances. One for the GPUs, one for the BFL Singles. For the GPU ionstance I compiled without the bitforce configuration. For the BFL cgminer I run kano's version with --disable-gpu.

Maybe you can just run two instances until a windows binary becomes available.

its not in the latest windows version, I have a linux binary from the git with it compiled in to show temps but it wasnt compiled with openGL - so I cant run the Bitforce on the same machine as GPUs which I need to do in this situation.

I thought temps were already in v 2.3.1
API: kano worked on this. I already have this running, on ubuntu. 

https://github.com/kanoi/cgminer

Screenshot here
https://bitcointalksearch.org/topic/bash-scripts-for-rpc-interface-to-cgminer-suggestions-welcome-66779

any idea if Bitforce temps and API stats will be included in next version?

Or pay ANUBIS developer a bounty to support remote rebooting.  It would be OS specific but can be done.

Theoretically everything can be done through a web interface (troubleshooting, monitoring, modifying configurations, restarting miner, rebooting rigs, powering off rigs).  SSH could simply be used as a "last resort" to troubleshoot a rig with broken web control panel.

There are web interfaces!  That is the whole point of some of us putting up a huge bounty to get RPC access into cgminer.

cgminer IMHO should focus on being the best ENGINE.  With RPC it can be controlled via web interface, and android app, a windows GUI, or any other interface someone desires.  Take a look at ANUBIS and cgminer web monitor for examples of alternate interfaces.  If the existing web interfaces don't do everything you want them to then support those authors via bounties.  

IMHO cgminer would have absolutely no interface at all.  Simply operate as a silent daemon and users would interact with it via RPC calls much like how bitcoind works.  Still there are advantages to a minimal interface for debugging and testing.  Tightly coupling cgminer to a web interface would be bad.  It would also defeat the purpose of RPC API.  The API exists to allow 3rd party apps to interact with cgminer. 

A last technical issue is conman has a lot of code to maintain and improve.  He has indicated he doesn't like GUI work.  RPC provides a perfect split.  Those that like user interfaces can treat cgminer as a black box and code interfaces using the RPC.  Conman meanwhile is able to focus on making cgminer engine the most efficient and possible and know that others are making "pretty" interfaces. 

BTW as a side note:
you can't run cgminer under local system because in Win7/Vista video drivers are user mode drivers.  No user logged in = no GPU access.

I don't know why did I miss this miner earlier, I started to use, it's very practical, now I don't have to use clocktweak and 4 phoenix miners. And, it's even giving me 20 MH/s more per card with 12.1 than phoenix with 12.1. I think this gem needs more advertising to newbies.

Would only work on XP. Windows 7 requires the user to be logged in, since the display drivers run in usermode, not kernelmode.

Thinking about it. Running as a service it's like Windows without windows. I like that. So for every miner setup, I would have the privilege of buying a copy of Windows to not use windows. Hmm. Somehow, I think this is not the most profitable route to take. But I understand why MS would like it.

cgminer already is "the miner to run" its far superior to most any other miner out there and for many good reasons

You can do it. Follow these instructions and you can be compiling in under 30 minutes.

http://pastebin.com/3pzivj32

can anyone compile the latest cgminer from git for windows for me?

thanks!

I didn't do emails or anything.  The script just quietly fixes the problem by restarting everything.  I may add a pause followed by a re-check of the statuses to which I might resort to a full scale automated reboot of the rig if the miner restart didn't fix the issue.  I don't really want to just be notified that something is wrong and have to manually fix it.  I want the script to fix the problem itself.

The first version I had out there was just bad...this is much cleaner.

One of these days I might look into email, but I really don't think that I'll need it. Glad someone benefited from the script.

Thanks for the help.  The 'nc' command was the trick I needed and wasn't familiar with.  I already have a script (init.sh) that kills all running miners and starts new ones in background screen sessions, so I just needed a way to detect that it was necessary.  This is pretty simple script I ended up with (I run it every 15 minutes via cron):

OK, as I just said to you in IRC - yep I give in, I failed - I'm not gonna do it

As you said, ZTEX requires USB direct control - it won't work via serial - so yeah there's no way I could write that in a day without the hardware
(If I had the hardware ... well yeah that wouldn't be an issue)

I've little experience with USB directly (and no idea why it wont work via serial like Bitforce and Icarus) but if that's the case, yep I certainly can't get the USB interface to it right without the hardware to try stuff

Oh and what I was thinking about the Frequency was to do it a little different:
Basically have a cgminer option to set the start frequency (comma list for ZTEX devices),
and use a simple lookup table based on the hardware (for unspecified on the command line) with a low value for unknown,
and step it up N (1 or 2?) every successful nonce then as soon as it gets a hardware error start stepping it down one every time you get a HW error (that would always be the case from then on, never go back up)
It would take a while to get to optimal frequency if it started too low but since that will vary from board to board, you would be setting cgminer to start close to the optimal ferquency for each board once you see what it is after an extended run
Then also add a new API option to set it to a new value (and report the current value) ... since you may want to be able to push it back up rather than restarting cgminer if conditions change (e.g. a hot day vs a cool night)
Thinking about pushing it back up automatically - I don't think that's a good idea since I'd expect in the long term that would be bad for the life of the FPGA - i.e. better to let it settle a couple of Hz below than always going up and down near HW failure (and also losing work due to every time you get a HW failure)

Forgive me, I just updated the scripts, the one to modify is the cgm-dev-parse.  The new corresponding number is line 45.  I think you can just modify that to you liking.  I'm sorry I don't already have a device restart function.

Outstanding.  Thank you.