Pages:
Author

Topic: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux) - page 84. (Read 6590565 times)

sr. member
Activity: 1484
Merit: 253
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.
Why do you prefer Claymore? It is slower than PM on any GPU. It takes twice more devfee. Consumes less or equal power. What is more important than these three facts? Your emotional affection? Are you a female?

WHAT THE HELL DOES IT MATTER AND WHAT IS IT TO YOU???
Mind your own business. If I like Coke over Pepsi, I'll drink Coke. If I like mustard on my hot dog, I'll take mustard on it. Last I knew I needn't explain my preferences or loyalty.
I don't give a shit who or what you like, do I?
What does my GENDER have to do with anything? Are you wanting to fucking ask me out? Will you try to date rape me or some shit? Fuck off!

This loss of control obviously shows what your gender is. Don't worry! I date only normal female.

You don't know shit. Mind your own business and stay on topic.
But he right about PM. And here is only positives - less fee, faster speed, equal or less power with him...
member
Activity: 180
Merit: 10
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.
Why do you prefer Claymore? It is slower than PM on any GPU. It takes twice more devfee. Consumes less or equal power. What is more important than these three facts? Your emotional affection? Are you a female?

WHAT THE HELL DOES IT MATTER AND WHAT IS IT TO YOU???
Mind your own business. If I like Coke over Pepsi, I'll drink Coke. If I like mustard on my hot dog, I'll take mustard on it. Last I knew I needn't explain my preferences or loyalty.
I don't give a shit who or what you like, do I?
What does my GENDER have to do with anything? Are you wanting to fucking ask me out? Will you try to date rape me or some shit? Fuck off!

This loss of control obviously shows what your gender is. Don't worry! I date only normal female.

You don't know shit. Mind your own business and stay on topic.
member
Activity: 180
Merit: 10
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.
Why do you prefer Claymore? It is slower than PM on any GPU. It takes twice more devfee. Consumes less or equal power. What is more important than these three facts? Your emotional affection? Are you a female?

WHAT THE HELL DOES IT MATTER AND WHAT IS IT TO YOU???
Mind your own business. If I like Coke over Pepsi, I'll drink Coke. If I like mustard on my hot dog, I'll take mustard on it. Last I knew I needn't explain my preferences or loyalty.
I don't give a shit who or what you like, do I?
What does my GENDER have to do with anything? Are you wanting to fucking ask me out? Will you try to date rape me or some shit? Fuck off!
legendary
Activity: 1899
Merit: 1024
I try to send API call to claymore to disable all GPU but nothing happens, I set  -mpsw xxx, and I try with telnet:

{"id":0,"jsonrpc":"2.0", "psw":"xxx", "method":"control_gpu", "params":[-1, 0]}
member
Activity: 220
Merit: 12
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.
Why do you prefer Claymore? It is slower than PM on any GPU. It takes twice more devfee. Consumes less or equal power. What is more important than these three facts? Your emotional affection? Are you a female?
member
Activity: 180
Merit: 10
What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.

Well, the faster he can make his miner, the more dev fee he will collect. So yeah, I think optimizing the kernel would be worth it to him.

I hope so.

So... I let this run for exactly 5 hours and 19 minutes.
Three XFX 5700 XT cards.
Accepted 318, Rejected 0, HW Errors 0
Averaging 52 MH/s for 156 MH/s combined and 277w combined (92w - 94w each)

This is my setting for PhoenixMiner:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -clKernel 1 -clNew 1

You have to admit that these are very solid, stable and promising. Results of 52MH/s for 92w is 0.56MH/s per watt seems pretty efficient. Ideally I'd love to have a 500+MH/s Ethereum mining rig on a 1,000w PSU and I believe that it's achievable with these cards.
jr. member
Activity: 78
Merit: 3
What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.

Well, the faster he can make his miner, the more dev fee he will collect. So yeah, I think optimizing the kernel would be worth it to him.
member
Activity: 180
Merit: 10
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?

I've removed the "-openclLocalWork 64" completely and I'm averaging 52 instead of 49.5 with ZERO errors or incorrect shares. PhoenixMiner says that the new kernel is included in the latest version. IF the developers coordinate and assist each other instead of competing against each other more can be accomplished. Granted I don't know if they do share tips with each other. Anyway, I still prefer Claymore... but so far Phoenix yields better results after this update. Not sure how he did it but it is an improvement nonetheless. I hope he can figure something out (and I'm sure he will) because I prefer Claymore.
member
Activity: 220
Merit: 12
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
Claymore has already released his version with Navi support. Quoting Claymore:
-----------------------------------------------------
v15.0:

- now miner supports up to #384 epoch (4GB DAG size). Note that previous versions support up to #299 epoch, you will not be able to use old versions after #299 epoch.
- added support for Navi cards (ETH-only mode).
- now miner sets environment variables automatically (required for 4GB AMD cards).
- a few minor bug fixes and improvements.

PS. AMD still has no public Navi drivers with DAG-fix, so currently 5700XT shows a very bad hashrate. But AMD already solved this issue and they promise to release public drivers soon...
-----------------------------------------------------

What else do you expect from him, to start walking on water like Jesus did?
member
Activity: 180
Merit: 10
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.

All of my incorrect shares were from the same GPU (I have three) so it's possible that it's just my XFX GPU since it's also the GPU that won't let me clock past 900Mhz without the watchdog error. Thinking of returning it.

But from 49.5 to 57 seems like an improvement to me. Once Claymore releases some Navi kernels for his software then we'll be in business for sure.
jr. member
Activity: 78
Merit: 3
So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.

Yeah, sure. I tried all the settings you just did, and every time, the % gain was almost exactly offset by % invalid shares. However, I did not run very long tests, so it could be possible that pool-side effective hashrate might go up even with the incorrect shares, but I doubt it.
member
Activity: 180
Merit: 10
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 128 causes incorrect shares.

I'm trying this:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -gt 100 -clKernel 3 -clNew 1 -openclLocalWork 64

And it's pretty solid. I'm only getting 56.6 though. No incorrect shares.

..for now. You are a great optimist.

As stated, it still needs some tweaking but it's progress!
I'm keeping it with these settings for now. Only 1 incorrect share out of 22 so far.

So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.

You mean a 10% gain?
50MH/s increased to 55MH/s is 10%. But I get your point.
jr. member
Activity: 78
Merit: 3
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 128 causes incorrect shares.

I'm trying this:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -gt 100 -clKernel 3 -clNew 1 -openclLocalWork 64

And it's pretty solid. I'm only getting 56.6 though. No incorrect shares.

..for now. You are a great optimist.

As stated, it still needs some tweaking but it's progress!
I'm keeping it with these settings for now. Only 1 incorrect share out of 22 so far.

So you have a 5% speed gain, but losing 5% to incorrect shares.... seems like a wash to me. Until the kernels are written for that worksize (if it's even possible), seems like using the default settings is the best way to go.
member
Activity: 180
Merit: 10
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 128 causes incorrect shares.

I'm trying this:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -gt 100 -clKernel 3 -clNew 1 -openclLocalWork 64

And it's pretty solid. I'm only getting 56.6 though. No incorrect shares.

..for now. You are a great optimist.

As stated, it still needs some tweaking but it's progress!
I'm keeping it with these settings for now. Only 1 incorrect share out of 22 so far.
member
Activity: 220
Merit: 12
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 128 causes incorrect shares.

I'm trying this:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -gt 100 -clKernel 3 -clNew 1 -openclLocalWork 64

And it's pretty solid. I'm only getting 56.6 though. No incorrect shares.

..for now. You are a great optimist.
member
Activity: 180
Merit: 10
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 128 causes incorrect shares.

I'm trying this:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -gt 100 -clKernel 3 -clNew 1 -openclLocalWork 64

And it's pretty solid. I'm only getting 56.6 though. No incorrect shares.
member
Activity: 220
Merit: 12
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!
It seems to me that PM is optimized especially for 32 threads per work group and doesn't work correctly for more. So I think that this 60 MH/s is fake and that your -openclLocalWork 64/128 causes incorrect shares.
member
Activity: 180
Merit: 10
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!

I'm getting incorrect shares with those settings... and not just a couple.

Yeah, I got a lot too. About 30%.
I'm trying this now:
-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -mode 1 -clKernel 3 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

I removed the -gt and hope that clears up a bit. Seems like it needs some tuning still but it's progress!


-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -clKernel 3 -clNew 1 -openclLocalWork 64
Seems much better. It's been running for about 4 minutes and no incorrect shares (yet).
jr. member
Activity: 78
Merit: 3
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!

I'm getting incorrect shares with those settings... and not just a couple.
member
Activity: 180
Merit: 10
Well... I hate to say this... but I'm getting 60MH/s using PhoenixMiner 4.6c now.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -acm -mi 12 -gt 126 -mode 1 -clKernel 1 -clNew 1 -clf 0 -lidag 1 -openclLocalWork 128 -openclGlobalMultiplier 4096

~95 watts per card and 59C.

I like it a lot!

(Credit to PedPandaMining)
Pages:
Jump to: