Bitcoin Forum
May 28, 2024, 02:03:51 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 [519] 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 »
10361  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 11, 2012, 12:25:56 PM
- 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.
10362  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 11, 2012, 11:24:29 AM
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 <arg>   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().
10363  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 11, 2012, 01:42:09 AM
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.
10364  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 11, 2012, 12:35:46 AM
My signal to noise ratio is extremely low with messages coming from everywhere and forum questions and so on, so I'm going to once more stop replying to anything that other people can answer. Thanks to the others who contribute to this thread.
10365  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 11, 2012, 12:33:05 AM
If that came from anyone else I would have laughed at it.

I heard people posting about it before and myself have found the same but the Mhash/s gains and temp drops are usually (at least to me) too negligible to pay too much attention to it.
On a 6970 it was 20 Mhash.

20 MHash/s over worst possible ratio of mem:core or over settings of an overclocked and tweaked card?
Sorry it was at 960, not 920.
Watching the trend in hashrate rise as I increased engine clock speed, I noticed a larger-than expected rise at 955 and then it peaked at 960. The hashrate was 20 higher there than I would have expected. Even though one of the cards goes as high as 985, it was faster at 960 than at 985 so I left it at 960 where it ran cooler and faster. It was only the other card that got to 990 when it started exceeding the values at 960.
10366  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 10:58:06 PM
If that came from anyone else I would have laughed at it.

I heard people posting about it before and myself have found the same but the Mhash/s gains and temp drops are usually (at least to me) too negligible to pay too much attention to it.
On a 6970 it was 20 Mhash.
10367  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 10:53:21 PM
Note that there are "sweet spots" in hash rate. After you've found the top speed, try going down by 5 at a time. Sometimes you'll find a magic Mhz where it suddenly jumps up.

If that came from anyone else I would have laughed at it. But since its you, Ill have to believe it, but is it not more likely the reason is not so much the clockspeed as such, as the ratio between GPU and memory clock? IOW, rather than reducing your GPU clock, perhaps try increasing the memory clock a little bit?
Indeed, but there is a -125 or -150 difference limit and we're trying to run memory as low as possible. So the equation works out best in energy terms at the lower memory clock where you hit the right ratio difference between mem and engine, wherever that is.
10368  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 10:42:54 PM
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.
Beautiful.  I'm running this on 2 of my boxes and seeing substantial increases.  I'm getting about a 3.3% increase on the overclocked box.  What's really weird is that I saw a 6.5% increase on the box that's only overclocked by 75 mhz.  Heh.  Weird.  I'll take it though.
After an overnight run:
GPU 0:  73.0C 4743RPM | 708.1/706.7Mh/s | A:4454 R:7 HW:0 U: 9.83/m I:11
So I'll call the actual rate 707

Note that there are "sweet spots" in hash rate. After you've found the top speed, try going down by 5 at a time. Sometimes you'll find a magic Mhz where it suddenly jumps up. That happened at 920 on my 6970s for example. Maybe that's what you're experiencing.
10369  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 10:25:22 PM
OK, so I take it that I can no longer copy the .bin files from previous versions of CGMiner?
I can't get 2.2.3 to generate them.
Sam
Change the datestamp on your old bins to the new dates. That will do it. One day, just one day, I'd like for that fucking failed to build bug to go away. Maybe next release!  Roll Eyes
10370  Bitcoin / Mining software (miners) / Re: collection for cgminer 7970 [Card as been sent! THANK YOU EVERYONE] on: February 10, 2012, 03:35:07 PM
Working on the 7970 tuning, I have tried to port both the diapolo and diablo kernels to cgminer. Alas neither of them are actually working yet, so instead I started modifying the existing poclbm kernel in cgminer to improve throughput. This should work on other GPUs as well as the 7970, but I have no idea if it's better or worse than phatk.

When it's released it will get a new date/version number, but I haven't changed the number right now so that people can download it now and give it a try:
https://raw.github.com/ckolivas/cgminer/kernels/poclbm120203.cl

Remember to delete any .bin files and if you're not on a 7970 with the latest cgminer, you'll have to tell it to use that kernel with -k poclbm.

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.
10371  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 03:33:23 PM
Working on the 7970 tuning, I have tried to port both the diapolo and diablo kernels to cgminer. Alas neither of them are actually working yet, so instead I started modifying the existing poclbm kernel in cgminer to improve throughput. This should work on other GPUs as well as the 7970, but I have no idea if it's better or worse than phatk.

When it's released it will get a new date/version number, but I haven't changed the number right now so that people can download it now and give it a try:
https://raw.github.com/ckolivas/cgminer/kernels/poclbm120203.cl

Remember to delete any .bin files and if you're not on a 7970 with the latest cgminer, you'll have to tell it to use that kernel with -k poclbm.

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.
10372  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 11:18:17 AM

Didn't' forget about this  Tongue I ran 2.1.2 with no errors for 18 hours then started 2.2.3 yesterday with the same flags and got this:
(...)
Weird how las initialised is slightly after start time, but it wasn't disabled for a few hours.  You might be on to something here.

I had to stay on 2.1.2. It's weird just us having reported this problem.
I believe that when people with 5970 rigs running Linux update cgminer, more posts like ours will appear.

Working on i t... workaround for now is to set fan to fixed speed and disable --auto-fan
10373  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 06:49:36 AM
Edit: Perhaps we could try my old approach of writing to output in the kernel, because I know that worked for me?

That's the code I used, but uses your NFLAG. It would need to scan the output buffer on host side everytime after a kernel execution, which could lead to higher CPU usage (and needs changes in host code), but saves the IF-clause and another write into output (which saves the kernel quite some instructions, even on GCN).

Code:
u result = (V[7] == 0x136032ed) * nonce;
output[NFLAG & result] = result;

This code would be more like your current code, but uses the approach of comparison and mul to save 0 or a positive nonce in result (and is slower than your current code). But for sure that can't be the problem we are looking for ...

Code:
u result = (V[7] == 0x136032ed) * nonce;
if (result)
output[FOUND] = output[NFLAG & result] = result;

Dia
Writing to output on every iteration isn't going to fix the problem, and I can't see how this would help to be honest. Note that your last code will end up setting output[FOUND] to 0 and would undo anything you wrote to it with other threads  Wink
10374  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 06:45:46 AM
Okay, so as I wrote, if Phatk works, then the base-nonces passed to the kernel should be correct for diakgcn. I will check the phatk.cl to be sure. I saw you added a BITALIGN path to diakgcn, that's not using bitalign() or any other OpenCL function, but simply does it's thing directly. What is that for, i'm not sure if that's needed for a GCN kernel anyway Smiley.
Another idea, are you applying a BFI_INT patch on Tahiti (it must not use amd_bytealign())? This is not needed and produces wrong values ... I want that damn thing working Cheesy, I stared at it quite a few hours too ^^.
BITALIGN is to enable amd media ops for platforms that have it.

BFI INT patching does NOT work on Tahiti. It makes a corrupt kernel. SDK2.6 automatically uses the BFI INT instruction anyway so there is no need for this crappy patching.
10375  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 10, 2012, 05:59:47 AM
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 ...

You said local copy, is it a copy of the last version of my fork? As you've observed I am new to this kind of working, but I hope you see my progress Cheesy.

Dia
Compiling this on windows is nothing short of a DISASTER so forget it.

Anyway I fixed up a few things on my Diapolo branch on github. Pull the changes to bring your local tree into sync. Alas I'm still only getting HW errors, so there's clearly something wrong. The return code for giving me a nonce I use works fine, provided I'm testing for the right thing before sending the nonce back. I've stared at it for half a day and can't find what's wrong. I even tried diablo's kernel and encountered exactly the same problem. For some reason I keep thinking it's something to do with confusion about the initial offset of the nonce and what is passed to the kernel.
10376  Bitcoin / Mining software (miners) / Re: Decreasing performance on: February 09, 2012, 11:15:19 PM
Thanks for the reply ckolivas and again thanks for the good work..
If I remember right, with version 1.5.1 or a bit later you've upgraded the kernels and again with version 2.2.1or3. I don't blame you for the performance decrease ckolivas! I just want to find out what other users do for best performance, what the best config is.
Btw.. do you still support SDK 2.1, in your FAQ you mention 2.4/2.5 only.
The kernel updates recently were purely bugfixes for platforms they wouldn't work Tongue

SDK 2.1 should work fine for 5x cards with poclbm. I don't think they work with phatk.

Thanks. Will try 11.6 with SDK 2.1 then. Post an update soon..
Btw.. 1.5.x was best performance ever..  Tongue
I seriously cannot see how that can happen...
10377  Bitcoin / Mining software (miners) / Re: Decreasing performance on: February 09, 2012, 11:12:11 PM
Thanks for the reply ckolivas and again thanks for the good work..
If I remember right, with version 1.5.1 or a bit later you've upgraded the kernels and again with version 2.2.1or3. I don't blame you for the performance decrease ckolivas! I just want to find out what other users do for best performance, what the best config is.
Btw.. do you still support SDK 2.1, in your FAQ you mention 2.4/2.5 only.
The kernel updates recently were purely bugfixes for platforms they wouldn't work Tongue

SDK 2.1 should work fine for 5x cards with poclbm. I don't think they work with phatk.
10378  Bitcoin / Mining software (miners) / Re: Decreasing performance on: February 09, 2012, 10:56:21 PM
Over time, with new CGMINER versions, never kernels and for sure updated drivers/app sdk the performance is lower and lower.

Currently with 12.1 driver and APP SDK 2.5 I only get around 280Mhash with poclbm and worksize 128 (I8) (tried many settings and different kernels and this works out best).
See this is the thing. You're saying it's the newer kernels and the updated drivers and sdk.... but there have been no updated kernels. They are essentially unchanged for 7 months now. So look at the other things you've blamed instead.
10379  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 09, 2012, 10:54:32 PM
but i cant start mining, except with cpu only (on 2.1.2, 2.2.3 has no cpu support i think), it tells me that there is no valid gpu available.
What did ./configure show when you built it?
Also, when running remotely:
Code:
export DISPLAY=:0
then start it.
10380  Bitcoin / Mining software (miners) / Re: CGMINER GPU bitforce overclock monitor fanspeed RPC in C linux/windows/osx 2.2.3 on: February 09, 2012, 09:34:41 PM
Hey Con,

I looked again through every kernel argument and compared line by line with my Python code. I found 2 small differences and 2 brackets, that are not needed (see last commit https://github.com/Diapolo/cgminer/commit/68e36c657318fbe1e7714be470cf954a1d512333), but I guess they don't fix the persisting problem with false-positive nonces (perhaps you can give it a try - I have no compiler or IDE setup to test it by myself). The argument order is exactly as DiaKGCN awaits it, so that can't be the problem either.

It could be a problem of your changes to the output code in the kernel, a problem with the base-nonces, who are passed to the kernel or something with the output-buffer in the CGMINER host code ... :-/. Where resides the output-buffer processing? As I said my kernel used ulong * natively, which I changed to uint * in one commit of my fork, I guess I need to look at it.

Edit: OMFG, I introduced a bug with one of my former commits, which changed the type of the output buffer from uint * to int * ... fixed that one! It's time for another try Con Cheesy.

Dia
Diapolo... I appreciate the effort you're putting in, and I realise you're new to this collaborative coding and source control management, but probably a good idea to see your code actually compiles before you ask someone to test it. Usually people compile and test their own code before asking someone else to test it for them.

Anyway... I fixed the !(find) in my local copy and it still produces hardware errors.

edit: It doesn't matter what vectors or worksize I try this with.
Pages: « 1 ... 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 [519] 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!