have you find something why cgminer stats go away after a longer term? (on y rigs on windows 64bit after 10-10.5 days cgminer don't show temp and fan speed, after quit and restart (only cgminer) all is okay)

I just compiled the new cgminer direct from git using git clone and the steps recommended (./autogen.sh then CFLAGS="-O3 -Wall -march=native" ./configure)I'm getting an incomprehensible bunch of data after a few minutes of mining (cgminer with -w 256 and --submit-stale shuts down and gives me this info):

have you find something why cgminer stats go away after a longer term? (on y rigs on windows 64bit after 10-10.5 days cgminer don't show temp and fan speed, after quit and restart (only cgminer) all is okay)

They will tell you it is because you are remote controlling your computer. As in you are controlling your PC form another PC (VNC, Logmein, etc...)

Cgminer only reports what the ATI display library shows and does not show anything if it's not reporting results from a device. At the mercy of the ATI display library. If it stops reporting values there's nothing cgminer can do about it.

Hmm... could be a race on the work item. Can you "git checkout a3e77937c8b8d924b2671aa4a77e9f13689ac64a", rebuild, and see if it goes away?

Running more than twice as long as before and no crash yet. I'll post again, should this post trigger another crash, but so far it looks good.

@kano: The first thing I did before posting was "ulimit -c unlimited; make clean; ./autogen.sh && ..." just to get a clean core dump.

Yep - sorry - but I thought I better mention the obvious just in case ... and mine hadn't yet crashed either - but the 725 comment also meant that was possibly the reason mine hadn't crashed.My guess is your hash rate is a lot higher than mine? Or you were unlucky

Edit: yeah I'm running 2.2.3 now also

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

@kano: The first thing I did before posting was "ulimit -c unlimited; make clean; ./autogen.sh && ..." just to get a clean core dump.

Yep - sorry - but I thought I better mention the obvious just in case ... and mine hadn't yet crashed either - but the 725 comment also meant that was possibly the reason mine hadn't crashed.My guess is your hash rate is a lot higher than mine? Or you were unlucky

The way my luck has been going in the last 25 years... BTW, I only have ~55 MH/s. And I got the first instance of the crash on a pure-CPU machine where I was trying the new version out. That thing barely has 1.5 MH/s...

Note this version has extra goodness for mining on p2pool, though other pools will of course benefit too.

Human readable summary of possibly user visible changes:

- New opencl kernels to work half decently on GCN hardware 79xx and to make phatk2 work on them, NVIDIA devices and much older ATI GPUs.

- OpenCL Platform information is now available when cgminer is called with --ndevs, including what devices are available on each platform. cgminer also now supports the --gpu-platform command line option which allows you to choose what platform to use, should you have multiple installed (eg both NVIDIA and ATI, or mutliple SDKs from ATI). Note you MUST delete any *.bin files generated before starting for new binaries to be generated using the chosen platform.

- Some pools support an extension called "submitold" which recommends you actually submit stales. Instead of universally throwing them out (default cgminer behaviour) or submitting all of them (when you enable --submit-stale), this allows the pool to tell cgminer what it wants you to do. On pools that your stale count doesn't matter (like p2pool) there is a theoretically miniscule chance this share is worth submitting, and on merged mining pools, it might be okay to submit shares from a valid BTC block but not a valid NMC block. You can actually see this in action in this latest version with output that looks like this:

As you can see, it was still rejected by p2pool here, but that is harmless.

- More work is "rolled" on longpoll. This should minimise the dip in hashrate across longpolls, and decrease the "pool is not providing work fast enough" warnings on pools that support n-rolltime. It will also increase the dreaded "efficiency" rating.

- GPU threads on the same GPU now start work staggered, with the first thread on each GPU having no delay. This means all GPUs should be busy ahead of extra threads on a GPU that is already busy. This should further decrease the dips across block changes/longpolls/network delays.

- Hopefully the "linked GPU" (eg 5970) scenario where a GPU would be apparently randomly turned off is fixed.

- When a GPU hangs now, the fan control should still keep trying to keep it at target temperature if it's hung running flat out. This should decrease crashes.

- The --donation feature is GONE.

- The wrong "thread" will not be reported if a GPU is disabled.

- Some networks can take extraordinarily long for the pool detection to work so the 15 second timeout has been increased to 60 seconds. This will help those who have had apparently everything set up fine but ended up with pool communication failure at startup.

- Enabling the -T text only option will guarantee that the formatted "curses" output will never occur. This makes debugging easier.

- Bitforce devices should actually work now.

- More information available (last share) in the changed RPC API.

---Changelog:

2.2.3:- Revert "Rewrite the convoluted get_work() function to be much simpler and rollwork as much as possible with each new work item." This seems to cause a race onwork in free_work(). Presumably other threads are still accessing the structure.

2.2.2:- Provide support for the submitold extension on a per-pool basis based on thevalue being detected in a longpoll.- Don't send a ping to a dynamic device if it's not enabled as that will justenable it for one pass and then disable it again.- Rewrite the convoluted get_work() function to be much simpler and roll work asmuch as possible with each new work item.- Roll as much work as possible from the work returned from a longpoll.- Rolling work on each loop through the mining thread serves no purpose.- Allow to stage more than necessary work items if we're just rolling work.- Replace divide_work with reuse_work function used twice.- Give rolled work a new ID to make sure there is no confusion in the hashtablelookups.- Remove now-defunct hash_div variables.- Remove unused get_dondata function.- Silence ADL warnings.- Silence unused parameter warnings.- Stagger the restart of every next thread per device to keep devices busy aheadof accessory threads per device.- Deprecate the --donation feature. Needlessly complex, questionable usefulness,depends on author's server and a central pool of some kind, and was not heavilyadopted.- It's devices that report back now, not threads, update message.- Continue auto-management of fan and engine speeds even if a device is disabledfor safety reasons.- No need to check we're highest performance level when throttling GPU enginespeed.- Abstract out tests for whether work has come from a block that has been seenbefore and whether a string is from a previously seen block.- Probe but don't set the timeout to 15 seconds as some networks take a longtime to timeout.- Remove most compiler warnings from api.c- Add last share's pool info in cgpu_info- Allow the OpenCL platform ID to be chosen with --gpu-platform.- Iterate over all platforms displaying their information and number of deviceswhen --ndevs is called.- Deprecate main.c- Some networks can take a long time to resolve so go back to 60 second timeoutsinstead of 15.- Only enable curses on failure if curses is desired.- Fix warnings in bitforce.c- Bugfix: Need to open BitForce tty for read-write- Fix various build issues.- Modularize code: main.c -> device-cpu + device-gpu- Fix phatk kernel not working on non-bitalign capable devices (Nvidia, olderATI).- Update poclbm kernel for better performance on GCN and new SDKs with bitalignsupport when not BFI INT patching. Update phatk kernel to work properly for nonBFI INT patched kernels, providing support for phatk to run on GCN and non-ATIcards.- Return last accepted share pool/time for devices- Display accepted share pool/time for CPUs- Bug intensity always shows GPU 0- Update example web miner.php to use new API commands

Anyone who used the old one this one should be interesting to look at once or twice (I of course use it to view the status of my rig since it's all in one page)Of course there are other more complex ones out there for pure display onlyThis one also happens to allow you to change everything that the API allows (unless I missed something )

Kano code is just an "example" (Kano wrote the RPC code for cgminer BTW). Other people have written multi-rig management/reporting tools which use the RPC functionality in cgminer. There are two web based tools and BAMT uses RPC for both web based tools and console tools.

This is the multi-rig monitoring view in BAMT. Also the nice thing about the RPC code (I organized the bounty project BTW) is that if existing solutions don't do what you want it to do, you (or someone else) can also write another one. Since the RPC API is a standardized set of queries it doesn't require modifying the cgminer to implement new "front ends".

Off topic: 192.168.0.183's GPU #0 must have bad VRM. . It will thermally cut out for a second or so every 20 or 30 seconds. The core is not running too hot so it makes me think it is the VRMs. Since mpgumon only gets updates once every 30 seconds or so it will either show 99% or 0% depending on timing. I have dropped that GPU back to stock but it keeps "cycling" on & off. I think it is degraded.

So after 9 months on mining with 30 GPU (15x 15970s) I have two "degraded" GPUs. GPU #0 on .183 rig and GPU #5 on the .184 rig (which will crash about once a day - hard hang even on stock w/ low temps). I also have "lost" 2 fans. Be interesting to see what my "attrition" will be at the one year mark.