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

That's bad. Earlier this was a problem limited to Windows (because of some lib IIRC), right? So there is no other workaround?

EDIT: Oh and one core? Two cores are in use here. (I see, two threads...)

High CPU usage has been plaguing recent driver versions, to the point of increasing CPU usage on linux to match that of the windows driver. On Linux at least, downgrading to the 11.6 driver makes a massive difference to the CPU usage. Some new code in the driver that does busy-waiting to improve throughput on the GPU also causes 100% (of one core) load. It's been annoying the hell out of me and someone else on this forum found the small sacrifice in GPU throughput by downgrading his driver was well worth the massive drop in CPU usage.

Still get around 141mhash/s

I did the opposite test and put in the new kernel into the old version and I get about 143 mhash/s but I get hardware errors (well, that should have been expected, you obviously changed stuff)

Hmm, I just noticed the miner (at least .6 and .7) have a lot of CPU usage (looks like it maxes it out for both cores) on Windows 7. I remember it has been around 10-20% in earlier versions. I am not sure whether it is related to a driver upgrade. There is a difference between GPU0 and ALL hashrates. It looks like it would use my CPU. I tried adding -t0, but it doesn't help.

Copy the old phatk110816.cl file from 1.5.6 into your 1.5.7 directory and rename it phatk110817.cl (overwriting the new one). Then delete any .bin files created and start again. See if that restores the speed. The kernel may behave differently depending on which core it is.

1.5.7 is just 3mhash/s slower on my 5750 down from 144 or so to 141

I know what you mean. But I did not change anything beside starting 1.5.6 or 1.5.7 from a clean folder.
There was no crash, black screen or anything.
If I start 1.5.5 after, before or after restart, it still gives me the normal 410 MHash.

One thing to add.. the reason is, the GPU usage for the first GPU jumps around from 50% to 95% back to 40%. I assume that may cause the low speeds.

Talk to you in IRC..

If it's the first GPU, could be coincidence involving a change to your setup, like having the monitor connected, or the screensaver being enabled that wasn't just a blank screen, or... power supply now failing or... some other random who knows what. Does 1.5.5 still give you the higher rate?

I don't know what the reason is but after getting 1.5.6 and 1.5.7 successfully to start (after a few start-stop-start-stop because of zero binaries..) the hash speed for my first GPU (Cayman HD6970) is pretty low.
288MHash/sec compared to 410 Mhash/sec at 1.5.5.

Both Cypress GPUs 2 and 3 run fine. I tested with different Intensity settings but no way to reach 410 again.
I assume, there are still issues with the OpenCL compiler. (11.6, 11.7, 11.8 all the same issue, Win7 64bit)

Version 1.5.7 - (links in 1st post as usual)

- Fix a crash with --algo auto
- Test at appropriate target difficulty now.
- Add per-device statics log output with --per-device-stats
- Fix breakage that occurs when 1 or 4 vectors are chosen on new phatk.
- Make rolltime report debug level only now since we check it every work
item.
- Add the ability to enable/disable per-device stats on the fly and match
logging on/off.
- Explicitly tell the compiler to retain the program to minimise the chance of
the zero sized binary errors.
- Add one more instruction to avoid one branch point in the common path in the
cl return code. Although this adds more ALUs overall and more branch points, the
common path code has the same number of ALUs and one less jmp, jmps being more
expensive.
- Explicitly link in ws2_32 on the windows build and update README file on how
to compile successfully on windows.
- Release cl resources should the gpu mining thread abort.
- Attempt to restart a GPU once every minute while it's sick.
- Don't kill off the reinit thread if it fails to init a GPU but returns safely.
- Only declare a GPU dead if there's been no sign of activity from the reinit
thread for 10 mins.
- Never automatically disable any pools but just specify them as idle if they're
unresponsive at startup.
- Use any longpoll available, and don't disable it if switching to a server that
doesn't have it. This allows you to mine solo, yet use the longpoll from a pool
even if the pool is the backup server.
- Display which longpoll failed and don't free the ram for lp_url since it
belongs to the pool hdr path.
- Make the tcp setsockopts unique to linux in the hope it allows freebsd et. al
to compile.

Hi everyone,

First of all, thanks a lot to ckolivas for creating such a program.

I have a question/suggestion. I'm trying to make a Gentoo ebuild for cgminer and have run into a problem.
cgminer seems to look for OpenCL kernels in the current directory and from the first glance at it, it looks
like it's hardcoded that way. I think that it would be more correct to store them in /var/lib/cgminer directory
along with the dynamically-generated binary. Is it possible to add an option to specify kernel file locations manually?

Any ideas on how to better implement this? It can, of course, be done by adding a trivial patch to the ebuild, but
would it hurt to add such an option? I'm in no way an expert at programming but I hope I did make some sense.

Thanks,

P.S. ATM i'm doing a cd /var/lib/cgminer in my init.d script and then exec the binary and it works.

No worries. I seem to be the only one that wants to be able to use a separate login for each GPU anyway. The author does not seem to give a shit, nor do users of cgminer. So I have given up on cgminer and moved on.

Obviously for Windows users that do not want to toggle between multiple windows running at 1024 x 768 this is not for you if; you want to be able to see on your pool's website which computer/GPU is having issues. Stick with Guiminer or whatever you were using.

Sharky,
Please don't throw tantrums.  It's unbecoming of any member and is a lot less likely to get ANYONE to work with you regardless of how good an idea may be.  As I said, while it would be easy to modify the command options to accept such a command, modifying the cgminer software itself to submit results on a per-username basis would take a lot longer.  Honestly, with the most recent Windows ATI driver (11.8 at the time of writing), the efficiency won't drop as much as most people think because it doesn't use as much CPU/memory as the previous driver versions.  Most people haven't realized this yet as they probably haven't downloaded the most recent driver.  Now, you will have some more memory usage due to the extra threads of running 3 other instances of cgminer; but that can't be helped until some pretty big modifications to the cgminer code could be completed.
So please try to understand that it's not as easy as just typing in a few words and being done with it.  Okay?

Not yet. The only way currently is to specify multiple config files, each with different pool settings (i.e.: -c 1.cfg -c 2.cfg )

It will generate local work from a failed pool for up to 5 minutes after a pool has gone down. If in that time the pool still hasn't come back up, only then will it switch.

Is it possible to define multiple pools using a JSON config file? I tried just duplicating the url/user/pass, but it seems to ignore all but the last entry.

I'm sure this has been answered already, but I searched and was unable to find any info on this.

Is there a reason cgminer 1.5.6 won't fail over to a backup pool? When my primary pool goes down, cgminer sits there and says the pool is not responding repeatedly. I have to manually switch to the second pool and then it will start mining away.

I have it setup on failover mode and when I check the pool screen it says both pools are alive.

Why should the cgminer developer put in a massive effort of time and work to make a fundamental change to the code of cgminer just to make it look-like/work-as guiminer when they both are based on different idea on how their program should work? 
Why not just ask for a web-browser and a media player to be added as well? 
I for one would like it to have a native hypervisor with 0% loss of performance when doing millions of I/O per second, but that doesn't mean I would ask for it. 

What you are looking for is a "simple" wrapper. (I think)
If you want it really easy, take a look at BAMT https://bitcointalksearch.org/topic/bamt-easy-persistent-usb-key-based-linux-for-dedicated-minersmining-farms-28967. (sorry for pointing to other projects in this thread)

Below are my 5870s which have been running for hours at 975/300. I'm sure that they are stable at this clock (had been running without a hitch for weeks using phoenix before switch to cgminer).

Well it will take some time to add the code so by all means it should not be done. BS logic IMO.

I am not going to donate for software I deem unusable to me at this time. When it will replace Guiminer for me (Everything on one screen and ability to use a separate login per GPU) then I will start using it and certainly donate.

It is only a moot point to you because you probably would not use the feature, but do not seem to give a crap that other people will.

Yes the windows can all be re-sized but try doing that at 1024x768 with 4 windows. You will not be able to see all the windows contents without moving them.