NICE!
Dropped the new kernel into GUIMiner's sub folders, created a new Phoenix Miner with the default switch listed on page 1 and BAM a solid 10% increase if not a little more and so far stales are zero in the 20 minutes I have been running it using Bitcoins.LC pool.
I can't send much but I will certainly send something, will see how the pool goes over the next day and how well the new kernel holds up.
Topic: further improved phatk_dia kernel for Phoenix + SDK 2.6 - 2012-01-13 - page 4. (Read 51252 times)
August 12, 2011, 12:49:32 AM
August 12, 2011, 12:39:02 AM
Not yet, I had the impression that this only works for V++ non Express Editions!? I will take a look now
.Are you skilled to interpret APP Profiler results?
Dia
I have no idea about the Windows version, but the Linux version works completely standalone.
I wouldn't say I'm skilled at all. It just happened to be bundled with the SDK, and seemed like it would be helpful.
I more or less just figured out what was important in the output and figured out a way to directly compare results.
Having actual runtime data seems like it would be more helpful than the projections the kernel analyzer gives you.
-Una
August 12, 2011, 12:18:59 AM
This worked very good got a bigger increase than overclocking 50 mhz which would crash my computer
August 12, 2011, 12:07:56 AM
Diapolo:
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:
Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.
-Una
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:
- Run it for a fixed period of time. Just a couple minutes is fine.
- Open up the csv output in a spreadsheet.
- Average the ALUBusy then the ALUPacking columns.
- Convert the averages from percent to decimal (99.42 to .9942) and multiply them together.
- Multiply that number by the device SP count. (5770=800, 5870=1600, 6950=1400, 6970=1536, etc..)
- Divide by ALUInsts.
Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.
-Una
Not yet, I had the impression that this only works for V++ non Express Editions!? I will take a look now
.Are you skilled to interpret APP Profiler results?
Dia
August 11, 2011, 11:48:41 PM
Diapolo:
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:
Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.
-Una
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:
- Run it for a fixed period of time. Just a couple minutes is fine.
- Open up the csv output in a spreadsheet.
- Average the ALUBusy then the ALUPacking columns.
- Convert the averages from percent to decimal (99.42 to .9942) and multiply them together.
- Multiply that number by the device SP count. (5770=800, 5870=1600, 6950=1400, 6970=1536, etc..)
- Divide by ALUInsts.
Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.
-Una
August 11, 2011, 10:57:08 AM
So far my results are as follows (all other things being equal except for using VECTORS2 instead of VEC TORS on all kernels since 8/4/11):
kernel from SVN 7/25/11: 470MHash/s, approx 0.5% stale shares
Diapolo kernel 8/4/11: 466Mhash/s, didn't run long enough for % stales
Diapolo kernel 8/11/11: 467 Mhash/s, stale test in progress.
All of this is on a 5870.
On a 5850, same remarks as above:
SVN 7/25/11: 381Mhash/s, 0.5% avg stales
Diapolo 8/4/11: not tested
Diapolo 8/11/11: 381Mhash/s, stales in progress.
(edit) after 537 shares on the 5870 and 423 on the 5850, 0% stales on either.
(edit2) around share #580, the 5870 gave me a " Kernel error: Unusual behavior from OpenCL. Hardware problem?" but then continued mining.
(edit3) after 2 1/2 hours:
5870: 932 shares, 10 stales (1.06%)
5850: 758 shares, 14 stale (1.69%)
I am switching back to the kernel from 7/25; on my system I get better performance from it.
kernel from SVN 7/25/11: 470MHash/s, approx 0.5% stale shares
Diapolo kernel 8/4/11: 466Mhash/s, didn't run long enough for % stales
Diapolo kernel 8/11/11: 467 Mhash/s, stale test in progress.
All of this is on a 5870.
On a 5850, same remarks as above:
SVN 7/25/11: 381Mhash/s, 0.5% avg stales
Diapolo 8/4/11: not tested
Diapolo 8/11/11: 381Mhash/s, stales in progress.
(edit) after 537 shares on the 5870 and 423 on the 5850, 0% stales on either.
(edit2) around share #580, the 5870 gave me a " Kernel error: Unusual behavior from OpenCL. Hardware problem?" but then continued mining.
(edit3) after 2 1/2 hours:
5870: 932 shares, 10 stales (1.06%)
5850: 758 shares, 14 stale (1.69%)
I am switching back to the kernel from 7/25; on my system I get better performance from it.
August 11, 2011, 10:40:40 AM
Download version 2011-08-11: http://www.mediafire.com/?s5c7h4r91r4ad4j
New version for your testing pleasure
. Remember to use VECTORS2 as switch!
This one should be a bit faster for 58XX and 69XX cards compared to earlier versions PLUS it should not generate invalid shares, if more than 1 positve nonce is found in a work-group!
If a few of you could make a comparison (with older or other kernel versions) of accepted shares over a certain period of time, this woule be pretty cool!
Dia
New version for your testing pleasure
. Remember to use VECTORS2 as switch!This one should be a bit faster for 58XX and 69XX cards compared to earlier versions PLUS it should not generate invalid shares, if more than 1 positve nonce is found in a work-group!
If a few of you could make a comparison (with older or other kernel versions) of accepted shares over a certain period of time, this woule be pretty cool!
Dia
August 09, 2011, 08:35:48 PM
This is great work and I can't believe I'm just finding it. Thanks!
August 09, 2011, 07:57:14 AM
I can't wait to give this kernel a shot when I get home!
August 09, 2011, 05:19:13 AM
You could try to add http:// in front of user / pass:
Dia
Code:
python phoenix.py -u http://user:pass@pool:8332 -k phatk DEVICE=0 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=12 WORKSIZE=128
Dia
Duh! That works, thanks! However it still doesn't work with BAMT's automatic mine scripts (but this isn't the kernel's problem).
Nonetheless I get 4Mhash/s less with the new kernel compared to the old one on a 5870 (466Mhash/s vs 470Mhash/s, all other things being equal except for using VECTORS2 with the new kernel).
August 09, 2011, 03:57:52 AM
Thanks for this. Only 3 more hashes/s on my 5830, but it allows me to clock it down about 5-10 mhz without losing hashes. This leads to a more stable card! Awesome! 
August 08, 2011, 11:28:52 PM
No, no new .elf file. Last .elf is from 7/28 (the last time I messed with the kernel). Haven't seen any error messages either.
Well it should have created a new .elf for the new kernel ... there seems to be something wrong.
Dia
When I try again after re-downloading the files and converting them to Unix format:
Code:
python phoenix.py -u user:pass@pool:8332 -k phatk DEVICE=0 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=12 WORKSIZE=128
I get the following message:
Code:
Unknown protocol:
FWIW the pool is deepbit. Still no new .elf is created.
You could try to add http:// in front of user / pass:
Code:
python phoenix.py -u http://user:pass@pool:8332 -k phatk DEVICE=0 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=12 WORKSIZE=128
Dia
August 08, 2011, 03:17:46 PM
No, no new .elf file. Last .elf is from 7/28 (the last time I messed with the kernel). Haven't seen any error messages either.
Well it should have created a new .elf for the new kernel ... there seems to be something wrong.
Dia
When I try again after re-downloading the files and converting them to Unix format:
Code:
python phoenix.py -u user:pass@pool:8332 -k phatk DEVICE=0 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=12 WORKSIZE=128
I get the following message:
Code:
Unknown protocol:
FWIW the pool is deepbit. Still no new .elf is created.
August 08, 2011, 02:42:44 PM
Thanks, this topic helped me in the past as well. Keep up the good work.
August 08, 2011, 02:40:27 PM
No, no new .elf file. Last .elf is from 7/28 (the last time I messed with the kernel). Haven't seen any error messages either.
Well it should have created a new .elf for the new kernel ... there seems to be something wrong.
Dia
August 08, 2011, 12:11:34 PM
No, no new .elf file. Last .elf is from 7/28 (the last time I messed with the kernel). Haven't seen any error messages either.
August 08, 2011, 12:07:03 PM
Can't get the new kernel to work at all in Linux (using BAMT) with the phoenix miner. The miner simply refuses to start with the new kernel, even with changed parameters (VECTORS2 instead of VECTORS). I thought at first it's a problem with line endings (DOS vs Unix-style) since the files from mediafire are in DOS format; but even after converting with dos2unix it still won't work. The mioner works perfectly well with the previous version of the kernel.
Did you start Phoenix via sudo the first time because of the OpenCL kernel compilation?
Dia
Yep, started as root.
Did Phoenix create a new .elf file (if that's the case in Linux)? Any output any error message?
Dia
August 08, 2011, 12:02:08 PM
Can't get the new kernel to work at all in Linux (using BAMT) with the phoenix miner. The miner simply refuses to start with the new kernel, even with changed parameters (VECTORS2 instead of VECTORS). I thought at first it's a problem with line endings (DOS vs Unix-style) since the files from mediafire are in DOS format; but even after converting with dos2unix it still won't work. The mioner works perfectly well with the previous version of the kernel.
Did you start Phoenix via sudo the first time because of the OpenCL kernel compilation?
Dia
Yep, started as root.
August 08, 2011, 11:56:05 AM
Can't get the new kernel to work at all in Linux (using BAMT) with the phoenix miner. The miner simply refuses to start with the new kernel, even with changed parameters (VECTORS2 instead of VECTORS). I thought at first it's a problem with line endings (DOS vs Unix-style) since the files from mediafire are in DOS format; but even after converting with dos2unix it still won't work. The mioner works perfectly well with the previous version of the kernel.
Did you start Phoenix via sudo the first time because of the OpenCL kernel compilation?
Dia
August 08, 2011, 11:45:24 AM
Can't get the new kernel to work at all in Linux (using BAMT) with the phoenix miner. The miner simply refuses to start with the new kernel, even with changed parameters (VECTORS2 instead of VECTORS). I thought at first it's a problem with line endings (DOS vs Unix-style) since the files from mediafire are in DOS format; but even after converting with dos2unix it still won't work. The mioner works perfectly well with the previous version of the kernel.
Jump to: