citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 03:44:51 AM |
|
Great work! Any improvements about XMR in pre3?
Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR. While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited. You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7. Even with 2% fee it gives about 5-10% more speed on 280X. on my 290x GG is 15% faster, on my RX470 not much faster but it's faster. But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best ) Claymore v9.7 is best for non-RX cards (290s/390s/R9 cards). He needs to further optimise the miner for RX/Polaris (long time overdue). For RX cards, Wolf's XMR miner and sgminer-gm, sgminer-gg will be a better and more stable miner.
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
Sam123
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 04:44:02 AM |
|
Great work! Any improvements about XMR in pre3?
Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR. While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited. You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7. Even with 2% fee it gives about 5-10% more speed on 280X. on my 290x GG is 15% faster, on my RX470 not much faster but it's faster. But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best ) Claymore v9.7 is best for non-RX cards (290s/390s/R9 cards). He needs to further optimise the miner for RX/Polaris (long time overdue). For RX cards, Wolf's XMR miner and sgminer-gm, sgminer-gg will be a better and more stable miner. Can you please share the link for the Wolf XMR miner (RX480 cards) Thanks
|
|
|
|
laik2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 06:28:35 AM |
|
Great work! Any improvements about XMR in pre3?
Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR. While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited. You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7. Even with 2% fee it gives about 5-10% more speed on 280X. on my 290x GG is 15% faster, on my RX470 not much faster but it's faster. But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best ) It's the fastest open source miner, I repeat - OPEN SOURCE ! As of your statement that Claymore's CryptoNote miner is the fastest - your are absolutely wrong, sgminer-gm/gg are still faster ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 06:36:40 AM |
|
I am not going to join this "Who got the fastest miner?" discussion. Project GG's slogan is: "The best miner should be free." I mean, Bitcoin founder Satoshi Nakamoto was so generous. Why shouldn't we?
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
Ursul0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 08:37:37 AM |
|
getting closer... ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fs10.postimg.org%2Fnkgj114eh%2Fzec_zpr3_clay12_2.png&t=665&c=hZo6N_3Nql5bPg) EDIT: actually two of the cards just went SICK after 5 minutes, while Claymore works for days with no issues
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 01:49:54 PM |
|
Using SLC or GLC memory read/write may also give a small performance boost. Could you elaborate on this? I recall you said Wolf was using them for his private miner, but I am not entirely sure how to use SLC/GLC bits for performance enhancements. The SLC (System Level Coherence) bit forces bypassing the L1 cache, and GLC (Global Level Coherence) forces bypassing the L2. For ETH mining, which is 100% memory reads, I think SLC gave a performance improvement, but GLC did not. The results weren't completely intuitive, so you'll probably have to do some experimenting. I also suspect you may get different results from different GCN versions. Pitcairn and Tahiti seem to have a brain-dead cache controller that gets slower as the working set gets much over 1GB. Therefore I think GLC read/write may have a more significant impact for them vs Tonga (or even Hawaii).
|
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 05:01:36 PM |
|
EDIT: actually two of the cards just went SICK after 5 minutes, while Claymore works for days with no issues
That must be a hardware issue. Different miners tend to expose different hardware problems. Also, for optimal performance with Ellesmere, you need to run the miner on Linux for now. I think the only real technical advantage Claymore has over me is that he figured out how to access the entire GDS both on Windows and Linux.
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 05:07:36 PM |
|
Using SLC or GLC memory read/write may also give a small performance boost. Could you elaborate on this? I recall you said Wolf was using them for his private miner, but I am not entirely sure how to use SLC/GLC bits for performance enhancements. The SLC (System Level Coherence) bit forces bypassing the L1 cache, and GLC (Global Level Coherence) forces bypassing the L2. For ETH mining, which is 100% memory reads, I think SLC gave a performance improvement, but GLC did not. The results weren't completely intuitive, so you'll probably have to do some experimenting. I also suspect you may get different results from different GCN versions. Pitcairn and Tahiti seem to have a brain-dead cache controller that gets slower as the working set gets much over 1GB. Therefore I think GLC read/write may have a more significant impact for them vs Tonga (or even Hawaii). Thanks for the clarification. Yeah, these features definitely make more sense for access to ETH's huge DAG. Let's see what I can do with them for ZEC...
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2017, 06:23:14 PM |
|
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 07:10:23 AM Last edit: March 16, 2017, 09:50:33 PM by zawawa |
|
I just patched the Linux kernel as an experiment: if (1 /*gds*/) { p->job->gds_base = 0; // amdgpu_bo_gpu_offset(gds); p->job->gds_size = 65536; // amdgpu_bo_size(gds); }
This may actually work...
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
john1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 10:02:52 AM |
|
How many hash it will produce on ethereum usage? thanks
|
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 09:44:57 PM |
|
How many hash it will produce on ethereum usage? thanks
About 10% lower than Claymore's. You should try it yourself.
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 09:52:19 PM |
|
THE KERNEL PATCH IS WORKING!! WHOO HOO!!!!
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 17, 2017, 04:20:23 AM |
|
Well, it turned out that multithreading wasn't working, so I'm still working on the kernel patch. The miner is running about 15% faster with a single thread, so it's very promising. I should be able to get rid of the patch entirely by hooking system calls to the driver later. This is no easy stuff!
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
zawawa (OP)
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 728
Merit: 304
Miner Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 17, 2017, 09:07:54 AM |
|
It seems that the real maximum size of GDS segments for RX 480 is 16KB. It's a little disappointing, but still much better than 4KB without the kernel patch. This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way. Now let me fix the kernel patch one more time...
|
Gateless Gate Sharp, an open-source ETH/XMR miner: http://bit.ly/2rJ2x4VBTC: 1BHwDWVerUTiKxhHPf2ubqKKiBMiKQGomZ
|
|
|
doktor83
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 17, 2017, 09:41:04 AM |
|
so good to see how much you love doing this zawawa ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 17, 2017, 01:03:04 PM |
|
It seems that the real maximum size of GDS segments for RX 480 is 16KB. It's a little disappointing, but still much better than 4KB without the kernel patch. This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way. Now let me fix the kernel patch one more time...
Or maybe Optiminer runs just 2 instances of the kernel and uses only half of the GDS. It's possible (I'd even say probable) the benefits of using a full 64KB is offset by slower GDS access caused by contention with 4 instances of the kernel running.
|
|
|
|
jstefanop
Legendary
Offline
Activity: 2151
Merit: 1399
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 17, 2017, 04:49:04 PM |
|
It seems that the real maximum size of GDS segments for RX 480 is 16KB. It's a little disappointing, but still much better than 4KB without the kernel patch. This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way. Now let me fix the kernel patch one more time...
Or maybe Optiminer runs just 2 instances of the kernel and uses only half of the GDS. It's possible (I'd even say probable) the benefits of using a full 64KB is offset by slower GDS access caused by contention with 4 instances of the kernel running. Pretty sure both optiminer and claymore running two kernel threads.
|
|
|
|
|