You should no longer need the --variation for stellite, now it's automatic
about the suffix i admit i haven't tested that for some time, maybe a regression, i'll test again
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 88. (Read 90841 times)
I've re-uploaded the 0.30b with the extra Nicehash fix. I recheck at every step the Job and the nonce is still valid. And again before sending the result to the pool. If nicehash after that still says the nonce is invalid or the job doesn't exist, well, i'm out of ideas.
i also added the total cpu hashrate in the log.
i also added the total cpu hashrate in the log.
Maybe some problem with fixed difficulty added to wallet string?
'.500000' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\anwar\Desktop\jce_cn_gpu_miner.prototype.030b>jce_cn_gpu_miner64.exe -c config.txt --no-cpu --any --forever --variation 7 --low -o stellite.ingest.cryptoknight.cc:16223 -u Se3oCb3DbCzSUXnDeUtZq5gCbZ68ZmXahQaetshwYzun2pPhXPvfh3zSQhjFNjVjrtbjcA8hoKd5UAz YKFHoD4LR1Xi5a1M82 -p 6
I've re-uploaded the 0.30b with the extra Nicehash fix. I recheck at every step the Job and the nonce is still valid. And again before sending the result to the pool. If nicehash after that still says the nonce is invalid or the job doesn't exist, well, i'm out of ideas.
i also added the total cpu hashrate in the log.
i also added the total cpu hashrate in the log.
ok, i've an idea about where it could come from. My last idea.
I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
"Job not found" rejects also still here... During 1.5 hour of mining 2 of them allready. I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
ok, i've an idea about where it could come from. My last idea.
I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
yeah i need to look at the new Bittube fork
Nicehash: that's very strange, I rewrote large parts of my nicehash netcode, i know how to handle the nicehash mode (keep the high-order byte of the nonce) and, I couldn't reproduce despite long tests on my rig today. Sure there's a problem, but it's getting complicated.
Invalid nonce error happens in other miners too, but very rare... In you miner it's often... After fixing "job not found", invalid nonce became often imho...Nicehash: that's very strange, I rewrote large parts of my nicehash netcode, i know how to handle the nicehash mode (keep the high-order byte of the nonce) and, I couldn't reproduce despite long tests on my rig today. Sure there's a problem, but it's getting complicated.
Ohh, new rejected share detected - "duplicate share"... nicehash mode...
Effective speed allways much lower than hashspeed... Looks like it's many work need on nicehash mode...
yeah i need to look at the new Bittube fork
Nicehash: that's very strange, I rewrote large parts of my nicehash netcode, i know how to handle the nicehash mode (keep the high-order byte of the nonce) and, I couldn't reproduce despite long tests on my rig today. Sure there's a problem, but it's getting complicated.
Nicehash: that's very strange, I rewrote large parts of my nicehash netcode, i know how to handle the nicehash mode (keep the high-order byte of the nonce) and, I couldn't reproduce despite long tests on my rig today. Sure there's a problem, but it's getting complicated.
Error "Invalid nonce; is miner not compatible with NiceHash?" is still here. "Job not found" not seen yet...
just a quick heads up: bittube will switch tomorrow (probably) to cn-heavy of some sort.
My problem is with cryptonight normal v7, my 560s are capped at 540-550 h/s, i'm editing elpida/hynix straps with "some" knowledge but i can never pass the 540 h/s although the memory does that with 1950-2000 mhz, whatever i do to the timings, i cant seem to pass 550 h/s even with core to 1230 mhz (1150 mhz on 16CU 560 and around 1900-2000 mhz silicon lottery on memory, always gives 500-550h/s) I don't get 550s cause they are roughly almost the same cost! and they cnat mine ethereum or ethereum forks even with 4gb of memory cause of the compute limitations.
What memory strap/config do you use for Hynix MJR and Elpida? I'm stuck at 505H/s
tried light algo withh settings from normal v7 and got 4050hs on Vega 56 (normal v7 2000hs)
thats nice!
and also thhe Ryzen got speed buff on this algo with 1260hs
so Ryzen + 2x Vega 56 = 9360hs = love the algo and JCE
thats nice!
and also thhe Ryzen got speed buff on this algo with 1260hs
so Ryzen + 2x Vega 56 = 9360hs = love the algo and JCE
I dont understand the moaning about compile times, you just do not launch the miner that frequently that it is an issue.
Yes there is some trial and error to start with to find optimum configuration but then you launch and forget.
If you are messing around excessively restarting the program you are not mining and so not earning.
If you are messing around excessively restarting the program that is your choice and not a problem for the author to fix.
Baz
Yes there is some trial and error to start with to find optimum configuration but then you launch and forget.
If you are messing around excessively restarting the program you are not mining and so not earning.
If you are messing around excessively restarting the program that is your choice and not a problem for the author to fix.
Baz
easy man..
It just my input / opinion I didn't say it's bug / problem that developer need to fix. it just value added to the miner same thing like GPU temp and fan speed.
Still if you choose between fast startup and a bit slow startup with the same hash rate you will choose fast startup right?
Today there is a lot of cryptonight variant where if you want to switch the algorithm you need to restart miner, of course we don't switch often.
I dont understand the moaning about compile times, you just do not launch the miner that frequently that it is an issue.
Yes there is some trial and error to start with to find optimum configuration but then you launch and forget.
If you are messing around excessively restarting the program you are not mining and so not earning.
If you are messing around excessively restarting the program that is your choice and not a problem for the author to fix.
Baz
Yes there is some trial and error to start with to find optimum configuration but then you launch and forget.
If you are messing around excessively restarting the program you are not mining and so not earning.
If you are messing around excessively restarting the program that is your choice and not a problem for the author to fix.
Baz
I'll tell you about the long kernel compile: it's made of generated-on-the-fly obfuscated opencl that contains some hard-coded values (mostly pointers) explicitly here to make the code un-runnable on any other thread, on any other gpu, even on the same machine.
In a paradise world with no hacker, i would simply compile once and run several times. Like Stak.
But hacking binary kernels or normal opencl code is simple, so i prefer using expandable code generated every time, for security reasons. Maybe i'll find a way to be both fast and secure, but not for now.
So as strange as it can look, even if you have 16 times the exact same config on your 8-GPU rig, it will compile 16 different codes, on purpose. And if you relaunch the miner, it will be yet another 16 different codes. I made no code re-usable, on purpose.
Temperature and Fan speed monitor is planned, but not high priority. That's quite simple with lib ADL.
In a paradise world with no hacker, i would simply compile once and run several times. Like Stak.
But hacking binary kernels or normal opencl code is simple, so i prefer using expandable code generated every time, for security reasons. Maybe i'll find a way to be both fast and secure, but not for now.
So as strange as it can look, even if you have 16 times the exact same config on your 8-GPU rig, it will compile 16 different codes, on purpose. And if you relaunch the miner, it will be yet another 16 different codes. I made no code re-usable, on purpose.
Temperature and Fan speed monitor is planned, but not high priority. That's quite simple with lib ADL.
ok understand for your concern about security reason, but I believe most miner is very fast at startup so i hope you will find the way soon.
thanks for considering GPU temp and fan speed, it's useful information for me.
I'll tell you about the long kernel compile: it's made of generated-on-the-fly obfuscated opencl that contains some hard-coded values (mostly pointers) explicitly here to make the code un-runnable on any other thread, on any other gpu, even on the same machine.
In a paradise world with no hacker, i would simply compile once and run several times. Like Stak.
But hacking binary kernels or normal opencl code is simple, so i prefer using expandable code generated every time, for security reasons. Maybe i'll find a way to be both fast and secure, but not for now.
So as strange as it can look, even if you have 16 times the exact same config on your 8-GPU rig, it will compile 16 different codes, on purpose. And if you relaunch the miner, it will be yet another 16 different codes. I made no code re-usable, on purpose.
Temperature and Fan speed monitor is planned, but not high priority. That's quite simple with lib ADL.
In a paradise world with no hacker, i would simply compile once and run several times. Like Stak.
But hacking binary kernels or normal opencl code is simple, so i prefer using expandable code generated every time, for security reasons. Maybe i'll find a way to be both fast and secure, but not for now.
So as strange as it can look, even if you have 16 times the exact same config on your 8-GPU rig, it will compile 16 different codes, on purpose. And if you relaunch the miner, it will be yet another 16 different codes. I made no code re-usable, on purpose.
Temperature and Fan speed monitor is planned, but not high priority. That's quite simple with lib ADL.
Hi JCE Miner,
What is the meaning of recent changes "Increased maximum threads from 64 to 256" ?
Please consider to display GPU Temperature and Fan Speed, because it's good to monitor them.
Another input instead of compiling kernel for each thread is it better to use compiled kernel on first thread if the rest of GPU and the setting is the same?
because compiling kernel take time and can you imagine if we have 13 GPU each GPU we set 2 thread then it will compiling kernel 26 times.
Thanks.
What is the meaning of recent changes "Increased maximum threads from 64 to 256" ?
Please consider to display GPU Temperature and Fan Speed, because it's good to monitor them.
Another input instead of compiling kernel for each thread is it better to use compiled kernel on first thread if the rest of GPU and the setting is the same?
because compiling kernel take time and can you imagine if we have 13 GPU each GPU we set 2 thread then it will compiling kernel 26 times.
Thanks.
0.30b online
Code:
Rewritten Nicehash netcode
Increased maximum threads from 64 to 256
Found share now logs the GPU and the Lane and the Thread
Increased maximum threads from 64 to 256
Found share now logs the GPU and the Lane and the Thread
Quote
@JCE, Gief luv to Linux Smiley Windowz Sux
Probably not, that's a lot of work for very few potential usersQuote
I tested it on my APU - no change. Stil not recognized.
Si i'll need to get one myself, bling fixes won't do the jobQuote
posting the changelog on the first page of this thread and/or in github.
Done on first page here, but not github, it would make the doc too long
I don't even know if JCE is good on Vega, i got report at ~2070 on a Vega 64, it sounds good but i cannot bench against Cast.
Now the rx560 : i got same results than you. Memory controller capped at 50% and no way to go above ~540 on best cards, the 2Gb with Elpida.
About the GPU itself, its power doesn't matter, i've same result with the 14CU and 16CU, and underclocking the GPU down to 1120 still gives the same results (but it allows to lower voltage to save power).
So i found no magic on the RX560, and i just think the memory controller level indicator is either gitchy, or counts some texture buffers that are not used during mining, resulting into an average between 0 and 100% usage.
My dev now focus on fixing Nicehash and add multi-pool (per-GPU coin/pool)
Now the rx560 : i got same results than you. Memory controller capped at 50% and no way to go above ~540 on best cards, the 2Gb with Elpida.
About the GPU itself, its power doesn't matter, i've same result with the 14CU and 16CU, and underclocking the GPU down to 1120 still gives the same results (but it allows to lower voltage to save power).
So i found no magic on the RX560, and i just think the memory controller level indicator is either gitchy, or counts some texture buffers that are not used during mining, resulting into an average between 0 and 100% usage.
My dev now focus on fixing Nicehash and add multi-pool (per-GPU coin/pool)
Hey, first off don't split your efforts much into expansion, rather plan an expansion one shot into one thing, like APUs or GPUs only, or better results with nvidias, etc etc. rather than jumping into lets say, VEGA when both other miners have better stability or optimization.
If you want, i can help with 560/550 2gb (well most 128 bit memory polaris)
I need your help to understand something though, 560 2gb elpida (best is even unpowered ones, ie: no 6 pins) , i was even thinking of a semi asic rig, strip off useless fans, get well made chinese aluminum heatsinks and do a compact 8/12/16 builds but meh).
My problem is with cryptonight normal v7, my 560s are capped at 540-550 h/s, i'm editing elpida/hynix straps with "some" knowledge but i can never pass the 540 h/s although the memory does that with 1950-2000 mhz, whatever i do to the timings, i cant seem to pass 550 h/s even with core to 1230 mhz (1150 mhz on 16CU 560 and around 1900-2000 mhz silicon lottery on memory, always gives 500-550h/s) I don't get 550s cause they are roughly almost the same cost! and they cnat mine ethereum or ethereum forks even with 4gb of memory cause of the compute limitations.
I noticed my memory controller utilization is nearly always 50.0% exactly, can't tell what is the limitation here, cause theortically, with different timings at lets say 2100 mhz, memory should produce some 5-15% more hash rate correct?
I'm glad to share any info with you i have 6x 580/570 4gb (hynix ajr high quality), 2x580 8gb Hynix mjr (1100 h/s CN heavy), 9xRX 560 2gb (elpida/hynix with mixed factory 1750mhz memory batches "not silicone lottery here") and 2x 560 4gb Micron mining mostly cryptonight forks. at high efficiency (specially when compared to the wasteful eth)
If you want, i can help with 560/550 2gb (well most 128 bit memory polaris)
I need your help to understand something though, 560 2gb elpida (best is even unpowered ones, ie: no 6 pins) , i was even thinking of a semi asic rig, strip off useless fans, get well made chinese aluminum heatsinks and do a compact 8/12/16 builds but meh).
My problem is with cryptonight normal v7, my 560s are capped at 540-550 h/s, i'm editing elpida/hynix straps with "some" knowledge but i can never pass the 540 h/s although the memory does that with 1950-2000 mhz, whatever i do to the timings, i cant seem to pass 550 h/s even with core to 1230 mhz (1150 mhz on 16CU 560 and around 1900-2000 mhz silicon lottery on memory, always gives 500-550h/s) I don't get 550s cause they are roughly almost the same cost! and they cnat mine ethereum or ethereum forks even with 4gb of memory cause of the compute limitations.
I noticed my memory controller utilization is nearly always 50.0% exactly, can't tell what is the limitation here, cause theortically, with different timings at lets say 2100 mhz, memory should produce some 5-15% more hash rate correct?
I'm glad to share any info with you i have 6x 580/570 4gb (hynix ajr high quality), 2x580 8gb Hynix mjr (1100 h/s CN heavy), 9xRX 560 2gb (elpida/hynix with mixed factory 1750mhz memory batches "not silicone lottery here") and 2x 560 4gb Micron mining mostly cryptonight forks. at high efficiency (specially when compared to the wasteful eth)
I tested it on my APU - no change. Stil not recognized.
Jump to: