 Show Posts
|
|
Pages: [1] 2 »
|
Very sad news  I wish you would reconsider once more. Perhaps at the moment mining is not profitable, but when you hodl and sell in 3 years, when BTC will be at 60.000  the calculation is a different one. |
|
|
|
Why my core i7-8700k,when mine cryptonight sometimes starts with good hashrate ~=400 h/S but sometimes start with 270h/S and i have to do several restarts of miner ( or open multiple instances) to make it to maximum and sometimes i quit and i leave it in the low hashrate..
Yes, that's stange! I had this issue, too, on several i7-8700 "Coffee Lake". Interestingly never on AMD Ryzen and not with "Haswell" based Intel systems. Perhaps a "secret" Coffee Lake hw-prefetching mechanism, which sometimes gets into play and sometimes not?!  |
|
|
|
Is it a quite weak machine? I had that problem a while ago with Monero and some older machines. The pool rised the difficulty higher and higher till the machine had no chance to return a hash in the given time. As a solution, I added the smallest allowed difficulty after the wallet address in the config file. With your pool it should be ".100000"  |
|
|
|
RYO is going to fork with a new algo "CN GPU"
Wow, with floating point operations!  That should keep away ASICs for a loooong time  5. New mining algo Cryptonight-GPU (CN-GPU).
Our previously developed POW Cryptonight-heavy was made to put GPU miners in a safe harbor, from ASICs and botnets threat. Keeping an eye on recent attacks of various coins by ASICs, botnets and FPGAs, we developed brand new mining algo. Keeping in mind GPU miners, our goal is to achieve our concept of fair GPU mining:
The most possible equality for both AMD and NVIDIA lineups of GPUs.
Scalable performance from low-end to high-end GPU.
Further slowing down CPUs in mining, making botnet creation times more inefficient.
Keeping algo ASIC-resistant.
Making algo FPGA-resistant.
Remove ability to attack network using Nicehash.
As you can see, the task is nowhere trivial and it took several weeks of hard work which resulted in the completion of all 6 goals:
Hashrate of NVIDIA GPUs increased up to 35% (depending on model) compared to CN-Heavy. Testing showed the potential of getting close results for comparable by compute capabilities cards. Though some AMD cards show decrease in hashrate compared to CN-heavy.
It is simple like that: If your GPU A is faster in Flops than GPU B - it will be faster in CN-GPU algo.
CPUs are even more slowed down e.g: Intel i3 - 4h/s (maximum - 4 threads), AMD Ryzen 1700 - 100hs (max - 16 threads)
Known ASICs are not capable of handling such computations, the cost of creation of an ASIC of this type is too high to be considered possible.
FPGAs can be programmed to execute any algo, but FP32 math is heavy even for this kind of devices, making the whole idea of spending dozens of thousands of USD and getting relative result to couple hi-end GPUs.
It is obvious that NH won't be supported a while. But keep in mind that if the algo will be popular among other projects - there is a possibility of being added there.
As a result, we come up with an algo that heavily relies on compute capabilities of chip and not dependant on the amount of GPU memory. The CN-GPU based FP32 math is the first of a kind mining algo in crypto world. |
|
|
|
It's interesting, that cn/2 alias Monero v8 has different impact on different CPUs. With Zen it's relatively moderate, AMD Ryzen 7 2700 dropped from 620 H/s to 595 H/s (-4%). On Bulldozer-based CPUs instead, it's devastating! A8-5600K "Piledriver" dropped from 155 H/s to 119 H/s (-24%), Opteron 4284 "Zambezi" from 280 H/s to 180 H/s (-35%) and A8-7600 "Kaveri" clashed from 177 H/s to 94 H/s (-47%). Apparently this are the archs, which were not cache limited, but are limited in execution units, pipelines and/or instructions on the fly, whereas a CPU like Ryzen is wide enough to do the extra instructions on the side.  |
|
|
|
Hi, I'm using JCE especially on older systems without AES-NI, because this miner is without competition here. Perhaps some may want to know, what's up with cn/2 alias Cryptonight v8 here. The extra instructions seem to be hard work for the oldies. An AMD Opteron 1381 dropped from 70 H/s to 50 H/s, two Opteron 2374 HE (working with 6 Threads) dropped from 120 H/s to 70 H/s Is there a chance for further optimizations or is all done what can be done with non-AES cpus? |
|
|
|
It's practically impossible...
It's not. I have a couple of systems, too, which were rebootet last time several years ago. When the system is stable and auto updates are off, why should a system not run for years? |
|
|
|
Hi JCE Miner,
first your miner is very nice and now supported by awesomeminer.
1 thing is not so nice, the masari hashrate is to low. Masari speed must be like cryptonight light v7.
Can anybody confirm this?
Nope Masari is twice the V7 hashrate Nope you are wrong. I have around 800 hashes with my RX550 and SRB 1.6.2 not tuned out on masari and cryptonight fast I think you talk at cross purposes With the CPU miner Masari (CN-Fast) has about 2x hashrates of CNv7 and half the hashrate of CN-lite (for example Aeon). With my Ryzen 7 2700: CNv7 => 640 H/s CN-Fast => 1200 H/s CN-Lite => 2350 H/s With GPUs, sxemini ist talking about, it may be different. Edit: sorry, doublepost with Larvitar |
|
|
|
Using cpu miner 0.31a. Algo cn-v7 on nicehash via ssl port 33363. AMD FX 8320 on two double threads. Speed about 175-190 h/s. Pool diff 100001.
Apart from your problem with the dev fee reconnect: You shouldn't use double hash with CNv7 on an AMD FX. Bulldozer has got 2 MB L2 cache per module. That's exactly the scratchpad size of one CNv7 thread. So don't us double hash, which results in 4 MB scratchpad size, use four single hash threads and put one per module, ergo (under Windows) cores 0, 2, 4 and 6 (or 1, 3, 5 and 7). That's way faster than your config. With CNv7 you should get a hashrate of approximalely 290 H/s. The maximum you can get with an AMD FX is, to use the circumstance that it has – beneath its 2 MB L2 cache per module – an 8 MB L3 victim cache, which is not inclusive as it is the case with all Intel CPUs. Data in the L2 cache is never in the L3 cache and vice versa. So with bulldozer, you can start 8 single hash CNv7 threads dedicated to the cores 0, 1, 2, 3, 4, 5, 6 and 7. This config will result in a lot of traffic between L2 and L3, that's why performance will not scale linear with the number of threads, but still all data is cached, no slow memory access. It will give you the max. performance, in your case around 340 H/s with FX-8320. |
|
|
|
Thanks! The new GPU miner 0.31c is indeed a bit faster in BitTube v4 (CN Heavy variant) than its predecessor. My Radeon RX 580 4GB @stock hashes with 672 H/s now (vs. 655 H/s with the old 0.30c). Settings are: "gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":432 },
], Higher intensity is not possible because a FullHD display is connected. |
|
|
|
Bittube v2 has both the complexity of CN-Heavy and CN-IPBC. This is why it's clearly slower than others.
My opencl in the 0.31c was based on the pre-bittube code, sorry i just got confused with my own files and shipped the bad release. I reuploaded it. Same version, no other change, that's just to fix a bad zip upload.
Great! And I works! |
|
|
|
|
The BitTube code of the new GPU miner 0.31c seems to be broken. I immediately get rejected shares with that version. 0.30c instead works with the same settings.
|
|
|
|
Heavy is not good optimized yet. But on 570/4 speed will be about 750-800, 580/8 - about 1000 h/s.
You should add "with mod bios and optimized clock/power/ram settings". @Stock the performance is significantly lower! |
|
|
|
just to be clear, for CPU mining, I want to look for CN-Lite --and-- CN-Fast algorithms? I'd go for CN-Lite, AeonCoin for example. There the CPUs' advantage over GPUs is max. With a scratchpad size of 1 MB per thread you can start 32 threads on your 2 socket system and the data still fits into the L 2 cache of your Opterons 6376. When you activate double-hash, you can still run 32 threads, filling the L2 and L 3 victim cache for the last extra percent of performance. " Bulldozer was without doubt an unmitigated failure" (Andrew Feldman, Corporate Vice President and General Manager of the Server Business Unit, AMD), but at mining CN, it is a beast! |
|
|
|
Coin/Algo: Alloy / cryptonight-alloy
How would I determine optimized settings? I guess I should see what I get on CN v7 to see if it's close to that 900 number. any suggestions of coins to try? Sumo? Oh. Alloy is a harder variant of CN Heavy. You shouldn't mine CN-Heavy or CN-Alloy with CPUs, since their drop of hashrate in comparison to CN ist enormous, whereas GPUs aren't affected in the same way. CN-Heavy and CN-Alloy are tailormade for GPUs.  Consider to mine a CN-Lite coin with your CPUs. You may reach around 2700 H/s with CN-Lite (Aeon, Turtlecoin) or about 1300 H/s with CN-Fast (Masari).  If you want to mine CNv7, why not Monero? Sumo is back to ASIC friendly original CN. It's absurd to mine an ASIC coin with CPUs.  I didn't know that about AMD FX Piledriver dies. Your response is very informative. Thank you for that.
No problem |
|
|
|
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 But that depends on what coin/algo you want to mine |
|
|
|
Hey there are some errors or outdated infos in the README.md: 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! Perhaps you got confused by your own Ryzen 5 1600. There indeed 8 cores are unused. 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. |
|
|
|
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...
My AMD Epyc 7351P has 64 MB shared L3 cache, besides of 16x 512 KB L2 cache dedicated to each core. http://www.cpu-world.com/CPUs/Zen/AMD-EPYC%207351P.html |
|
|
|
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. |
|
|
|
|
