Bitcoin Forum
September 23, 2019, 08:21:20 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 120 »
  Print  
Author Topic: [JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+  (Read 87019 times)
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 04, 2018, 06:17:00 PM
 #661

Wow, so many messages, thanks all.

I'm currently burning my ryzen with the Bittube-v4 fork test. I'm one day late, but the speed on ryzen is higher than other miner. I don't give numbers since i may have badly configured the other (xmrig) I let you test by yourself, but my assembly optimization looks good.

Code:
Detecting OpenCL-capable GPUs...
No OpenCL-capable GPU found.

I've a known bug about APUs, nVidia cards and probably other cases, i've several exotic cards on my rigs (Baffin, Tahiti, Pitcairn, and even a Bonaire) but no APU or RX470 yet. That's why i keep it labeled "prototype" for now. I plan to buy an APU to test my bug, and hope it will fix the other cases too.

Quote
Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

As i already mentionned, the OpenCL in the prototype is dynamic and expandable for security reasons. No way to save or reuse a kernel, on purpose. JCE kernels, may you dump them, would not work, even on a subsequent run of JCE.
I hope i'll find a way to be both secure and fast, and then maybe i'll be able to provide reusable kernels.

SRB kernels are normal kernels with just the file encrypted. One can attach a OpenCL debugger and look at the clear IL code (CGN pseudo-assembly). The same for Cast or Claymore. I want to be more secure. (no i didn't do that myself, my code uses exclusive optims I originaly developped for JCE CPU 32-bits, since CGN GPU are scalar 32-bits now, hence why the perf are different, and lower on Heavy for now).

Quote
what happens with miner if one of the cards get stuck or some problem occurs?
Yeah a watchdog is planned, to look for zero hashrate or GPU overheat. But not higher priority for now.

"Lermite" mmh, that name sounds familiar... Roll Eyes
1569226880
Hero Member
*
Offline Offline

Posts: 1569226880

View Profile Personal Message (Offline)

Ignore
1569226880
Reply with quote  #2

1569226880
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1569226880
Hero Member
*
Offline Offline

Posts: 1569226880

View Profile Personal Message (Offline)

Ignore
1569226880
Reply with quote  #2

1569226880
Report to moderator
Lermite
Newbie
*
Offline Offline

Activity: 54
Merit: 0


View Profile
July 04, 2018, 06:29:48 PM
 #662

"Lermite" mmh, that name sounds familiar... Roll Eyes
I'm the one your thinking about Smiley

One way to save compiling time without compromising the security would be to compile the kernel of the first thread of a GPU, and keeping it in RAM or cache to inject it to the other treads of the same GPU if they have the exact same parameters.
This optimization would not apply to a GPU with only one thread, neither one with several threads with different parameters, but as the most usual case is two identical threads per GPU, it could save much time during each startup.
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 04, 2018, 06:43:07 PM
 #663

It may be possible, but slightly less secure. Kernels are not unsecure in ram, they are unsecure when passed to OpenCL as binaries.

I read SRB indirectly replied to my post about hashrate. I didn't want to polute his topic, so I answer here. Doktor, you're welcome to answer here, if you want.

I said and repeat that Claymore was cheating, at least on the XMR miner. Just use the no-fee mode, and you get the exact same displayed hashrate with a punishing -5% effective result. Plug it to a proxy, and you get -10%. As a vengeance. And hashrate difference was a lot worse on version 10+ than 9.7.
That's was I carefully measured when I mined with claymore, before I dev my own miner.
And I say the opposite for Stak or Xmrig. It means that anybody claiming Stak or xmrig cheats (i read one on your topic) just does a bad test, since they explicitely does nothing bad, their code is clear open and clean.
The only cheaty thing is that Stak mines +2s than said per session, to handle the connection delay. I find it oversized, no pool has a 2s ping, but that's a small difference.

Code:
inline bool is_dev_time()
{
//Add 2 seconds to compensate for connect
constexpr size_t dev_portion = static_cast<size_t>(double(iDevDonatePeriod) * fDevDonationLevel + 2.);
....

However, all, please do not jump back to another miner's thread to claim you found a better one. That's not polite. I know that Xmrig did it a lot with Stak so it's somehow a tradition, but please avoid.
vmozara
Member
**
Offline Offline

Activity: 193
Merit: 55


View Profile
July 04, 2018, 07:28:50 PM
 #664

Ok, sorry, i will not do anymore. I just got angry because nobody listened to me. I will stick with JCE now Smiley
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 04, 2018, 07:33:19 PM
 #665

A technical possible reason could be a bug in code that cause false positive. Good shares that are not found.
Also, if the mining of N shares (N=multihash in JCE, intensity in Stak) is interrupted after only K shares have been computed (K<N) because of a Stale share, the share counter should be incremented by K and not by N. Since evaluating K is complicated, maybe some miners just count N. In such case this is not explicit cheat like adding +5% on the displayed hashrate like Claymore, but a technical overlook.
Bry Guy
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
July 04, 2018, 07:38:59 PM
 #666

Hi JCE, I just started testing your miner (I opted for the a version due to noted regressions in b) and after about 15 hours of testing on my 8 x Vega 56 rig, things are looking very good. I can post more details once it has proven stable over time, but upon initial observation, I am quite pleased.

I understand that the h/s displayed in blue is the true average physical hashes per second over the past 512 hashes. In Advanced Topics, you state that the displayed number has no tweak, and includes the fees. If I understand correctly, could this be a reason why when I refresh quickly using 'h', I see values drop considerably on one thread followed by the other, followed by yet another? The only reason I ask this, is that a highly variable h/s on any given thread can sometimes be an early warning sign that the card/thread is not stable due to overly-aggressive configuration settings or clocks/voltages). Based on my observations, the numbers come right back up into a normal and stable range, so it seems that this is by design and that you are mining to your dev pool on a thread-by-thread basis, and that this is not necessarily a sign of instability. I just want to be sure before I spend more time tweaking performance.

Also, Effective Net Hashrate as calculated by total hashes / total seconds spent mining is often much higher than my average physical hashrate, even over an extended period of time. Since this number is supposed to take into account stale/invalid shares as well as fees, this is surprising. I would expect the number to be lower. Do you have any thoughts on this matter?

Keep up the good work!
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 04, 2018, 09:02:54 PM
 #667

hello,

When i say the fees are included, that means the displayed hashrate is the same no matter if you're in a devfee session or not. This is the raw physical hashrate.
If you punch h, you lock the mining thread to force it to update the hashrate counter and display it on screen, so if you punch again and again, it will lower the hashrate, that's normal. This is the same for the CPU version. Better use the JSON http output which is updated in the network thread, and does not cause such a problem. From your browser, you can press F5 as much as you want. But not H from the console.

Effective hashrate should converge mathematicaly to lower than the average physical hashrate. Normaly by ~2% on a very long term.
If it's higher, so you had a good luck biasis. You can check that number two ways :
1. Look at your pool, you should get a similar hashrate (the computation range of the pool may be different from JCE, but on the long term, they should converge).
2. Get your total hashes and divide it by the uptime. You should get the same value. The hashes themselve can be checked against your pool history, or JCE log, and the uptime by... your wall clock Smiley

A difference can be explained by some instant peaks from your cards that make you mine faster but may not be reported by the blue instant hashrate, if you mine so fast that the 512 hashes are obsoleted fast. I admit that 512 was good for CPU, which can mine at 150h/s per core at best, but that's just half a second for a Vega. Average rate over half a second is too low. This is the problem. Good remark, i'll increase the time period for average of fast cards like Vega Wink

Version 0.30c online
Quote
Netcode fixes
Bittube v4
PsychoSterope
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
July 04, 2018, 09:23:23 PM
 #668

I have a very old AMD HD5670 that I am just curious to try with the GPU miner. I know you said on Github you didn't have very good luck with a 1GB card, but I am just too curious.

What settings do you think I should try with this old 1Gb card?


Thanks!
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 04, 2018, 09:30:18 PM
 #669

i didn't test on cards older than HD7000 and i don't think it will ever compile. but you can test Wink

use the same config that my Bonaire in the doc, and try to raise multi_hash to 240 in case it's better Smiley
Bry Guy
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
July 04, 2018, 10:23:32 PM
Last edit: July 04, 2018, 10:36:09 PM by Bry Guy
 #670

hello,

When i say the fees are included, that means the displayed hashrate is the same no matter if you're in a devfee session or not. This is the raw physical hashrate.
If you punch h, you lock the mining thread to force it to update the hashrate counter and display it on screen, so if you punch again and again, it will lower the hashrate, that's normal. This is the same for the CPU version. Better use the JSON http output which is updated in the network thread, and does not cause such a problem. From your browser, you can press F5 as much as you want. But not H from the console.

Effective hashrate should converge mathematicaly to lower than the average physical hashrate. Normaly by ~2% on a very long term.
If it's higher, so you had a good luck biasis. You can check that number two ways :
1. Look at your pool, you should get a similar hashrate (the computation range of the pool may be different from JCE, but on the long term, they should converge).
2. Get your total hashes and divide it by the uptime. You should get the same value. The hashes themselve can be checked against your pool history, or JCE log, and the uptime by... your wall clock Smiley

A difference can be explained by some instant peaks from your cards that make you mine faster but may not be reported by the blue instant hashrate, if you mine so fast that the 512 hashes are obsoleted fast. I admit that 512 was good for CPU, which can mine at 150h/s per core at best, but that's just half a second for a Vega. Average rate over half a second is too low. This is the problem. Good remark, i'll increase the time period for average of fast cards like Vega Wink

Version 0.30c online
Quote
Netcode fixes
Bittube v4

Thanks for the thorough reply. I will indeed use the JSON to monitor moving forward. I fully understand the way luck is involved and that a hashrate shown poolside based on shares found will need considerable time to converge with physical hashrate. I now see that you are simply multiplying shares found for the non-dev pool x difficulty value and that luck is included in this Effective Hashrate number.

I suspect that you are right about the possible spikes in physical h/s on Vegas causing confusion since the current sample size for physical averages is actually closer to .25 seconds!
NotEnough
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
July 04, 2018, 10:51:58 PM
Last edit: July 05, 2018, 07:39:18 AM by NotEnough
 #671

any hints why Ryzen starts with 180hs per Thread and drop to 130hs after some minutes (CNV7 lite)

and yes..got many duplicates at no nicehash pool

I have same issue. R7 1700x starts with 2200+ h/s and after few minutes h/r drops to 1700 h/s. Also all system GPU slow down h/r too . XMR-Stak (with similar settings for CPU) gets ~ 2140 h/s, but all works great.
P.S. Tested on two different motherboards (B350 and X470 chipsets) with two different instances of the processor.
grendel25
Legendary
*
Offline Offline

Activity: 1456
Merit: 1024



View Profile
July 05, 2018, 04:45:38 AM
 #672

question:  I'm using 2x opteron 6376 and get around 475 h/s using 16 of 32 available cores which seems to consume about 57% of CPU resources.  Could i tune this up to get better performance and also use the other 16 cores?  Thank you for any comments or suggestions.

..Absolute.......................
..The First Proof of View Cryptocurrency..
.
.
▄▄█████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄████████████████▀▀█████▄
▄████████████▀▀▀    ██████▄
████████▀▀▀   ▄▀   ████████
█████▄     ▄█▀     ████████
████████▄ █▀      █████████
▀████████▌▐       ████████▀
▀████████ ▄██▄  ████████▀
▀█████████████▄███████▀
▀█████████████████▀
▀▀█████████▀▀
.
▄▄█████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄████████▀█████▀████████▄
▄██████▀  ▀     ▀  ▀██████▄
██████▌             ▐██████
██████    ██   ██    ██████
█████▌    ▀▀   ▀▀    ▐█████
▀█████▄  ▄▄     ▄▄  ▄█████▀
▀██████▄▄███████▄▄██████▀
▀█████████████████████▀
▀█████████████████▀
▀▀█████████▀▀
.
.
Bazzaar
Jr. Member
*
Offline Offline

Activity: 76
Merit: 1


View Profile
July 05, 2018, 12:03:24 PM
 #673

its more about the cache than the cores, you can only run as many threads as the cache has capacity for the scrtchpads
Larvitar
Jr. Member
*
Offline Offline

Activity: 197
Merit: 1


View Profile
July 05, 2018, 12:28:55 PM
 #674

Wow

I take a few days off and you lauch the JCE-Miner GPU version!

I'll try it today. How is the CN-Lite performance?
Lonnegan64
Jr. Member
*
Offline Offline

Activity: 37
Merit: 5


View Profile
July 05, 2018, 12:43:03 PM
 #675

Hey Smiley

there are some errors or outdated infos in the README.md:

Quote
Another exclusive feature of JCE!
❗️ The no-cache mode is available only in the Windows version.
This is the reciprocal of multi-hash: for cases when your have wasted CPU cores, typically when mining Cryptonight Heavy. If you have a Ryzen 1700, 8 physical cores, 16 logical CPUs, 16M cache, the naive configuration would be 4 threads on 4 cores, 4M cache each, total 16M.

"cpu_threads_conf" : 

     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  1, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  5, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  9, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 13, "use_cache" : true },
]
But 8 logical CPUs would be unused. Enabling them would flood the cache and lead to worse performance. What to do is making them mine, but with no cache, direct to memory.
When the Ryzen 7 1700 has 16 logical cores and only 4 are used, then not 8 logical cores are unused, but 12! Wink Perhaps you got confused by your own Ryzen 5 1600. There indeed 8 cores are unused.

Quote
Sumokoin, Loki, Ombre, Italo, Bloc, Niobio, Saronite are now Cryptonight-Heavy,
Sumokoin is not Cryptonight-Heavy anymore. They went back to original Cryptonight to be ASIC-friendly, whereas the existing Cryptonight-Heavy chain was renamed to Ryo-currency or simple Ryo.  Shocked
Lonnegan64
Jr. Member
*
Offline Offline

Activity: 37
Merit: 5


View Profile
July 05, 2018, 12:44:54 PM
Last edit: July 05, 2018, 12:56:03 PM by Lonnegan64
Merited by grendel25 (5)
 #676

question:  I'm using 2x opteron 6376 and get around 475 h/s using 16 of 32 available cores which seems to consume about 57% of CPU resources.  Could i tune this up to get better performance and also use the other 16 cores?  Thank you for any comments or suggestions.
What coin/algo?

The Opteron 6376 is basically two AMD FX Piledriver dies on one package. An FX 8300 hashes around 1000 H/s Cryptonight-Lite or 340 H/s with CN v7.

Your system with two Opteron 6376 (say four FX dies), but lower frequency, should be around FX-8300-hashrate * 4 * 2.3 / 3.3. So CN v7 hashrate should be VAGUELY 900 H/s for the whole system with optimized settings Smiley But that depends on what coin/algo you want to mine Smiley
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 05, 2018, 04:36:21 PM
 #677

Quote
I now see that you are simply multiplying shares found for the non-dev pool x difficulty value and that luck is included in this Effective Hashrate number.

Correct. This is why I call it effective. This is not a long term average, but the real yield you got from the miner.

Quote
But 8 logical CPUs would be unused
I was correct, there are 4 cores (equals 8 logical cpu) unused. But i rewrote my sentence to be more explicit.

The CPU mining is very sensitive to any event on the computer, including yourself pressing H to get the hashrate (pressing H has higher priority than mining to stay responsive, so it stops the miner for a split second and leads to a lower hashrate).
With the computer/rig Idle and dedicated to CPU mining, the hashrate should be stable.

Quote
Sumokoin is not Cryptonight-Heavy anymore.
Thanks, I updated my doc.

I'm now building the updated CPU-only version 0.31 with new netcode, bittube-v4 and updated coins.
vmozara
Member
**
Offline Offline

Activity: 193
Merit: 55


View Profile
July 05, 2018, 05:47:55 PM
 #678

Hi everybody,

I promised update on the hash rate verification and here is:

Total of 6 miners connected to monero ocean pool

Each miner is 14.3 to 14.7 KH/s depending of cards setups

When I press R, the miner gives effective hashrate and hash count - all 6 miners showed exact the same hash count as the pool (minus 1.5% devfee). My average effective hashrate is at least 14KH/s, which is less than blue letters HS/s, I saw JCE put some explanation about this in previous posts, but I didn't read the post well.

Anyway, with such huge effective hashrate, all my rigs are now on JCE miner. My moneroocean "chart average" went from around 70-73KH/s to around 78-80KH/s (hard to say due to only one day of testing but difference is massive and obvious) compared to srbminer 1.6.1 which I was using before.

Unfortunately I did not pay attention to power consumption but seems to be the same

The people in other topic tried hard to convince me that my math is bad or I have issues with rigs, and simple change of miner increased my hashrate by like 10%. I have never been more happy to give 1.5% dev fee  Grin

Dear JCE, thanks for awesome miner, please keep developing!
Sx5000
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
July 05, 2018, 06:16:05 PM
 #679

Hello! First, I thank the developer of this miner, very happy!
I would like to emphasize the minuses and advantages of the gpu miner at the moment:

Pro:
A real hash
Many coins supported
Normal minimalistic interface
Minimal commission

Con:
No monitoring of temperature and speed, voltage, frequency, their adjustment
There is not enough identification of the card on bus_id
Display sequence is not the same as in gpuz and overdrive
A heavy algorithm on rx550 has an unstable hashrate
Very long compilation at startup. Rig on 12 cards about 5 minutes, this makes testing very difficult Sad
No failover pools

Good luck to the developer!
JCE-Miner
Member
**
Offline Offline

Activity: 350
Merit: 22


View Profile
July 05, 2018, 06:30:58 PM
Last edit: July 05, 2018, 06:56:29 PM by JCE-Miner
 #680

Thanks vmozara Smiley

I don't reply about the pool side difference. I don't want to start a dev war.
I just still say Claymore obviously tweaked the effective hashrate of his XMR miner against displayed hashrate, and he pretended in his doc that was because of "disabled optims" -5%. No problem with that, but a disabled optim should also lower the displayed hashrate. If you explicitely mine @500 minus 5% of "disabled optims" you must display 475. Period.

Note that the GPU devfees are 0.9% and not 1.5%.
1.5% is on the CPU part only, your 2KH/s vegas mine with 0.9% devfee.

Quote
Normal minimalistic interface
Thanks, this is on purpose, I wanted something clear and simple, close to Claymore 9.7
I found later versions harder to read. For example, I give the pool-side value of the share, which is useful, but not the hexadecimal hash value, which is useless, except for the dev debug.

Quote
No monitoring of temperature and speed, voltage, frequency, their adjustment
No failover pools
Planned

Quote
There is not enough identification of the card on bus_id
There's currently the PCIe ID (named "Device" at JCE startup, in green)

Quote
A heavy algorithm on rx550 has an unstable hashrate
I know my heavy is bad, i need to optimize it. I even tell it explicitely in my doc.

Quote
Display sequence is not the same as in gpuz and overdrive
Debatable. I currently use the OpenCL order.

Quote
Very long compilation at startup. Rig on 12 cards about 5 minutes, this makes testing very difficult
When you test on 12 cards, first test on one card, then copy-paste the optimal values to the other 11 ones.
JCE OpenCL is generated on the fly and is bound to all environement, including the card, the parameters, the memory addresses and the coin. Recycling between two tests is impossible. Recycling between two same runs of JCE with exact same parameters is possible but would compromise security, I already explained why. But I don't give up finding a way that's both secure and faster.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 120 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!