OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Diapolo]

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

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!

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.

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 ^^.

[1714835964]

1714835964

[1714835964]

1714835964

[DeathAndTaxes]

Gonna link again the graphic I like so much (from phatk thread)

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).

[bulanula]

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 results for one core clock we could run it at another 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 version 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).

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.

[Diapolo]

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

[Frizz23]

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.

[kano]

c) cgminer stops after 5000 shares (and script detects it)

Or

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

... since shares are random

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

[-ck]

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.

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

[-ck]

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

[jjshabadoo]

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.

[kano]

...
fan 100 ...
...

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

[dlasher]

cgminer sets clocks all back to default on exit... if it exits cleanly, and of course on windows it's a miracle when it does.

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.

[DeathAndTaxes]

cgminer sets clocks all back to default on exit... if it exits cleanly, and of course on windows it's a miracle when it does.

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.

Is it exiting or crashing?

[-ck]

cgminer sets clocks all back to default on exit... if it exits cleanly, and of course on windows it's a miracle when it does.

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.

Instead windows decides to blow your balls off and feed them back to you by collecting up the splatter, mincing it, putting it into a glass and forcing you to drink it through a straw via  your left nostril.

[gnar1ta$]

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

What am I missing here, cuz my 5970 BAMT rig has been mining with cgminer for a week now - and it took 3 mins to set up 

[jjshabadoo]

Oh well, i guess i was wrong, i read that BAMT didn't work with cgminer, maybe they just mean it's not part of the original download which is fine. it didn't make sense to em either, but i fiugured it had something to do with some of the programming.

So i guess you just download BAMT and then download cgminer and you're all set?

what drivers and sdk does BAMT use?

[DeathAndTaxes]

Oh well, i guess i was wrong, i read that BAMT didn't work with cgminer, maybe they just mean it's not part of the original download which is fine. it didn't make sense to em either, but i fiugured it had something to do with some of the programming.

So i guess you just download BAMT and then download cgminer and you're all set?

what drivers and sdk does BAMT use?

BAMT already has cgminer installed and it is integrated into BAMT other tools (mgpumon, web monitor, gpumon, etc).

It is only cgminer 2.1.2 I believe but you can install newer copy if you like.  SDK is 2.4, I am not sure the driver.  It doesn't have 100% bug.

So it is write BAMT to flash drive.  Run fixer to grab latest updates, change 2 config files (1 for BAMT, 1 for cgminer) and you are mining.  You can then take that flash drive, record the image, put that image on 8 flash drives, put them in 8 rigs make a few changes via SSH and power up 20 GH/s farm in a few minutes.

[-ck]

cgminer sets clocks all back to default on exit... if it exits cleanly, and of course on windows it's a miracle when it does.

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.

Instead windows decides to blow your balls off and feed them back to you by collecting up the splatter, mincing it, putting it into a glass and forcing you to drink it through a straw via  your left nostril.

I'll try and code a workaround for this windows fail next time by stopping mining and resetting device values and pausing for a bit before letting windows crash cgminer when it tries to exit.

[-ck]

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

I tried writing code to send nonce as the global offset parameter and your code returned duplicate work on 2 or more vectors. Looking at your code:

Code:

u nonce = ((uint)get_global_id(0) << 1) + (u)(0, 1);

This won't be right as global id will now be the global thread id + the global offset parameter so doubling it will give random results.

[blandead]

Nonce of that code makes much sense, but I think Dia is suggesting that he wants to use the natively built-in global_work_offset parameter instead of the one you reference by using clEnqueueNDRangeKernel

[-ck]

Nonce of that code makes much sense, but I think Dia is suggesting that he wants to use the natively built-in global_work_offset parameter instead of the one you reference by using clEnqueueNDRangeKernel

Umm... I actually do understand the code  I was explaining what was wrong with it.