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

Is it exiting or crashing?

Sadly this is not the case.

windows machine, pair of 6950's, set to 850/1300 for normal operation, in cgminer they are set to 700-880/300... when cgminer exits it leaves the cards at 880/300.

even updated to 12.1 drivers, both 2.4 and 2.6 SDK.

Hmm don't expect that to last forever ...

I second a thread just for cgminer settings and what cards are being used.

I use I,9 and then just set memclock, fan and engine in my bash script for linuxcoin.

I'm still struggling to get my 5970's stable.

fan 100 engine 820 and me 410 seem best for me, but of course for wattage, I'd love a lower memclock.

Should I be using I 8, is that my issue? also i am on cgminer 2.0.7 because there is no way in hell i can do anything in linuxcoin without screwing it up and hate the full ubuntu OS, too difficult to work with IMO.

We need a new stripped down version of linuxcoin or call it whatever, just for mining and maybe built around optimal settings/set-up for cgminer. Seems BAMT doesn't supoort or work with cgminer.

My farm is up to 8 rigs 10 5970's, 8 5870's and 1 6990. I plan on building a water-cooled 4x5970 with 1500 watt psu. I have the stuff, but want to make sure I can get it set up as fast and stable as possible as it will be in a semi-remote location.

I know I need to figure out how to use ssh, etc. but I'd also like to have the best sdk, drivers, etc. along with some other folks settings for engine and memclock.

Can we start a cgminer optimization thread with some guides? I'll throw in a bounty of 10btc if it has a set up guide and an optimal settings database.

Okay so I tested the fastest diablominer has to offer on 7970 and current cgminer is 1.5 MHash faster with defaults, so I'm pleased . I guess I should keep working on my kernel

Yes I like that idea. But 8 and 16 vectors perform shithouse followed by appalling so it's not worth pursuing those.

Or

--sched-stop `date -d "+6 hours" +%H:%M`

... since shares are random

And 6 hours for a 1GH/s is approximately 5029 shares

Suggestion: Would it be possible to maintain on the first page of this tread a list of all the AMD graphics cards with the optimum settings for cgminer?

It's kind of cumbersome to keep reading through all those pages (202) at the moment - so it would be nice to have this information in one central place.

Con, maybe we can talk about integrating global offset parameter support into CGMINER?

Take a short look at http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clEnqueueNDRangeKernel.html and the global_work_offset parameter. All that has to be taken into consideration from the kernel-side is in DiaKGCN. OpenCL 1.1 detection is in your code, too, which is needed, but I can't do the other required changes without a compiler.

In short, the nonce-base is not supplied via the base parameter, if GOFFSET is enabled, but instead via the global_work_offset parameter and used via the global work-item ID in the kernel. This saves a few instructions and can give us a small boost.

Dia

Yeah. You can say that again.

I would have done it but sadly my router died on me and I am still trying to fix it ...

IMHO one needs to test just 2.1 against 2.4 and ranges from below 300 for memory and above 900 for core.

I would love to see an expanded version of this that goes down to 100 (or lower) memclock using latest version of cgminer, latest drivers, and SDK 2.1.

Anyone have any ideas how to automate a loop of cgminer.
I would imagine the easiest would be something like.

setup config file w/ shares: "5000", static memclock, static coreclock, worksize defined, vectors defined.

script
a) modifies config file to next parameter set to be tested (i.e. V2, W256, memclock = 180)
b) starts cgminer
c) cgminer stops after 5000 shares (and script detects it)
d) capture and save final avg hashrate, rejects, errors, etc.
e) goto a

I would be happy to run something like this on one of my rigs.   Once we get the complete result set for one core clock we could run it at another core speed.  Between 5870s & 5970s I figure coreclocks of 725 (5970 stock), 800, 825 (5870 stock), 850, 875, 900, 925, 950, 1000 (watercooled ) would be useful.

Doing it manually would be a nightmare but if someone can make some semi-automated tool I would be happy to leave it running on one of my rigs.  Once we get data for SDK 2.1 we could compare it to SDK 2.4, 2.5, 2.6.  It is possible that some parameters do better on different versions of SDK (as an example maybe SDK 2.1 is best w/ high work, low vectors, low memclock but SDK 2.5 is better at smaller  work, high vectors, "normalish" memclock, etc).

I still have some problems with that Git-stuff, but it's such a great tool, wow ... it would be nice to default diakgcn to -v 2 and it seems -w 256 is better for me by ~0,5 MH/s but I can live with the default being 128 ^^.

There is something unusual about it running diakgcn and the hashrate appears to be more unstable, rising and falling more so it takes a while to get a reasonable grasp for what the hashrate really is. Since you're running 2 vectors, it effectively makes the hashrate update half as often as running my poclbm kernel since I use no vectors. Either way, the hashrates are really close.

Sounds not too bad . I will try -w 128 and compare results on my machine ... will report back, which one is faster for me at default clocks and on Win7 x64. I'm happy now!

Dia

Indeed it is faster now, and with -v 2, it is fastest allow cgminer to choose worksize which is ends up being 128 - it queries the "preferred worksize" and divides that by number of vectors.

You are but 1 Mhash off my current poclbm kernel with that Diakgcn 716.5 versus ck-poclbm 717.5

Yes, please do, and if things go well, we can have a new default kernel for GCN

That's true for the most part when reordering kernel-arguments to be in line with usage of them in the code, but I think it's part of a clean code, don't you think so?

So you created a new DiaKGCN branch, will this last so I can switch my local repo to that one ?

Dia

Did you use the code from the latest commits, here on Windows it's definitely faster with -v 2.

-I 9 -k diakgcn -d 0 -v 1 -w 256: ~524 MH/s
-I 9 -k diakgcn -d 0 -v 2 -w 256: ~539 MH/s

Dia

And thank you for the code. Now what advantage is there to reordering the variables passed to the kernel? In commit d86a38d1e75090e1ffb9df9e68aa13b1c8dcf9ec you shuffled arguments which appear to be mostly cosmetic. Would that be right?

Tried it, much slower.