Topic: 3% faster mining with phoenix+phatk, diablo, or poclbm for everyone (Read 39162 times)

Ah, thank you -- just the confirmation I was looking for, without having to muddle with my OS

FYI this change is found already in both the phatk and poclbm kernels in linux coin.

Does this tweak/mod apply to the latest GUIMiner? When I installed GUIMiner, I did not create a new miner, GUIMiner is using what ever it uses when you fire it up [Default] tab.

Could you add explicit instructions " I am guessing I am using POCLBM?".

From what I see, there are instructions for phatk's.

But then you say

I opened bitcoinminer.cl and did not find

I would say mods are "truly beneficial", if they lower the needed ALU OPs to process the kernel. This can be checked via AMD APP KernelAnalyzer and is what I try to do. You are absolutely right, that we should not forget the ones, who created a kernel in it's basic version. I couldn't have done this, that's for sure! But in the end we are all interested in the same ... to calculate BTC faster or more efficient, right?

Dia

Diapolo I have been following your thread. You have put a lot of work into it and I look forward to further testing. That being said, including these kernel mods makes it difficult to tell how successful your changes are (lack of control). If your modifications are truly beneficial they will be included in the mainline. 

Also, I believe the original developers are not getting the attention they deserve. These kernel mods and experimentation are welcomed by the community, but lets not forget who put in the original effort!

That would state, one should trust only "the big 3" when it comes to kernel kernel updates, which I think is NOT true .
You are right, it's harder to edit the OpenCL kernel for yourself, but there is no reason in not trying out modified / optimized kernels (like mine)!

Dia

I would just like to restate, if you would like to get these tweaks your best bet is to just update your miner. The big 3 have all been updated at this point and you are better off not editing source unless you have to. The developers are very responsive to modifications in the kernel that can be shown to improve efficiency.

Win7, dual 6970s, Guiminer w/ poclbm.

Went from ~ 409Mhash per card to 423Mhash per card. 

As will DiabloMiner

poclbm will automatically do BFI_INT if your hardware is capable.

You applied the tweak to the phatk.cl file in the main part of the GUIMiner folder didn't you? Because I don't see the bitminer.cl file included with the latest update to GUIMiner any more so I'm guessing that is due to it being replaced with the modified phatk kernel.

Question, if you have to use the BFI_INT flag for this tweak to work with the Phoenix Phatk kernel what flag do you use to make use of it with POCLBM? I'm running the latest version of GUIMiner with the default OpenCL POCLBM miner and extra flags "-v -w128 -f2". I applied this kernel tweak to the modified phatk.cl file that is in the main directory for GUIMiner and it seemed to give me a boost in hash rate but is it actually working without an additional flag?

lol? All 5xxx and 6xxx do.

I thought only 57XX cards support bfi int

All who tried this kernel, the MA-function patch from this thread is included in my modified phatk kernel.
You are able to run it with SDK 2.1, too ... so give it a try .

http://forum.bitcoin.org/index.php?topic=25860.0

YES, this seems to be an ad .

Dia

If you're on one, you should be. OTOH, it shouldn't be slowing it down if you dont have BFI_INT enabled

This actually slows down my poor little 5670       94==>92
 
What is meant by "This will ONLY WORK if you're running with BFI_INT"? Maybe that's my problem

Thanks a ton!

I was getting 272mh/s with my 5830. After implimenting this change, I'm getting 278 or 279. Not too shabby

Got a few mhash on each of my systems, except on my dual 5870 system... Didn't really see a change.

This may just be me or a coincidence, but my single card system showed bigger gains than my multiple card systems. Also my more heavily overclocked systems showed less gains than my less overclocked systems.

Thanks a bunch.

This patch successfully pushed the difficulty up by an extra 3%

382 to 395, awesome.

Yes. As far as I know this has been implemented into the OpenCL kernel of all the main miners. If you want to implement this just update your miner. You can guarantee the change has been made by opening the kernel file and seeing if the Ma() line has been changed.

4850 no difference... pity... seems it's time to buy a new card...

exact same here

This tweek has been implemented into GUIminer.
So if you use GUIminer.
Just update.

410 -> 420 (2.4%) on my HD5870 with the new DiabloMiner! Suh-weeet! Thanks a bunch!

No, its invalid on mining as well. My miner has a HW error counter, it only ticks up when the HW produces a hash it thinks produces H == 0, but when double checked it doesn't.

359 -> 367 (2.2%) on my two 5850's (900/300 1.01V).

Thank you kindly.

This is shown up quite well if you run something like Folding or Seti on your GPU, you will notice a lot more invalid work showing up than you do using the CPU variant and has far as I am aware work for these two does not expire within any reasonable length of time unlike bitcoin so these are actually invalid results and not just "stale".

I think I meant 1 per several hundred billion. Its in the chip specification somewhere, ask AMD.


Bzzt, wrong. GPU hardware does not use the same manufacturing process CPU hardware typically does. GPUs are not mission critical hardware, and rare calculation errors are considered acceptable.

You are correct about "incorrect" voltage, however you assume that it is incorrect at all. The professional versions of these cards run at lower clock rates and lower voltages to reduce the error rate. Consumer cards are not ran at incorrect settings, they are merely ran at settings that lead to acceptable levels of errors.

i dont know what this did but i switched from open CL to phoenix changed a bunch of flags and went from 275Mh to 290MH on each of my 4 6870 cards

thanks!

One error per several hundred million instructions... where are you getting that information from? (an honest question, I'd like to learn more)

A 58xx series, from information I can find, can do between one and four instructions per clock.  If it is clocked at 775000000 cycles per second (775 MHz), that's up to 3.1 billion instructions per second.  So according to your information there would be many errors per second.

When you talk about hardware errors, are you sure you're not talking about rounding errors?

a silicon chip is not supposed to have errors, and will only occur if: incorrect voltage, incorrect temperature range, the silicon chip itself is faulty, something extremely rare such as a cosmic ray bouncing off and [in the case of RAM] 'flipping a bit' perhaps once every few weeks

Hardware errors cause things like bluescreens, frozen machines, display driver crashes and the like.  You would have to get REALLY lucky for a hardware error JUST SO HAPPEN to only effect something that isn't important, like what color this or that pixel is, or something mundane like that.  Most likely if there's a hardware error the odds are it won't happen on a piece of data where it doesn't matter, it will probably crash the system.

What I can find on cosmic ray bit flips:
http://www.zdnet.com/blog/storage/dram-error-rates-nightmare-on-dimm-street/638
http://lambda-diode.com/opinion/ecc-memory
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

I'll cut you off there. You cannot shut off error correction via OpenCL, not that there is any to actually shut off.

The only thing I shut off is HW error message spamming when BFI_INT is on (because BFI_INT is a large hack and certain usages confuse the driver). HW error checking is still enabled in the miner, and the counter still ticks up.

Consumer GPUs do not use ECC-enabled GDDR5.

The HW errors, however, are caused by naturally unstable hardware. On normal Radeons at stock clocks and voltages, and are not overheating, have a known error rate (which is something like 1 error per several hundred million instructions), and do not have excessive (or really, any) internal checks.

This is not a defect in the hardware. GPUs are for playing video games. Scientific apps that are searching for a needle in a haystack (such as what we do) double check the result.

Wow this really worked!!

2 6950's both:

380 -> 395 Mhash/s

Thank you so much!!

My 5870 (950/315) went from 418 -> 428 Mhash an increase of 10 Mhash or about 2.5%.

anyone notice 'slower' performance? I am noticing 'slower' performance with SDK 2.1

Oh, thanks for such a trick!
5770: 210 -> 214
5850: 364 -> 372

No, I am not wrong and I wasn't referring to GDDR5 or any specific memory.  As you know, memory itself must have error correction or a system simply could not run.  Anything that does I/O will have errors.  There are several types and there are several cases where it is better to let them slide than to fix them [and odd pixel or triangle or hexegon somewhere may be better than the performance cost of using error correction to recover it].   Also, as I have mentioned, hardware error correction/check is turned off by Diablo; with that in mind, one must expect errors [or there would be no need to have the error correction in the first place].

For the sake of this thread and forum, I will leave it at that.  You can respond if you like, say what you need to say.  Interested readers should do their research [including myself].  One thing that I am sure of though is that Diablo3 is no dummy and if errors are expected according to what he wrote about the Diablo miner [see the thread], then I believe he is working off of reliable and true information.

I'm sorry Veldy but you're incorrect

GDDR5 does have error correction however, which is why you can push it past its boundaries and not crash, but will get reduced performance from all the error-corrections.  

Aside from GDDR5 and specific ECC ram, any hardware error would cause huge problems up to and including system lockup. Later operating systems (Win7 in my case) have gotten better at coping though, if you're lucky you get a "Display Driver has Stopped Working" error and not a hard-freeze.

Edit: I'll just edit this post in response to the one below to avoid spamming this thread with offtopic posts to say that we'll just agree to disagree

There is a large margin of error with only two digits, but that is roughly 7% improvement.  Nothing to sneeze at.  More than likely, it is closer to 3%

readout went from 1.3 GH/s to 1.4 GH/s. I know most of it is a rounding error, but still an improvement!

Please excuse my snip, but I left the link to the original poster and the donation address [it is not mine and believe it to be the person who discovered this].

If anybody still wants or needs to use the poclbm kernel with phoenix, kernel.cl can be edited in phoenix kernels/poclbm directory.  I haven't tried it, but it should have the same effect.  I edited it locally for both kernels in Phoenix and for the POCLBM Miner "momchil's miner" as was actually indicated above by making the edit to bitcoinminer.cl.  I am sure similar could probably be found in Diablo, but you would have to find it in the Java source [unless it is in the native libraries per platform in which case, it is probably in the source code; I haven't looked, but I suspect it is written in C].

I saw that it was committed to the mainline in source control.  Such simple things can make significant differences and all add up cumulatively ... the process of performance tuning at it's best

EDIT:  Of course, in a short time, everybody picks it up, which drives up the network hash rate and thus the difficulty, so in its way, it is not meaningful once broadly adopted beyond getting a higher work/energy ratio which makes mining more affordable ... keeping some miners online just a bit longer [assuming fixed BTC worth which of course isn't true, but all you can use at any given point in time to determine ROI at any given time].

No it doesn't.  Go read carefully.  Hardware checks are turned off intentionally by Diablo (and I believe all GPU mining software) and there are always going to be occasional hardware errors for this kind of thing (there is for just about all hardware which is why there is FEC, CRC, and other error control protocols for all devices depending upon what they do ... your CPU is a bit of a different beast, and I am not sure how error handling is done there, but I assume there must be occasional errors of some kind].  Excessive hardware errors on the other hand does imply it is pushed beyond limits.  I can tell you that all of my cards passed the Furmark hammer  Not quite the same as mining obviously.  I have not pushed any card very far when it comes to core clock speed and only the 5850s had memory speed reduced [900MHz to 700MHz] and they had the least errors anyway [all being low, but especially those].  The temperature on all of the cards is never allowed to exceed 80C as my limit, but in practice, none have ever been higher than 78C for any amount of time and normally my hottest card is 73C (two almost mirror each other ... different models, cases, rooms (office and cement basement floor) and one doesn't exceed 68C ... just better airflow and heat sink in or something).  MSI Afterburner monitoring all of them.  The highest errors [which as I said, were very low] are on my 6970 and that is the card running in my primary workstation that I am using right now and it has Aero running always, a lot of processes going on, moving windows around often [which uses 3D hardware acceleration when Aero is on] and lots of other services [with priority] running on this machine [including Windows Media Center pulling OTA HD broadcasts down, although I don't typically watch them as I usually get what I need via TiVo].

It is worth determining what a hardware error is for any given device.  Ethernet cards, for instance, are loaded with them, but they correct for it and there is also correction in the Ethernet layer protocol itself to handle retransmits as needed [i.e. due to collisions].  In the case of a GPU using OpenCL, I do not know precisely what would cause a "hardware error" as determined by Diablo.  I suspect bus communication errors [data moving in or out fails a checksum or parity check ... whatever] and could be due to voltage, speed, PCIx bus, etc.  It could be true hardware faults from too much heat, too fast of processing without enough supporting power, or memory errors due to similar.  Many reasons.  Hardware as complicated as a video card [especially the GPU itself] will always produce errors, but it depends on what type of errors and how often whether it is a problem.  For instance, if hardware error checking was turned on, it may self correct or recompute .. whatever [I am speculating, I need to look it up to be sure].  Also, with video for instance, certain types of errors result in essentially unnoticeable changes (maybe a pixel is shaded slightly off, or a vector skewed ever so slightly .. again, hypothesizing), and thus, are accepted by the manufacturer (AMD in this case).  Different uses have different tolerances to different types of errors.  Look at your cable model or DSL modem and if the information is there, you will see lots of error stats like correctable errors and uncorrectable errors.  The latter, in that case, is information that it had no ability to correct and are usually external to itself.  Correctable errors are errors that may be externally caused [usually are], but error correction protocols were able to fix the error without a resend [meaning, FEC, CRC, parity and other methods which can essentially determine the bit that is incorrect and fix it].  Error correction in the case of communications means overhead in both bandwidth usage and computational analysis of the stream [and thus some latency].  My point is only that errors cannot be eliminated, only compensated for or dismissed as acceptable and dealt with either by redoing the work or simply ignore the results [with video and audio, it is usually fixing it via some error correction mode and anything that escapes that is deemed acceptable, or rather allowed to pass with the assumption that within design limits, the errors are not significant ... so bad hardware is often still usable with lots of errors and you get to suffer the effects of say, marcro blocks or pixilation or with audio, clicks or silences, etc.].

All this writing and all I really said is that hardware errors are normal and does occur with ALL GPUs.  Excessive hardware errors are not and the definition of excessive depends on the hardware and its intended function; I am not sure what is excessive with GPUs in general, but with hardware correction turned off by Diablo, the author indicates 3 in 1000 [shares] is just fine.  I saw less than that on all GPUs.

Thanks!

5850 - 316 -> 325 (~3%)

Interesting, may be worthy of its own thread.

As far as this modification it is being included in the latest versions of the various miners as far as I know, so you will not have to do this in the future.

Hardware errors?  Any hardware error means you've pushed the boundaries of either: voltage, clock speed, or heat...  Reduce one

I am running 5850s and a 6970 (the latter of which was always slower using phatk kernel as opposed to poclbm kernel until 1.50).  The latest Phoenix 1.50 seems to be significantly better.  I applied the #define fix, which I think is a bug fix more than an enhancement [judging by the stale percentages over the short term ... so the jury is still out I guess] and I am getting between 1.5-2.5% additional on my 5850s (nothing too aggressive, XFX boards of standard specs, factory voltages and 850-875MHz core and 700mH memory clocks between them) and about 2.5% on my 6970 (MSI, also standard spec board at factory voltages with the core clock at 920MHz and the memory clock at 1375MHz).  Note that I use the machine with the 6970 in it for day to day business and all day work via VPN/remote desktop (32-bit color full screen locally ... XP on the other end, so only one monitor) and I leave Aero on.  Win7 x64 on all machines except one which is Vista x64.  Aero off on all except my workstation with the 6970.

THERE IS A "MINOR" BUG IN 1.50 HOWEVER.  I don't know if the #define fix tickled it or if it was there before and I didn't notice it [I have only been using 1.50 for a few days anyway].  Soon after starting the miner on my 6970, long polling push came through and it shows 1 rejected in the phoenix console,  however, Deepbit did not show any rejects on it's side (0.00%).  With several previous versions, the accepted/rejected values ALWAYS matched, even after days, however, there were other issues as many have experienced.  I am curious, is the reject being shown because phoenix is now finding the occasional hardware error and counting it as a reject [without submitting anything] as opposed to simply burying it in previous versions?  Another reject came along after that, also following a long polling push and the console shows 2 rejects and deepbit shows 0.76% stale (131 accepted and 1 stale is 1/132 = 0.76%).  So, clearly one was a standard reject [stale/invalid] from the pool and the other from Phoenix itself.  I just verified on the others, and one of them also has one extra reject (in fact, that is the only reject it has). Phoenix is showing more rejects than Deepbit ... for the first time in many versions.

The reason I wonder if this might be because of hardware errors is I was playing around with Diablo Miner yesterday.  Achieved great hash rates as reported by Diablo; about the same as I would get with Phoenix 1.50 or slightly better [not as good as Phoenix 1.50 with the #define fix using phatk].  Diablo showed very very few hardware errors (according to the forums, it was low .. less than 3 in 1000 for any card, and in some one case only 1 in ~2000).  However, Diablo currently has a TERRIBLE problem with rejected shares (4%-8% per miner instance for me ... -v 2 -w 128 on all instances and I think -f 10 on the 5850s and -f 30 [default I believe] on my 6970 since it is the machine I use for other things and often.  I was so horrified that I ditched Diablo without even a report on their thread.

Having said that about the odd "extra" reject noticed in two miner instances, I have not seen another one since on any of my miners, but they have not been running all that long either (about 35 minutes).  In fact, in this time, there are only 3 rejects among all my miner instances and two of them are reported by Phoenix and not by Deepbit.  Accepted share count exactly matches on each miner to what is shown on Deepbit, so it isn't a big deal; but I would like to know what is causing the extra rejects reported locally only.

Visiontek 5870 are so awesome

I can confirm on two machines:

Ubuntu 11.04, 11.4 SDD-SDK, pyopencl + phoenix 1.48: card is Visiontek HD 5870, running at 855/900, stock voltage, fan at 50%, 73 C,  with new define line == increase from 365 Mh/s to 374 Mh/s; running at 870/900 increase from 377 Mh/s to 383 Mh/s

Windows 7 x64: 11.4 sdd-sdk, guiminer (phoenix 1.48): card is Visiontek HD 5870, running at 948.7/300 stock voltage, fan 48% 68 C, with new define line == increase from 416 Mh/s to 425/s

yeah!
will donate to original poster. THANKS!

OP correctly included the original author's donation address, so clearly he isn't trying to steal credit for it

Win7 64

GUIMiner / phoenix phatk

5850 @ 920/300

My mhash tends to fly all over the place but from what I can gather:


Before: 365-379
After: 360-388

Everyone make sure to donate to Bitless and not the address in the OP's sig!
(OP posted Bitless's Donate address I believe)

Latest poclbm exe (20110627) also had the phatk patched.

Done.

Its also in the latest Diablo.

Sapphire 5830 @ 1000/300 @ 1,2v @ 48c (AC)

309-310Mh/s > 315-317Mh/s

Sharing: from 386-396 Mhash/sec on 5850XFX+IcyVision @ 975/300/1.174v/58C
Great work! Thanks for the info.

Strange format is actually the same as phatk.cl but without 'enter's'. Just press CTRL+F, type fist part of string to change and after u find it replace with what u have in first post. Works well for me ( values arent much higher, but more constant (387 instead of 377-385). If you want I can post here the file.

thx!
send a donation

NO! has a strange format and not editable with "normal" MS editor .. just edited phatk kernel.cl
...

Works also for POCLBM, just need to edit bitcoinminer.cl and change very same line.

PS.
Add it to first post plx.

Works with poclbm+phatk.

Someone whitelist that guy out of the newbies forum!

5850Vapor
392->401MHash (995/300) POCLBM with phatk

Win7/x86

5830 @ 1000/300

Went from 308 to 317 Mhash (327 Mhash @ 1033/300).

HD 5830 - 275 Mhash -> 279 Mhash
HD 6950 - 340 Mhash -> 359 Mhash

Very nice

I'm glad this was helpful but be sure to send donations to the address listed, not me.

From 338.9 to 352Mhash/s on my 6950 (only @860) ~3.86% gain

Will donate a bit as well if this is stable

Awesome find, Gave me 6-7 more MH froom 340 with my 5850 Extreme. I'll send a few bitcents your way if this is stable.

321 - 329 Mhash/s on 6870 @ 1056/366, Win 7

its weird, while the hash rate shows more it did'nt actually produce any more shares over the same period of time...

Thanks!
350 -> 365 on my 6950@900MHz 

About +5mhash on 5770. *tip sent* Thanks!

thx, sent a small donation

did you edit bitminer.cl in the guiminer folder?

5830 980/600 running a 70 deg fans 55%

produce 290 Mh ...

No change under guiminer after update of the kernel file ...

going back to original file ...

good luck

5870:  350 to 370 MHash /sec

great thanks works perfectly fine!

5830 (970/300) 301 -> 307 Mhash/s

359 -> 367 MH/s on 5850! Thank you very much (small donation will be sent this evening)!

379 -> 382 MH/sec on 5850 (966/180)
199 -> 202 MH/sec on 5770 (933/300)
441 -> 449 MH/sec on 5870 (1006/180)

All in all, pretty good!

280 to 289 on a stock speed 5850... will be using this on all my miners, thanks!

Note that the origin of this mod is here: https://forum.bitcoin.org/index.php?topic=22965.0
And here's the author: https://forum.bitcoin.org/index.php?action=profile;u=30003

Nice find, thanks. Will add this to hashkill as well if you don't mind

Yes, from ~330 to ~340 Mh/sec on an o/c 5850. Great work.

Great!

Got an increase of about ~370 to ~380 on both of my 5870

Thank you

Yeah, from 355.9 to 372.7 on unlocked 6950@840mhz, and only from 364 to 367.8 on 5850@920.

279 to 285 on a 6870@950.

Looks like the higher end cards are getting about 5%.

Confirmed on windows 7, I got a increase from 387.4 MH/s to 401.7 MH/s per GPU

from 355.9 to 372.70 on my 6950 on linux.

I saw an 9 MHash/sec (6.2%) increase on one of my miners after this fix, will do it on my other one later as well. Thank you! Will be sending a small donation your way soon.

Reposted from newbie forum posted by bitless

I just tried this and got >3% improvement in mining speed. On my 6870, I was getting 299 MHash/sec, and now I'm getting 308 or so. The change is simple enough for anyone to do it - you don't need to be a programmer to use it.

You can go to phatk's kernel.cl file (don't worry, it just sits there in the open, no need to recompile anything), find this line
  #define Ma(x, y, z) amd_bytealign((y), (x | z), (z & x))
and change it to this line
  #define Ma(x, y, z) amd_bytealign( (z^x), (y), (x) )
Once you've done it, restart the miner.

Technically, this is 1 less instruction for the Maj function in the hash, which is called ~128 times for each nonce value, so we get +3% to mining speed. This will ONLY WORK if you're running with BFI_INT. I'm using phoenix with phatk kernel on Ubuntu, so YMMV, but I see no reason for this to not work with other setups. As always, do play around with aggression and other settings after you've applied the change. Deepbit seems to be accepting my shares generated this way, but it comes AS IS, without any warranty whatsoever - if it doesn't work for you, or has been posted already, please don't blame me Smiley

If this helps you mine faster, please share your MHash/sec results, before and after. You can also donate to 15igh5HkCXwvvan4aiPYSYZwJZbHxGBYwB . I hear people are getting 50 BTC for things like this, and it would be nice to get some.

If you want to verify the correctness of the change, here's the truth table for the new Ma() function

x y z   Ma
0 0 0   0
1 0 0   0
0 1 0   0
1 1 0   1
0 0 1   0
1 0 1   1
0 1 1   1
1 1 1   1

Works also for POCLBM, just need to edit bitcoinminer.cl and change very same line.

Donate to 15igh5HkCXwvvan4aiPYSYZwJZbHxGBYwB

This is a repost from the newbie forum. https://forum.bitcoin.org/index.php?topic=22965.0;topicseen