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

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.

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

An example would be line 60, however all it does is pop up a non modal window.  You can modify it to email you with

echo "$node gpu$i reports $STATUS" | mail -s "Device Failure" [email protected]

or whatever else you want.

Has anyone written a script that checks if any GPUs are DEAD/OFF via the API?  I'd like to create something that checks periodically and restarts cgminer if that happens (since a restart usually fixes the issue).  If someone already has a simple script to talk to cgminer, I'd love to use it as a starting point.

That is weird.  Makes me think something larger is going on with your system.  AMD drivers can be weird sometimes but I don't think any GPU should show "disabled" while under load.

You may want to read my code instead, as python is much more readable than java and you have everything I needed on mpbm in one single source.

https://github.com/nelisky/Modular-Python-Bitcoin-Miner/blob/ztex/worker/fpgamining/ztexdev.py

I will try to find you on irc once I get some work things out of the way.

I took that to mean that the MH/s gets slower on the GPU with 'd' but you could be right.  Regardless, the advice from DAT after your last post (and just before this post) is exactly what Windows miners need.  (and there's still no thumbs up emoticon)

The #0 GPU is rarely the one driving the display.  It is up to windows crazy device number scheme.  Only only Windows rig (3x watercooled 5970s) the "display GPU" was #4.  When one 5970s died and I RMAed it (4 GPUs installed) he "display GPU" become #1.  When I got the RMA back (6 GPUs) the "display GPU" after a reinstall become #2.  So it varied and it was never #0 in this limited sample set.

So windows users should identify the display GPU.  If you have multiple physical displays as long as they are all connected to a single card one GPU will handle them all even on dual GPU cards like 5970s.  If you have multiple displays connected to multiple cards well change that it is sub optimal.

To identify the display GPU:
1) stop mining
2) open GPU-Z sensor tab (be sure record data when not shown is checked), AB, or CCC.
3) All GPU should be ~0% GPU load.
4) Do something which requires the GPU acceleration flash accelerated video, (although you should turn it back off when mining), Afterburner test tool, play some 3D game (in windowed mode would be best).
5) Look which GPU load increases.  Record this GPU number.

Now you think you might be done but you aren't (because windows & ADL library used by cgminer order cards differently sometimes).
Leave whatever tool you are using open.
5) Start cgminer  (you can use low intensity and stock clocks for stability)
6) You should see all GPU go to 99% load
7) Disable each GPU one at a time until you find the one which causes load on the GPU identified in #4 (in GPU-Z / AB) to go to zero.
Wait a few seconds between each GPU disable as sometimes it take a couple seconds for the tools to show a drop in GPU load.

That is the GPU in cgminer that is driving the display.  Yes windows is asinine.  You likely want to write it down.

On edit: clarified a few steps.

Actually he said:
Which sounds like it could be the wrong GPU is 'd'
i.e. as you increase the intensity on the display GPU it should of course get less responsive