Topic: Drop of hashrate for Polaris cards incoming - page 3. (Read 13939 times)
Time to put cards on the table. Bits be trippin did not come up with a video
so it sounds like we need more info. if amd is backing that its not an issue on their end, then I might feel bad about cancelling a 90 card order in favor of Nvidia. *sigh*
If it is in the hardware, there is nothing AMD can do.
Only what BBT said in the comments of his video.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Quote
Yes, it works fine with SGMiner in Linux, Claymore working with AMD directly to address. Bottom line, SGMiner does not experience the issue.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
As I said, BBT is in over his head. Among other dumb statements in the video, he claimed the issue is because Claymore uses an asm kernel.
There's also nothing special about exchanging emails with AMD devs. Matt, Tom, Alexander, and others are reasonably responsive. What would be impressive is if they can tolerate a mediocre Russian programmer with an ego bigger than his mouth.
Well BBT said AMD claimed to their knowledge, only Claymore was affected. He's also not backing down from the comment he posted earlier.
Quote
Michael Carter4 hours ago
Дмитpий Яцyшкo only way to prove it is to show it right? Tune in tonight
Bits Be Trippin'3 hours ago
SGMiner (Linux) using OpenCL 2.0 does not have the same issue after EPOCH 150+.[/quote]
Дмитpий Яцyшкo only way to prove it is to show it right? Tune in tonight
Bits Be Trippin'3 hours ago
SGMiner (Linux) using OpenCL 2.0 does not have the same issue after EPOCH 150+.[/quote]
Only what BBT said in the comments of his video.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Quote
Yes, it works fine with SGMiner in Linux, Claymore working with AMD directly to address. Bottom line, SGMiner does not experience the issue.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
As I said, BBT is in over his head. Among other dumb statements in the video, he claimed the issue is because Claymore uses an asm kernel.
There's also nothing special about exchanging emails with AMD devs. Matt, Tom, Alexander, and others are reasonably responsive. What would be impressive is if they can tolerate a mediocre Russian programmer with an ego bigger than his mouth.
Only what BBT said in the comments of his video.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Quote
Yes, it works fine with SGMiner in Linux, Claymore working with AMD directly to address. Bottom line, SGMiner does not experience the issue.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Claymore more or less denies
Yes, he asked for someone to send him proof of SGminer woking with a future epoch
https://bitcointalksearch.org/topic/m.19807290
Wolf0 also says SGminer is affected
https://bitcointalksearch.org/topic/genesis-mining-presents-sgminer-gm-now-with-zawawas-gg-updated-17012017-1612329
Only what BBT said in the comments of his video.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Quote
Yes, it works fine with SGMiner in Linux, Claymore working with AMD directly to address. Bottom line, SGMiner does not experience the issue.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Claymore more or less denies
Only what BBT said in the comments of his video.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Quote
Yes, it works fine with SGMiner in Linux, Claymore working with AMD directly to address. Bottom line, SGMiner does not experience the issue.
He also said he was going to do a live stream last night once he was able to confirm whether what he was told about it only affecting Claymore's miner was true, but nothing yet showing any confirmation.
Big news from BBT about the Claymore epoch benchmark issue. He reached out to AMD who confirmed they are aware of the issue and are working with Claymore to resolve the issue which DOES NOT affect other miners, such as SGminer. So, it appears it's an issue related to the Claymore miner and NOT the RX platform.
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
Great news. Any validations done already?
Why are people even worried about this? The current run up in hashrate (from about 20-55TH) is ALL from polaris cards.
I would bet that a significant part of the hashrate climb THIS WEEK has been from NVidia 1060 and 1070 cards.
Prior to that, though, probably mostly Polaris.
Also, keep in mind a lot of folks are using other stuff, like my own R9 290 cards....
On the other hand, I would say it's not a big factor as the LARGE majority of ETH GPUs are probably Polaris and it will even out for those.
I'd be more worried about the Ice Age "block time gets a LOT higher" stuff dropping rewards quite a bit.
How much of the market do you think the Nvidia 1060/1070 make up? Probably less than 10%.
Most large farms are all running RX 470/480 since those GPUs came out about a year ago.
The R9 290/390 Hawaii series is probably in low numbers since it was originally a flagship model and probably sold in much smaller quantites than the RX series.
AS I SAID, "I would say it's not a big factor as the LARGE majority of ETH GPUs are probably Polaris".
Upon reflection though, network hashrate has approximately DOUBLED just in the last month - during which time all RX 470/480/570/580 cards have been in VERY short supply.
Given there was still a lot of stock in the channel of NVidia 1060/1070 cards a month ago, but since those cards are now in just as short of supply as the RX cards coupled with the existing shortage of AMD cards, I believe that the amount of ETH hashrate added by NVidia cards exceeds 30% and likely is an outright majority of the hashrate added in the past month - which would put Nvidia share of TOTAL hashrate at a minimum of 15% and likely over 25%.
I believe the NVidia share of total hashrate that was in place PRIOR to a month ago is very small, likely 2% or LESS.
What farms were building with a year ago - or even 6 months ago - isn't a significant part of the CURRENT ETH network hashrate.
Big news from BBT about the Claymore epoch benchmark issue. He reached out to AMD who confirmed they are aware of the issue and are working with Claymore to resolve the issue which DOES NOT affect other miners, such as SGminer. So, it appears it's an issue related to the Claymore miner and NOT the RX platform.
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
This guy is in over his head.
Why are people even worried about this? The current run up in hashrate (from about 20-55TH) is ALL from polaris cards.
I would bet that a significant part of the hashrate climb THIS WEEK has been from NVidia 1060 and 1070 cards.
Prior to that, though, probably mostly Polaris.
Also, keep in mind a lot of folks are using other stuff, like my own R9 290 cards....
On the other hand, I would say it's not a big factor as the LARGE majority of ETH GPUs are probably Polaris and it will even out for those.
I'd be more worried about the Ice Age "block time gets a LOT higher" stuff dropping rewards quite a bit.
How much of the market do you think the Nvidia 1060/1070 make up? Probably less than 10%.
Most large farms are all running RX 470/480 since those GPUs came out about a year ago.
The R9 290/390 Hawaii series is probably in low numbers since it was originally a flagship model and probably sold in much smaller quantites than the RX series.
Big news from BBT about the Claymore epoch benchmark issue. He reached out to AMD who confirmed they are aware of the issue and are working with Claymore to resolve the issue which DOES NOT affect other miners, such as SGminer. So, it appears it's an issue related to the Claymore miner and NOT the RX platform.
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
https://www.youtube.com/watch?v=l3XOtQtFKSQ&feature=youtu.be&t=978
Why are people even worried about this? The current run up in hashrate (from about 20-55TH) is ALL from polaris cards.
I would bet that a significant part of the hashrate climb THIS WEEK has been from NVidia 1060 and 1070 cards.
Prior to that, though, probably mostly Polaris.
Also, keep in mind a lot of folks are using other stuff, like my own R9 290 cards....
On the other hand, I would say it's not a big factor as the LARGE majority of ETH GPUs are probably Polaris and it will even out for those.
I'd be more worried about the Ice Age "block time gets a LOT higher" stuff dropping rewards quite a bit.
Why are people even worried about this? The current run up in hashrate (from about 20-55TH) is ALL from polaris cards. Therefore the majority of miners are effected by this, which means that the relative distribution of coins among miners wont change.
To put it in simple terms, if everyones cards went from mining 30MH to 1MH overnight, your profitability would remain EXACTLY the same.
To put it in simple terms, if everyones cards went from mining 30MH to 1MH overnight, your profitability would remain EXACTLY the same.
R9 280 can make mining 
R9 280 and 280x are better on ZEC than ETH, and have been that way for a while now.
Polairs (and Tonga) both have 4 channels, with 2 GDDR5 chips per channel, making a total of 8 chips. Each chip does 32-byte burst xfers, so 2 chips provide a single 64-byte cache line. The memory layout switches channels every 256 bytes (4 cache lines).
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/#50401334_pgfId-472173
AMD docs say the cards use a direct-mapped cache, which means TLB thrashing can't be the problem since there is no TLB. It sounds a lot like the Pitcairn performance issues as the memory working set grows beyond 1GB (except the issue starts at 2GB with GCN3 devices). I haven't had much time for coding over the past few months, but hopefully I'll have some time over the summer to figure out what's really going on here.
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/#50401334_pgfId-472173
AMD docs say the cards use a direct-mapped cache, which means TLB thrashing can't be the problem since there is no TLB. It sounds a lot like the Pitcairn performance issues as the memory working set grows beyond 1GB (except the issue starts at 2GB with GCN3 devices). I haven't had much time for coding over the past few months, but hopefully I'll have some time over the summer to figure out what's really going on here.
Could this have anything to do with the memory straps? Maybe with stock straps it doesn't slow down with every new DAG
No, not possible.
Drop of hashrate for Polaris cards incoming
when that happens mine other coins and adjust ... i don't mine ETH much now any way .... I'll buy it from time to time and trade. an i hate trading . and would rather mine what i make ...so pretty much i buy eth if I want any , so it won't brother me ..
ETC might pick up more ...
when that happens mine other coins and adjust ... i don't mine ETH much now any way .... I'll buy it from time to time and trade. an i hate trading . and would rather mine what i make ...so pretty much i buy eth if I want any , so it won't brother me ..
ETC might pick up more ...
Could this have anything to do with the memory straps? Maybe with stock straps it doesn't slow down with every new DAG
LOL )) funny but I see such sentences not for a first time.
No, std straps won't help you. )))
Moreover, even Hawaii - now top performer - will go to 17mhs on epoch 333 ))
... it seems you all don´t get it:
You can´t escape the difficulty bomb !
Do your own research or cry later !
You can´t escape the difficulty bomb !
Do your own research or cry later !
This has nothing to do with the diff bomb. This has to do with the hardware architecture of the cards. The reason it started now is because DAG size is over 2GB. In a simplified manner, you could see it as part of DAG now physically ending up on a different IC. This causes the memory controller to switch the IC it reads from more often. The larger the DAG, the bigger the part of the DAG that ends up on a different IC, the more switching it has to do.
Polairs (and Tonga) both have 4 channels, with 2 GDDR5 chips per channel, making a total of 8 chips. Each chip does 32-byte burst xfers, so 2 chips provide a single 64-byte cache line. The memory layout switches channels every 256 bytes (4 cache lines).
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/#50401334_pgfId-472173
AMD docs say the cards use a direct-mapped cache, which means TLB thrashing can't be the problem since there is no TLB. It sounds a lot like the Pitcairn performance issues as the memory working set grows beyond 1GB (except the issue starts at 2GB with GCN3 devices). I haven't had much time for coding over the past few months, but hopefully I'll have some time over the summer to figure out what's really going on here.
Could this have anything to do with the memory straps? Maybe with stock straps it doesn't slow down with every new DAG
... it seems you all don´t get it:
You can´t escape the difficulty bomb !
Do your own research or cry later !
You can´t escape the difficulty bomb !
Do your own research or cry later !
This has nothing to do with the diff bomb. This has to do with the hardware architecture of the cards. The reason it started now is because DAG size is over 2GB. In a simplified manner, you could see it as part of DAG now physically ending up on a different IC. This causes the memory controller to switch the IC it reads from more often. The larger the DAG, the bigger the part of the DAG that ends up on a different IC, the more switching it has to do.
Polairs (and Tonga) both have 4 channels, with 2 GDDR5 chips per channel, making a total of 8 chips. Each chip does 32-byte burst xfers, so 2 chips provide a single 64-byte cache line. The memory layout switches channels every 256 bytes (4 cache lines).
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/#50401334_pgfId-472173
AMD docs say the cards use a direct-mapped cache, which means TLB thrashing can't be the problem since there is no TLB. It sounds a lot like the Pitcairn performance issues as the memory working set grows beyond 1GB (except the issue starts at 2GB with GCN3 devices). I haven't had much time for coding over the past few months, but hopefully I'll have some time over the summer to figure out what's really going on here.
Jump to: