Hi! Now we can open the v2.84 in Windows 10 but.... I Have a lot of problems saving the BIOS and can not write any Modded bios...  It always says "Error reading from ROM"... I change Risers, change GPU.. and still the same problem with my RX570 8GB Micron memory. Any can help ?? Thanks a lot!! RX 580 8Gb hynix flashing modded bios normal without errors... |
|
|
|
Does anyone can use high intensiity 100-110+ on 1.6.1 CN-v7 algo without speed drops?
No one tries CN-v7 on 1.6.1. on 8Gb cards? With intensity higher 100-110? I use 118 intensity dual threads on 8gb cards CN-V7 I'm talking about 1.6.1 version. You post screen from 1.6.0. On 1.6.0 I can use 110+ intensity with 2 threds without problems too. But on 1.6.1 I have speed drops to 0 if intensity higher 99. I also feel there is some changes for intensity in CN-V7, normally with previous version my intensity 72 got stable hash rate, now with 1.6.1 got up and down hash rate. Intensity 72 in 1.6.1 is especcial!!! It got speed to jump down to 875 and up to 1250. But average is still 925. On 1.6.0 with intensity 108 I has 985 on this card. But on 1.6.1 with intensity 108 I have speed 980 and drops to 0 so average speed is 600-700... |
|
|
|
|
New version will allow to run several instances? If I want to mine on CPU other olgo than on GPU...
|
|
|
|
Does anyone can use high intensiity 100-110+ on 1.6.1 CN-v7 algo without speed drops?
No one tries CN-v7 on 1.6.1. on 8Gb cards? With intensity higher 100-110? I use 118 intensity dual threads on 8gb cards CN-V7 I'm talking about 1.6.1 version. You post screen from 1.6.0. On 1.6.0 I can use 110+ intensity with 2 threds without problems too. But on 1.6.1 I have speed drops to 0 if intensity higher 99. |
|
|
|
The Ethash kernel for GCN3 is done.
Theoretically spraking, it cannot get any faster than as it is now with four active wavefronts
per CU.
I am sick of kooking at Ethash, though...
and what sort of improvements do you see? 33-35 H/s is what should be an excellent achievement. Maybe you wanted to say 33-35 MH/s? |
|
|
|
Does anyone can use high intensiity 100-110+ on 1.6.1 CN-v7 algo without speed drops?
No one tries CN-v7 on 1.6.1. on 8Gb cards? With intensity higher 100-100? no because we use 2 threads and 54-56 intensity on 580 8g Not heavy? On normal CN v7? And what speed? |
|
|
|
Does anyone can use high intensiity 100-110+ on 1.6.1 CN-v7 algo without speed drops?
No one tries CN-v7 on 1.6.1. on 8Gb cards? With intensity higher 100-100? |
|
|
|
i was testing an optim on cn-heavy than gave negligible perf increase. then i backtested on previous algos and gpu to look for regression.
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
It's good news... I waiting to test it... |
|
|
|
|
Does anyone can use high intensiity 100-110+ on 1.6.1 CN-v7 algo without speed drops?
|
|
|
|
Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166
1.5.9 and 1.6.0 always creates kernels with chunk 0...
Is there is some dependences? What max it can be? What best?
In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2
thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy  you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards Not every time. It's still needs to restarts miner several times. But max speed can be achieved. About fragments - you mean that way: { "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678}, And will it work for 1.6.1 ? yes, exactly that's how you can use it. Hmmm... Thanks I'll try it. Last question: does it means that with this parameter no matter what chunk size in kernel file? it creates a new kernel file with the fragment value you defined Thanks! I can build kernel with fragments 1873279048 and 1.6.1 gives the same speed as 1.6.0 with 1.5.8 kernel. Now we can build kernels with any chunk (fragments) size. But I think you must determine why it's happens. I tried fragments 1396800320 and less step by 43650010, but always not get max speed... Also tried variants 3, 4, 512, 1024, 4096, 4096000, 87654321, 12345678 and some more. Every time waits about 10 min. |
|
|
|
Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166
1.5.9 and 1.6.0 always creates kernels with chunk 0...
Is there is some dependences? What max it can be? What best?
In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2
thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards Not every time. It's still needs to restarts miner several times. But max speed can be achieved. About fragments - you mean that way: { "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678}, And will it work for 1.6.1 ? yes, exactly that's how you can use it. Hmmm... Thanks I'll try it. Last question: does it means that with this parameter no matter what chunk size in kernel file? |
|
|
|
Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166
1.5.9 and 1.6.0 always creates kernels with chunk 0...
Is there is some dependences? What max it can be? What best?
In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2
thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards Not every time. It's still needs to restarts miner several times. But max speed can be achieved. About fragments - you mean that way: { "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678}, And will it work for 1.6.1 ? |
|
|
|
|
Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166
1.5.9 and 1.6.0 always creates kernels with chunk 0...
Is there is some dependences? What max it can be? What best?
In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2
|
|
|
|
Maked many tries with 1.6.1 version on 580 cards heavy algo. Max I can get is about 10 h/s less than 1.6.0 with kernel created by 1.5.8 and the same speed as 1.6.0 with kernel created by 1.6.0.
The problem is in creating kernels. 1.5.8 makes kernel files every miner launch. And some of them was not good, but some - Excellent!
1.5.9, 1.6.0 and 1.6.1 can't make fastest kernel...
Normal v7 can't get any close result as 1.6.0 even with the kernel created by 1.6.0. In 1.6.1 intensity higher 100 couses speed to jump up and down, looks like new v7 kernel in 1.6.1 requires more video memory that's why 8Gb now not enough for optimal intensity for 8Gb 112-118.
you need to stop pushing the h key , and start looking at an average value of minimum 5 min, better 30 min. 1.6.1 does not require more vram. I waits up to 10 minutes every try. Max speed lower about 10 h/s than 1.6.0 with kernel from 1.5.8. Speed lower only with good kernel from 1.5.8. With kernel created by 1.6.0 speed on heavy with 1.6.1 and 1.6.0 is equal. This means that 1.5.8 can build better kernels than 1.6.0 and 1.6.1. But 1.6.1 can't work with old kernels... And miner on CN-v7 didn't give stable speed on intensity 100+ like 1.6.0. Thats causes speed drop with intensity 112-118. 1.6.0 woks perfect with 112-118 intensity on 580 8Gb cards. |
|
|
|
GPU version done.
Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
Heavy needed twice amount of video memory. And intensity usual twice less than in CN v7. On 4Gb 270X max speed on CN-v7 with Claymore 11.3 - 550 h/s (manual modded bios). Intensity 460 (-h 460 -dmem 1) Heavy on SRB Miner with 26-27 intensity got 400-420 h/s and many HW errors. Heavy very strange algo... On RX 580 8Gb heavy gives about 10% more speed than CN-v7. But on 4Gb cards heavy gives less speed. Looks like heavy can give the same or even better speed only with 8Gb+ cards. |
|
|
|
|
Maked many tries with 1.6.1 version on 580 cards heavy algo. Max I can get is about 10 h/s less than 1.6.0 with kernel created by 1.5.8 and the same speed as 1.6.0 with kernel created by 1.6.0.
The problem is in creating kernels. 1.5.8 makes kernel files every miner launch. And some of them was not good, but some - Excellent!
1.5.9, 1.6.0 and 1.6.1 can't make fastest kernel...
Normal v7 can't get any close result as 1.6.0 even with the kernel created by 1.6.0. In 1.6.1 intensity higher 100 couses speed to jump up and down, looks like new v7 kernel in 1.6.1 requires more video memory that's why 8Gb now not enough for optimal intensity for 8Gb 112-118.
|
|
|
|
When I try the latest version on an AMD Epyc (basically four Ryzen dice on a package) I get the following error: Thread 30 successfully bound to CPU 30 Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 30 of NUMA node 3 at: 0000021b3c200000 Starting CPU Mining thread 31, affinity: CPU 31 Thread 31 successfully bound to CPU 31 GetNumaProcessorNode failed for cpu 32, error code: 87
Retrying with no NUMA Allocated 2MB Cached Large Page Scratchpad Buffer at: 0000021b3c400000 Connecting to mining pool support.ipbc.io:17777 ... Devfee is 1.5% That's strange because I only defined threads for the CPUs 0 to 31 in the config file.  Why does the miner try to access a CPU (core) 32, which is not present? Apart from that the miner starts mining and has better hashrate than XMR-stak with Bittube: 5200 H/s vs 4900 H/s.  In wikipedia no info about L1/L2 cache on Epyc. Only L3. Does L1/L2 cache exists on it or not? Just interesting... P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent... L1 -> Level 1 L2 -> Level 2 L3 -> Level 3 as the levels get higher, the cache is slower but larger. Maybe AMD is using some clever technique so L1/L2 caches are more shared than they are already, so mentioning it is useless. But absend L1 or L2 cache would have a huge impact on performance. I know it. No need to explain what means L1/L2/L3 and what they do... I just look in wiki and there no info about L1/L2 on Epyc... Just stays "N\A"... Not sure which Wikipedia you are looking at, but on https://en.wikipedia.org/wiki/Epyc you can see L2 cache or even better, on https://en.wikichip.org/wiki/amd/epyc you have even more information And if you use logic, there is no way a cpu will have L3 cache and not have L2/L1, since in that case L3 becomes L1... But in both your links there is no pointed L1 cache... i know that L1/L2 must be, I just wanted to know amount... |
|
|
|
|
zawawa, when we can try new version? What's the progress?
|
|
|
|
When I try the latest version on an AMD Epyc (basically four Ryzen dice on a package) I get the following error: Thread 30 successfully bound to CPU 30 Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 30 of NUMA node 3 at: 0000021b3c200000 Starting CPU Mining thread 31, affinity: CPU 31 Thread 31 successfully bound to CPU 31 GetNumaProcessorNode failed for cpu 32, error code: 87
Retrying with no NUMA Allocated 2MB Cached Large Page Scratchpad Buffer at: 0000021b3c400000 Connecting to mining pool support.ipbc.io:17777 ... Devfee is 1.5% That's strange because I only defined threads for the CPUs 0 to 31 in the config file. Why does the miner try to access a CPU (core) 32, which is not present? Apart from that the miner starts mining and has better hashrate than XMR-stak with Bittube: 5200 H/s vs 4900 H/s. In wikipedia no info about L1/L2 cache on Epyc. Only L3. Does L1/L2 cache exists on it or not? Just interesting... P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent... L1 -> Level 1 L2 -> Level 2 L3 -> Level 3 as the levels get higher, the cache is slower but larger. Maybe AMD is using some clever technique so L1/L2 caches are more shared than they are already, so mentioning it is useless. But absend L1 or L2 cache would have a huge impact on performance. I know it. No need to explain what means L1/L2/L3 and what they do... I just look in wiki and there no info about L1/L2 on Epyc... Just stays "N\A"... |
|
|
|
When I try the latest version on an AMD Epyc (basically four Ryzen dice on a package) I get the following error: Thread 30 successfully bound to CPU 30 Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 30 of NUMA node 3 at: 0000021b3c200000 Starting CPU Mining thread 31, affinity: CPU 31 Thread 31 successfully bound to CPU 31 GetNumaProcessorNode failed for cpu 32, error code: 87
Retrying with no NUMA Allocated 2MB Cached Large Page Scratchpad Buffer at: 0000021b3c400000 Connecting to mining pool support.ipbc.io:17777 ... Devfee is 1.5% That's strange because I only defined threads for the CPUs 0 to 31 in the config file. Why does the miner try to access a CPU (core) 32, which is not present? Apart from that the miner starts mining and has better hashrate than XMR-stak with Bittube: 5200 H/s vs 4900 H/s. In wikipedia no info about L1/L2 cache on Epyc. Only L3. Does L1/L2 cache exists on it or not? Just interesting... P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent... |
|
|
|
|
Show Posts
