Author

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

hero member
Activity: 518
Merit: 500
Quote from: TheHarbinger
950/180  Do the math.

It doesnt work out to a nice round number. But I just tried.
5870 @ 950/300 : 432.4
5870 @ 950/180 : ~441-442
5870 @ 950/170 : ~442

Not a quantum leap, but still quite a nice boost!

So I tried another 5870 that runs at 1 GHz applying the same memory clock and same ratio and a few other speeds:

5870 @1000/300: 454.7
5870 @1000/200: ~459
5870 @1000/190: ~460
5870 @1000/180: ~460
5870 @1000/150: ~454

Smaller boost than at 950. Not too sure what to make of it, but there is nothing wrong with getting a few extra MH while consuming less power Smiley

Note these results were obtained testing just a few minutes on each setting, dont take it as gospel


Have to try this tweak and 2.2.4 version. Can memory go lower than 150 MHz ?

Thanks !
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Firstly, I guess bravetheheat's on windows ...

List of known fixes for such and other similar problems (repeated here many times)
(Problem being that cgminer wont start coz it wont generate the *.bin files)

1) Read the README
or
2) just restart it over and over until it succeeds to generate the new *.bin
or
3) make sure you extracted all the files (including the new *.cl files)
or
4) Last resort: just rename the old *.bin files to the new names: replace 110817 with 120203 in the names

And the other repeated again and again info often needed with problems:
the full output of 'cgminer -n' and some of 'cgminer -D -T --verbose ...' (obviously not all of it if cgminer is actually running ...)
where '...' are the options you use

And when you post the output of "-D -T --verbose" put it in [code]blah blah blah[/code] - which gives:
Code:
blah blah blah

Edit: tidied up the post ...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
... but it will accept -k diakgcn provided it is loading the kernel called diakgcn120208.cl . This will allow you to at least play with the .cl file and see if you can figure out what's wrong with it perhaps.

It accepts, but don't submits shares to pool Sad Shows a hashrate and GPU is hot (works) but there's no info about accepted shares (as usual) and pool website also confirms that there's no worker that is mining.
THIS IS NOT FOR USAGE ! THIS IS FOR DEBUGGING PURPOSES BY DIAPOLO ONLY. IT DOES NOT PRODUCE SHARES.
legendary
Activity: 1029
Merit: 1000
... but it will accept -k diakgcn provided it is loading the kernel called diakgcn120208.cl . This will allow you to at least play with the .cl file and see if you can figure out what's wrong with it perhaps.

It accepts, but don't submits shares to pool Sad Shows a hashrate and GPU is hot (works) but there's no info about accepted shares (as usual) and pool website also confirms that there's no worker that is mining.
sr. member
Activity: 457
Merit: 251
The new cgminer 2.2.4 doesn't seem to work with my discrete GPU + integrated GPU (though not used for mining) setup. It keeps giving me:
Code:
[2012-02-11 21:35:02] Error: Building Program (clBuildProgram)
[2012-02-11 21:35:02] Failed to init GPU thread 0, disabling device 0
[2012-02-11 21:35:02] Restarting the GPU from the menu will not fix this.
[2012-02-11 21:35:02] Try restarting cgminer.
Press enter to continue:

hero member
Activity: 807
Merit: 500
No problem. cgminer assumes we're operating at the highest profile, and adjusts all the profiles below to make sure the highest profile remains valid.
Good to know.  And while I'm not a programmer and I honestly don't care whether or not you change this, I believe it would make more sense from a "best practices" standpoint to only change the highest profile.  I mean, if cgminer crashes or the code to change the profiles back to defaults fails, the GPU is left running harder and hotter than it needs to be when it automatically goes back down to the lowest profile.  OTOH, some might disagree with me, being more concerned that their card might not switch to the highest profile or preferring the card not slow down if no work is available (based on the theory that the GPU and/or fan last longer when run at a constant rate).  Also, thanks for the quick response, I figured this might be something someone else could answer, but not something too many people could, so I wasn't sure I'd get an answer (much less a nearly instant one on a Saturday morning).
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Well ... as I said, I have no IDE setup, so currently I can't compile a version for myself. If you don't have the time to fiddle around with my commits, then I really need help in setting up an IDE in Windows. Have you got this in a readme, wiki or can you give me a brief explanation in how to do this? I worked with MS VC++ Express as a hobby some time ago ...
Dia. Grab the windows binary for 2.2.4. It is undocumented, but it will accept -k diakgcn provided it is loading the kernel called diakgcn120208.cl . This will allow you to at least play with the .cl file and see if you can figure out what's wrong with it perhaps.

NORMAL USERS DO NOT USE THIS. IT IS FOR DEVELOPMENT AND DEBUGGING. IT DOES NOT PRODUCE SHARES.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
- Remove the test for whether the device is on the highest profil level before
raising the GPU speed as it is ineffectual and may prevent raising the GPU
speed.
Does cgminer only change the highest profile level's settings?  If not, I'm concerned that this could lead to GPU crashes.  In my experience, if I accidentally forget to specify the highest profile when OCing manually, I get a GPU crash because the lower profiles have lower voltages and I am not changing the voltages.  I assume this is normal behavior when not changing the voltages.  If I am correct then cgminer changing the clock settings of the lower profiles and not changing voltages (because it's not being told to) would likely cause GPU crashes (while changing only the highest one even if it isn't currently being used wouldn't)...
No problem. cgminer assumes we're operating at the highest profile, and adjusts all the profiles below to make sure the highest profile remains valid.
hero member
Activity: 807
Merit: 500
- Remove the test for whether the device is on the highest profil level before
raising the GPU speed as it is ineffectual and may prevent raising the GPU
speed.
Does cgminer only change the highest profile level's settings?  If not, I'm concerned that this could lead to GPU crashes.  In my experience, if I accidentally forget to specify the highest profile when OCing manually, I get a GPU crash because the lower profiles have lower voltages and I am not changing the voltages.  I assume this is normal behavior when not changing the voltages.  If I am correct then cgminer changing the clock settings of the lower profiles and not changing voltages (because it's not being told to) would likely cause GPU crashes (while changing only the highest one even if it isn't currently being used wouldn't)...
full member
Activity: 210
Merit: 100
Thanks for the reply Kano,

I am using version 2.0.8, I should update my stuff.  Tongue

Cheers!
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Hello,

I want to start using the donate feature in CGminer and was just wondering: Does it take the donation as I mine or after I find a block while solo mining?

Thanks in advance for your reply, cheers!
The cgminer --donation option was removed a few versions ago.
Donate to ckolivas directly: 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
(that's in his sig)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 2.2.4


Human readable changelog of user visible changes:
- Faster performance on ATI GCN (79xx), ATI 4x cards and Nvidia.
- Less failures to build kernels at startup.
- Faster startup - cgminer now finds just one pool that's responding before starting mining and allows the others in a multipool setup to be detected later.
- Pool connection issues may have been causing inappropriate clocking of GPU engine clock speeds and fans and disabling GPUs. The pool detection code has been moved to its own thread to not disturb GPU management.
- Accumulated work was expiring at precisely the same moment leading to false pool-slow-to-respond warnings. cgminer now buffers even more work at intervals spaced out by the number of mining threads. This should make hashrate more stable as well.
- Shutdown code was made more robust so there should be less crashes on exiting.
- The windows binary was built with a newer pthread library (dll included in zip) which should also lead to more stable code.
- --failover-only is now much more aggressive at avoiding working on work that is not from the primary pool we're connected to.
- New option: --api-allow   Allow API access only to the given list of IP[/Prefix] addresses[/subnets]
- Support for x-reject reason. When a pool supports it you should get a response like this on rejects:
Code:
[2012-02-11 22:11:43] Rejected 00000000.a7b317fa.c16767ef GPU 0 thread 0 pool 1 (Stale or unknown work)
- Combinations of hardware that use different kernels (eg 7970 and 6970) should now work properly.
- Rarely GPUs would throttle to their lowest setting and not rise back even if they were below their target temperature. This should be fixed.


Full changelog:
- Retain cl program after successfully loading a binary image. May decrease
failures to build kernels at startup.
- Variable unused after this so remove setting it.
- BFI INT patching is not necessarily true on binary loading of files and not
true on ATI SDK2.6+. Report bitalign instead.
- Various string fixes for reject reason.
- Generalize --temp-cutoff and implement support for reading temperature from
BitFORCE FPGAs
- Change message from recovered to alive since it is used on startup as well as
when a pool has recovered.
- Start mining as soon as any pool is found active and rely on the watchpool
thread to bring up other pools.
- Delayed responses from testing pools that are down can hold up the watchdog
thread from getting to its device testing code, leading to false detection of
the GPU not checking in, and can substantially delay auto gpu/auto fan
management leading to overheating. Move pool watching to its own thread.
- Bugfix: BitFORCE index needs to be static to count correctly
- Space out retrieval of extra work according to the number of mining threads.
- Make shutdown more robust. Enable the input thread only after the other
threads exist. Don't kill off the workio thread and use it to exit main() only
if there is an unexpected problem. Use kill_work() for all anticipated shutdowns
where possible. Remove unused thread entry.
- Change poclbm version number.
- One array is faster than 2 separate arrays so change to that in poclbm kernel.
- Microoptimisations to poclbm kernel which increase throughput slightly.
- Import diablominer kernel. Currently disabled as not working.
- Import diapolo kernel. Currently disabled as not working.
- Conflicting entries of cl_kernel may have been causing problems, and
automatically chosen kernel type was not being passed on. Rename the enum to
cl_kernels and store the chosen kernel in each clState.
- Set cl_amd_media_ops with the BITALIGN flag and allow non-bitselect devices to
build.
- ALlow much longer filenames for kernels to load properly.
- Allow different kernels to be used by different devices and fix the logic fail
of overcorrecting on last commit with !strstr.
- Fix kernel selection process and build error.
- queue_phatk_kernel now uses CL_SET_VARG() for base-nonce(s), too
- added OpenCL >= 1.1 detection code, in preparation of OpenCL 1.1 global offset
parameter support
- Use K array explicitly to make it clear what is being added.
- Work items have a tendency to expire at exactly the same time and we don't
queue extra items when there are plenty in the queue, regardless of age. Allow
extra work items to be queued if adequate time has passed since we last
requested work even if over the limit.
- Discard work when failover-only is enabled and the work has come from a
different pool.
- Missing include to build on newer mingw32.
- Move from the thread safe localtime_r to regular localtime which is the only
one supported on newer pthread libraries on mingw32 to make it compile with the
newer ming. Thread safety is of no importance where localtime is used in this
code.
- Define in_addr_t in windows if required
- sys/wait.h not required in windows
- Allow API to restrict access by IP address
- Add pool switching to example miner.php
- Display X-Reject-Reason, when provided
- Remove the test for whether the device is on the highest profil level before
raising the GPU speed as it is ineffectual and may prevent raising the GPU
speed.
- Remove unnecessary check for opt_debug one every invocation of applog at
LOG_DEBUG level and place the check in applog().
full member
Activity: 210
Merit: 100
Hello,

I want to start using the donate feature in CGminer and was just wondering: Does it take the donation as I mine or after I find a block while solo mining?

Thanks in advance for your reply, cheers!
hero member
Activity: 1162
Merit: 500
So what's the damage? Well on the 7970 at 1200/1050 clocks, which was getting 694MHash, it's now getting 711Mhash. The 7970 has this unusual behaviour where the hashrate slowly rises for the first 5-10 minutes.

Besides "-k poclbm", which other command line options do I have to use to get optimal results on the 7970?
hero member
Activity: 518
Merit: 500
Quote from: TheHarbinger
950/180  Do the math.

It doesnt work out to a nice round number. But I just tried.
5870 @ 950/300 : 432.4
5870 @ 950/180 : ~441-442
5870 @ 950/170 : ~442

Not a quantum leap, but still quite a nice boost!

So I tried another 5870 that runs at 1 GHz applying the same memory clock and same ratio and a few other speeds:

5870 @1000/300: 454.7
5870 @1000/200: ~459
5870 @1000/190: ~460
5870 @1000/180: ~460
5870 @1000/150: ~454

Smaller boost than at 950. Not too sure what to make of it, but there is nothing wrong with getting a few extra MH while consuming less power Smiley

Note these results were obtained testing just a few minutes on each setting, dont take it as gospel


legendary
Activity: 3583
Merit: 1094
Think for yourself
Maybe nobody cares, but I should notice anyway.
Version 2.0.8 (win32) is last that works fast and effective. My 5850 gives 350 MH/s and I'm happy with the speed. All later versions (I tried every one of them) under the same conditions (cmdline options are the same) give just 308 MH/s
Any ideas?

Yes, you upgraded your video drivers. Thats the root cause. The reason your old copy of cgminer still works faster, is because it contains a cached/compiled copy of the .BIN file generated with your old drivers and sdk. If you were to reinstall 2.0.8 you will likely get the same lousy hashrate.

See here:
https://bitcointalksearch.org/topic/help-with-cgminer-and-5870s2-btc-bounty-solved-63383

Thanks! You saved my brain from explosion)

So, if the description is accurate you should be able to copy the .bin files from your fast 2.0.8 to the current version and get the higher hash rate.
Sam
newbie
Activity: 78
Merit: 0
i finally went back to my parents house and pluged a display to my ubuntu machine (the one i updated from 10.04 to 10.11 using ssh, in order to be able to use cgminer instead of phoenix, and ended up with a non working rig Tongue )

The problem was that the latest drivers, at least with the 2.4 sdk, cause some error / segmentation fault.

I thought that was because i was running with ssh -X, but that was not the case.

I then installed the latest one from synaptic (older than the newst one from AMD website) and all was fine.

ps: i updated to the latest from whatever i was using on 10.04, because the ones from 10.04 were not installable on 10.11 (they were some older drivers).

Also, upgrading had disabled the autologin, but i had no way of knowing that xD
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
Yeah would be good if we knew that magical memory clock / core clock ratio for 5870s !

950/180  Do the math.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Nice, I tried this poclbm kernel but it crashes cgminer on startup for me. I have two 7970s and a 6950 in my system though.
There's a problem with multiple different kernels running in the current cgminer release. This will be fixed on the next release.
Jump to: