Pages:
Author

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

sr. member
Activity: 418
Merit: 250
No it doesn't.  Go read carefully. there are always going to be occasional hardware errors for this kind of thing

All this writing and all I really said is that hardware errors are normal and does occur with ALL GPUs.

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
member
Activity: 98
Merit: 10
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!

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% Smiley
hero member
Activity: 560
Merit: 500
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!
member
Activity: 98
Merit: 10
Reposted from newbie forum posted by bitless

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

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].
member
Activity: 98
Merit: 10
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.

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.

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 Smiley

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].
member
Activity: 98
Merit: 10
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)

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

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 Smiley  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.
sr. member
Activity: 406
Merit: 250
Thanks!

5850 - 316 -> 325 (~3%)
sr. member
Activity: 378
Merit: 255
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.

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.
sr. member
Activity: 418
Merit: 250
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)

Hardware errors?  Any hardware error means you've pushed the boundaries of either: voltage, clock speed, or heat...  Reduce one
member
Activity: 98
Merit: 10
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.


full member
Activity: 154
Merit: 100
Visiontek 5870 are so awesome
newbie
Activity: 56
Merit: 0
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!

full member
Activity: 154
Merit: 100

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

full member
Activity: 182
Merit: 100
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
sr. member
Activity: 418
Merit: 250
Everyone make sure to donate to Bitless and not the address in the OP's sig!
(OP posted Bitless's Donate address I believe)
newbie
Activity: 28
Merit: 0
Latest poclbm exe (20110627) also had the phatk patched.
sr. member
Activity: 378
Merit: 255
Works also for POCLBM, just need to edit bitcoinminer.cl and change very same line.

PS.
Add it to first post plx.

Done.

Its also in the latest Diablo.
sr. member
Activity: 458
Merit: 250
beast at work
Sapphire 5830 @ 1000/300 @ 1,2v @ 48c (AC)

309-310Mh/s > 315-317Mh/s
full member
Activity: 154
Merit: 100
Sharing: from 386-396 Mhash/sec on 5850XFX+IcyVision @ 975/300/1.174v/58C
Great work! Thanks for the info.
member
Activity: 98
Merit: 10
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


did you edit bitminer.cl in the guiminer folder?

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

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.
Pages:
Jump to: