Modified Kernel for Phoenix 1.5

[BOARBEAR]

I like the VECTORS4 feature, it gives me extra 5Mhash/s using SDK2.5

[joulesbeef]

well crap Phateus, I guess I owe ya an apology. 300 shares, no rejects. it must have been a bad day on the pools i was on.

[navigator]

DELETED for privacy

[CanaryInTheMine]

I am getting rejects and hardware problem errors since the modification of __init__.py. Diapolo's 7-11 version is the last stable version for me on my 2 5830's @ 1000/350 stock voltage. I switched back to 7-11 version last night and today on BTCGuild I am back to showing 4500 (31, 0.68%) on one card and 4324 (27, 0.62%). I am getting 320mh/s with the 7-11 version and was getting 324mh/s with your phatk 2.1. The number of stales/rejects showing on BTCGuild and in phoenix log after a short period of mining was up to and over 3% on both cards yesterday. If you would like I can let one card run each version to compare the difference. I can also provide a log of phoenix if needed. Not for certain about this, but I believe I was only getting the "hardware problem?" error from diapolo's versions after 7-11 and  your phatk2.0. With phatk2.1 I saw the introduction of the rejected shares. I can provide any info if needed. I assume the kernel is pushing the card too hard as Diapolo mentioned earlier in his thread. I have no idea why it is affecting some and not others.

I had to reduce the OC by 10, kept same memory settings with my 5830s using 2.1

[Phateus]

well crap Phateus, I guess I owe ya an apology. 300 shares, no rejects. it must have been a bad day on the pools i was on.

Not a problem, I'm glad its working out for ya

I am getting rejects and hardware problem errors since the modification of __init__.py. Diapolo's 7-11 version is the last stable version for me on my 2 5830's @ 1000/350 stock voltage. I switched back to 7-11 version last night and today on BTCGuild I am back to showing 4500 (31, 0.68%) on one card and 4324 (27, 0.62%). I am getting 320mh/s with the 7-11 version and was getting 324mh/s with your phatk 2.1. The number of stales/rejects showing on BTCGuild and in phoenix log after a short period of mining was up to and over 3% on both cards yesterday. If you would like I can let one card run each version to compare the difference. I can also provide a log of phoenix if needed. Not for certain about this, but I believe I was only getting the "hardware problem?" error from diapolo's versions after 7-11 and  your phatk2.0. With phatk2.1 I saw the introduction of the rejected shares. I can provide any info if needed. I assume the kernel is pushing the card too hard as Diapolo mentioned earlier in his thread. I have no idea why it is affecting some and not others.

Any information you can post would be helpful in fixing this.  I am going to try to rewrite some of the init file and see if I can make it a bit more stable...

[BOARBEAR]

I am getting rejects and hardware problem errors since the modification of __init__.py. Diapolo's 7-11 version is the last stable version for me on my 2 5830's @ 1000/350 stock voltage. I switched back to 7-11 version last night and today on BTCGuild I am back to showing 4500 (31, 0.68%) on one card and 4324 (27, 0.62%). I am getting 320mh/s with the 7-11 version and was getting 324mh/s with your phatk 2.1. The number of stales/rejects showing on BTCGuild and in phoenix log after a short period of mining was up to and over 3% on both cards yesterday. If you would like I can let one card run each version to compare the difference. I can also provide a log of phoenix if needed. Not for certain about this, but I believe I was only getting the "hardware problem?" error from diapolo's versions after 7-11 and  your phatk2.0. With phatk2.1 I saw the introduction of the rejected shares. I can provide any info if needed. I assume the kernel is pushing the card too hard as Diapolo mentioned earlier in his thread. I have no idea why it is affecting some and not others.

Maybe try disable overclock.  I had an experience where switching to new miner caused problems.  Then I revert back to stock clock and problem solved.

[ssateneth]

I've gotten "Hardware problem?" errors often since the __init__ patches of 7-17 diapolo and phatk 2.0+, but they don't seem to cause any decrease in mhash, or crashes, or increased stales, so I'm not too worried about them. I'm assuming it causes "Hardware problem" when 1 hash isn't quite right, and getting 1 "bad" hash error every 10 minutes while doing 330 million hashes every second... you can probably see where I'm going with this.

If it matters, reducing my memory clock from 370 to 350 drastically reduced my "Hardware problem?" errors. I've gone from 1 every ~2 minutes to 1 every ~30 minutes.

[navigator]

DELETED for privacy

[bcforum]

Now running 2.1 on one card and at ~500 shares without a single reject or hardware problem. I don't get it. Maybe a pool issue? I know for certain that I still haven't seen one hardware problem? error come up running diapolo's 7-11 version. My temps are usually 62c or lower, currently at 59c.

Rejects are valid hashes that weren't accepted by the pool for some reason. Generally it is because the pool has moved on (added transactions, bumped up the timestamp, etc) Reject count shouldn't be used to validate GPU kernel performance, but you can argue good mining software shouldn't have a high reject rate.

Phoenix (and other mining frontends) checks the results of the GPU miners before sending it on to the pool. If the nonce is invalid (doesn't generate a hash with zeros in the proper place) it is reported as a hardware problem. Different kernels may cause more hardware errors due to how they are exercising the GPU. Unfortunately, this is a problem with your hardware and not the kernel. You will probably have to tweak your overclocking for each kernel to find a stable operating point.

[navigator]

DELETED for privacy

[deepceleron]

I left 2.1 running on both cards overnight. Today, one card is showing only the hardware problem error occasionally, no increase in rejects. Here is ~5hr log of it to get an idea of how often it pops up, http://pastebin.com/raw.php?i=qQedNWRG. I immediately restarted that miner using 2.1 and got the first hardware problem after 4mins of mining. Next I switched back to diapolo 7-11. Ran it for 15 mins without a single hardware error. Okay once more back to 2.1, again another hardware problem after only 2 mins this time. So I can turn the problem on and off by switching versions. This whole time my other card has been running 2.1 since last night without a single problem. I'm not too concerned about the hardware problem error. But the first night I tried out 2.1 I was getting a large amount of rejects also.

EDIT: Backed off clock 10mHz like CanaryInTheMine said in his earlier post to 990 for 10 mins and no problem showed up. Put back to 1000 and one popped up after ~30secs. Running the newer version at the slower speed doesn't net me any gain in mhash.

Again, the hardware problem doesn't concern me much. It's just the sudden amounts of rejects I was getting after I first switched to 2.1

Well the hardware error indicates not necessarily a 'hardware error', but a bad hash was detected outside the running OpenCL kernel by the first validity check:

In __init.py__:

 if not hash.endswith('\x00\x00\x00\x00'):
                        self.interface.error('Unusual behavior from OpenCL. '
                            'Hardware problem?')

So to get this error, either the SHA hashing math or the hash checking in OpenCL was corrupted, and an invalid hash was returned as a valid share. If this happens, then it is also possible that a hash that would be a valid solution could be corrupted and not returned or sent.

Diapolo's 7-17 kernel is also more sensitive to overclock than previous ones, and will start returning the 'hardware error' at overclocks where 7-11 doesn't. Either a different stream core instruction on the die is being used that doesn't overclock well, or the higher utilization causes some failure. My way of thinking is you don't want to overclock to the point where any bad math is happening in any stream processors. If you have to overclock 5% less on a kernel that is 1% more efficient, then you lose any gains.

[phorensic]

Ever since the kernel development for phatk got fired up again people noticed more "kernel errors".  After weeks of tweaking and testing I've come to realize a few simple things.  When overclocking to the edge, first the kernel will throw kernel error's a couple times an hour, after just a *few* more MHz it will actually crash the driver and reset the desktop, possibly killing the connection to the pool server.  It's amazing how razor thing those margins are.  Even as small as 4MHz on the core clock can go from rock stable all day, to kernel error, to crashed driver.  I don't see it as a bug, I see it as the kernel reporting what is going on better than before (verbosity).

[ovidiusoft]

@deepceleron

As long as the board doesn't crash or overheat, I think you just need to find out if the increase in hashrate is significantly more than the increase in hardware errors. For my board, on Diapolo's 08-04 version I get 0,2% hardware errors (out of the accepted shares, maybe time referenced would be better) at 1040 Mhz. At 1050, it's 0,21%, so a variance that can be as well network conditions or measurement errors (if time was involved). But, the hashrate increases by 0,95%. So my reasonment is that I gain about 1% performance while losing 0,01% because of more hardware errors.

I only tested 2.1 on 1050 and for a shorter time, but hardware errors seem to be in the same range as in Diapolo's kernel, so I will most likely leave the frequency alone and do comparative testing on the kernels only.

[bcforum]

@deepceleron

As long as the board doesn't crash or overheat, I think you just need to find out if the increase in hashrate is significantly more than the increase in hardware errors. For my board, on Diapolo's 08-04 version I get 0,2% hardware errors (out of the accepted shares, maybe time referenced would be better) at 1040 Mhz. At 1050, it's 0,21%, so a variance that can be as well network conditions or measurement errors (if time was involved). But, the hashrate increases by 0,95%. So my reasonment is that I gain about 1% performance while losing 0,01% because of more hardware errors.

I only tested 2.1 on 1050 and for a shorter time, but hardware errors seem to be in the same range as in Diapolo's kernel, so I will most likely leave the frequency alone and do comparative testing on the kernels only.

I think you should double (at least) the number of hardware errors. Remember that for every bad nonce that is reported, there is probably a good nonce that goes unreported.

[ssateneth]

No update yet? It's aug 8 now <.<

[Phateus]

No update yet? It's aug 8 now <.<

Just, posted the new version, enjoy.

[ovidiusoft]

First run report:

* Diapolo's 08-04: 338.9
* phatk-2.1: 340.9
* phatk-2.2: 341.3

Board is a 5830 Xtreme from Sapphire, GPU at 1050, RAM at 325, phoenix options:

-k phatkmod-0804 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=14 WORKSIZE=256
-k phatk-2.1 VECTORS BFI_INT FASTLOOP=false AGGRESSION=14 WORKSIZE=256
-k phatk-2.2 VECTORS BFI_INT FASTLOOP=false AGGRESSION=14 WORKSIZE=256

I'll leave it overnight to see if any problems (hardware errors, etc), but it looks good! Thank you for your work! (and waiting for Diapolo's reply on your kernel ).

[teukon]

Sapphire HD5850 Xtreme: 899MHz/327MHz@0.9875V
Linux x86_64, Catalyst 11.6, SDK 2.1
VECTORS BFI_INT AGGRESSION=14 WORKSIZE=256

phatk 2.1: 376.9 Mh/s (+/- 0.1 Mh/s)
phatk 2.2: 377.5 Mh/s (+/- 0.1 Mh/s)

[Beta-coiner1]

Radeon 6950- .1-.3 Mh/s over Diapolo's latest.v 4 w64 f3
Radeon 5770- .2-2.0 Mh/s  "     "   ".v 2 w128 f30

Cat. 11.6B /SDK 2.5

Not bad of an improvement.

[UniverseMan]

Cat 11.6, SDK 2.4
Ubunutu 11.04, phoenix 1.50

cards - 5830 1000/300, 6870 945/1050
phatk 2.1 - 324, 299
phatk 2.2 - 323, 298

Slightly slower on 2.2. I've listed it as 1 MH/s slower on both cards, but in fact it's more like .5 or less slower.