Thank you so much Vince. Your patch gives very nice performance for the HD 6870 cards I have, I sent a little something your way too.
Keep up the the good work guys, you are awesome.
Topic: further improved phatk_dia kernel for Phoenix + SDK 2.6 - 2012-01-13 - page 11. (Read 106928 times)
July 20, 2011, 12:38:54 AM
July 20, 2011, 12:13:15 AM
To above posters, AOCLBF with Phoenix will solve your backup pool problems.
But I'm using linux.
Im using linux too and dont want a GUI. I manage my mining rig through ssh.
July 19, 2011, 02:56:10 PM
Latest poclbm from github made some tasks asynchronous and should bring it up to par with phoenix now as well.
That's really not the same. It's also more hassle. I use poclbm b/c it's just as fast as phoenix has better display and has backup pool.
Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?
That's really not the same. It's also more hassle. I use poclbm b/c it's just as fast as phoenix has better display and has backup pool.
July 19, 2011, 02:23:18 PM
To above posters, AOCLBF with Phoenix will solve your backup pool problems.
But I'm using linux.
July 19, 2011, 02:11:49 PM
To above posters, AOCLBF with Phoenix will solve your backup pool problems.
edit: Forgot about the linux peeps, just shows how much of a WinBlows nab I am. Pardon me good folks.
edit: Forgot about the linux peeps, just shows how much of a WinBlows nab I am. Pardon me good folks.
July 19, 2011, 01:27:27 PM
Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?
That's really not the same. It's also more hassle. I use poclbm b/c it's just as fast as phoenix has better display and has backup pool.
July 19, 2011, 01:08:00 PM
Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.
Backup pools. Its a big plus (and peace of mind).
Also, for me poclmb is slightly faster than phoenix with the same kernel.
Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?
I tried this (I was a phoenix user until poclbm added backup pools), but the second miner would take some hashing power from the main one (big deal), and then if the main one went down it would not perform at full speed because the aggression was lower.
July 19, 2011, 11:43:58 AM
Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.
Backup pools. Its a big plus (and peace of mind).
Also, for me poclmb is slightly faster than phoenix with the same kernel.
Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?
July 19, 2011, 11:21:30 AM
Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.
Backup pools. Its a big plus (and peace of mind).
Also, for me poclmb is slightly faster than phoenix with the same kernel.
July 19, 2011, 11:11:45 AM
Can you make another version that includes all the recent changes and __init__.py does not need to changed?
thanks
thanks
Why? Just unzip in the kernels/phatk/ directory.
Main reason is some people like to use this kernel with poclbm. The 7-11 works, but the newest doesn't because it requires changes in __init__.py which is specific to phoenix. BOARBEAR is asking for a version that includes all the additional improvements since 7-11 that doesn't require any changes to __init__.py.
It is impossible to create a version of this kernel that works without modifications in the main miner software. As I wrote, there are values and variables, that the kernel uses and which are precalculated in the miner software and then passed as parameters to the kernel. A miner, which doesn't pass the required parameters will not work without beeing modified, sorry.
You guys are free to mod the kernel for yourself to revert the changes, which require a modded miner software and only take the ones, which can work without.
Dia
Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.
July 19, 2011, 12:37:38 AM
Can you make another version that includes all the recent changes and __init__.py does not need to changed?
thanks
thanks
Why? Just unzip in the kernels/phatk/ directory.
Main reason is some people like to use this kernel with poclbm. The 7-11 works, but the newest doesn't because it requires changes in __init__.py which is specific to phoenix. BOARBEAR is asking for a version that includes all the additional improvements since 7-11 that doesn't require any changes to __init__.py.
It is impossible to create a version of this kernel that works without modifications in the main miner software. As I wrote, there are values and variables, that the kernel uses and which are precalculated in the miner software and then passed as parameters to the kernel. A miner, which doesn't pass the required parameters will not work without beeing modified, sorry.
You guys are free to mod the kernel for yourself to revert the changes, which require a modded miner software and only take the ones, which can work without.
Dia
What I do here is just hobby and I don't want it to take even more time, I hope you understand that. I can't maintain 2 different kernel versions, sorry.
Dia
July 18, 2011, 11:10:23 PM
Can you make another version that includes all the recent changes and __init__.py does not need to changed?
thanks
thanks
Why? Just unzip in the kernels/phatk/ directory.
Main reason is some people like to use this kernel with poclbm. The 7-11 works, but the newest doesn't because it requires changes in __init__.py which is specific to phoenix. BOARBEAR is asking for a version that includes all the additional improvements since 7-11 that doesn't require any changes to __init__.py.
It is impossible to create a version of this kernel that works without modifications in the main miner software. As I wrote, there are values and variables, that the kernel uses and which are precalculated in the miner software and then passed as parameters to the kernel. A miner, which doesn't pass the required parameters will not work without beeing modified, sorry.
You guys are free to mod the kernel for yourself to revert the changes, which require a modded miner software and only take the ones, which can work without.
Dia
July 18, 2011, 08:25:44 PM
my stales are at / shares 4234 / stale (7, 0.17%) / after the latest version using AOCLBF on 2 5850's one running at 840/300 and 1000/300 the latter is because of getting a card with a crappy part number from sapphire
July 18, 2011, 04:23:29 PM
I think I jumped the gun. I believe I am having a real hardware problem. It's only on one card, the hotter one of the group, and it's overclocked and over-volted to all hell. I think what happened is that these errors were hidden from the console until this new kernel update! If that's the case, kudos for making the errors work! haha.
Not necessarely. I had the same problem with a card in previous versions of the kernel. After 20 minutes it would produce that message in phoenix or would crash poclbm. But with exactly the same configuration and later kernels it was solved, even when it was producing higher hashing rates. I am not sure why it happens exactly.
July 18, 2011, 02:08:31 PM
I think I jumped the gun. I believe I am having a real hardware problem. It's only on one card, the hotter one of the group, and it's overclocked and over-volted to all hell. I think what happened is that these errors were hidden from the console until this new kernel update! If that's the case, kudos for making the errors work! haha.
July 18, 2011, 12:42:53 PM
I'm on Linux and I'm still able to get these error messages, even with earlier versions of the phatk patch from this thread. For me they start happening if my clocks are too high and become more frequenty as I increase the clocks.
For my 5850 at stock volts, 1015MHz doesn't generate any errors and with 1020 MHz they are very occasional but become more frequent as I ramp up to 1035MHz (my card always freezes at 1040MHz).
When I overvolted my 5850 to 1.25V and took it to 1110 MHz for 3 hours I got a few but noticed that I was generating good shares with the same OpenCL work request as was throwing errors so it seems the error doesn't invalidate the whole second and likely just a very small portion of it. I have a screenshot here.
At lower voltages I never see these errors. Either the card runs error free or crashes and the MHz line dividing these two states is pretty fine in my experience.
It's interesting that the kernel version might affect the frequency of such errors but they don't bother me.
Thanks for this latest kernel patch Diapolo. My clock rates increased by 0.3 MH/s each. 2x5850: 722.2 MH/s -> 722.8 MH/s. I'll send another small tip.
For my 5850 at stock volts, 1015MHz doesn't generate any errors and with 1020 MHz they are very occasional but become more frequent as I ramp up to 1035MHz (my card always freezes at 1040MHz).
When I overvolted my 5850 to 1.25V and took it to 1110 MHz for 3 hours I got a few but noticed that I was generating good shares with the same OpenCL work request as was throwing errors so it seems the error doesn't invalidate the whole second and likely just a very small portion of it. I have a screenshot here.
At lower voltages I never see these errors. Either the card runs error free or crashes and the MHz line dividing these two states is pretty fine in my experience.
It's interesting that the kernel version might affect the frequency of such errors but they don't bother me.
Thanks for this latest kernel patch Diapolo. My clock rates increased by 0.3 MH/s each. 2x5850: 722.2 MH/s -> 722.8 MH/s. I'll send another small tip.
Very nice posting with relevant information to all who encounter this error. Thanks for sharing
. I never had this error, because my 5830 clocks were (and are) never above 1000 MHz for the chip, so it seems logical to me.Dia
July 18, 2011, 10:17:51 AM
I'm on Linux and I'm still able to get these error messages, even with earlier versions of the phatk patch from this thread. For me they start happening if my clocks are too high and become more frequenty as I increase the clocks.
For my 5850 at stock volts, 1015MHz doesn't generate any errors and with 1020 MHz they are very occasional but become more frequent as I ramp up to 1035MHz (my card always freezes at 1040MHz).
When I overvolted my 5850 to 1.25V and took it to 1110 MHz for 3 hours I got a few but noticed that I was generating good shares with the same OpenCL work request as was throwing errors so it seems the error doesn't invalidate the whole second and likely just a very small portion of it. I have a screenshot here.
At lower voltages I never see these errors. Either the card runs error free or crashes and the MHz line dividing these two states is pretty fine in my experience.
It's interesting that the kernel version might affect the frequency of such errors but they don't bother me.
Thanks for this latest kernel patch Diapolo. My clock rates increased by 0.3 MH/s each. 2x5850: 722.2 MH/s -> 722.8 MH/s. I'll send another small tip.
For my 5850 at stock volts, 1015MHz doesn't generate any errors and with 1020 MHz they are very occasional but become more frequent as I ramp up to 1035MHz (my card always freezes at 1040MHz).
When I overvolted my 5850 to 1.25V and took it to 1110 MHz for 3 hours I got a few but noticed that I was generating good shares with the same OpenCL work request as was throwing errors so it seems the error doesn't invalidate the whole second and likely just a very small portion of it. I have a screenshot here.
At lower voltages I never see these errors. Either the card runs error free or crashes and the MHz line dividing these two states is pretty fine in my experience.
It's interesting that the kernel version might affect the frequency of such errors but they don't bother me.
Thanks for this latest kernel patch Diapolo. My clock rates increased by 0.3 MH/s each. 2x5850: 722.2 MH/s -> 722.8 MH/s. I'll send another small tip.
July 18, 2011, 10:15:25 AM
New version 2011-07-17 getting a lot of:
Code:
2011-07-18 01:24:09: Listener for "bitcoinmonkey": [18/07/2011 01:24:09] Kernel error: Unusual behavior from OpenCL. Hardware problem?
I had the same issue on my 5850, but when I took 5Mhz off my overclock the error went away, guessing it was picking up some errors from being pushed harder?
July 18, 2011, 09:34:20 AM
I get lots of 'unusual opencl behavior. hardware problem?' on the latest version, using a fresh Catalyst 11.6 driver (not CPU buggy hotfix) on WinXP on two different miners, going back to stock phoenix and 07-11 kernel is fine.
I had the same issue under windows which magically went away when I switched to Linux.
July 18, 2011, 04:03:54 AM
Yes I copied over the init file, because without it it won't even run. Windows 7 64-bit, Catalyst 11.5, Stream 2.4. Haven't had this message pop up with any other version of phatk kernel, nor any other kernel for that matter.
Jump to: