I know this old miner, it works, but I am curious if in this miner is some optimisations for scryptjane. It's aready optimized up to AVX2 so it's as good as it gets. Edit: Upon further analysis of the code scryptjane:18 might work for yac. When I first ported scryptjane I just did a quick functional test on Nicehash and it worked with default options. That was good enough and I Ieft it at that. I hadn't noticed that the default NF was 1024 which made no sense and that Nicehash was NF16. I'd like to retest at Nicehash with NF16 but the stratum is down due to lack of orders. I know nothing about scrypt so I have no idea of the effect of the wrong NF. If the wrong NF works maybe the right one works better. I'm not that interested in setting up a user on a yac pool just for a quick test but if it works for you I'd be curious. Thanks for your response. -a scryptjane:18 miner say "Unknown algo: scryptjane:18" -a scryptjane:16 seems to work, but as far I know, there is no coins at NF16 (LEOcoin switched to POS) to mine scryptjane need to use corect NF for respective coin Tue, 08 Aug 2017 16:15:28 GMT YAC NF will be 19 http://download.muuttuja.org/yacoin/countdown/ UTC will stay forever at NF 14 Are you sure the miner isn't expecting N instead of NF? So for NF18, maybe you should specify scryptjane:524288 instead (according to the table in the link you provided) That's part of it. There is inconsistent handling of N vs NF. The command line parser expects algo:n but scyptjane expects algo:nf. scryptjane:18 fails because it is not a power of 2. This is not an area I am familiar with so some suggestions are welcome. NF seems more user friendly than N. Is it a convention to use algo:n notation or is algo:nf acceptible? Can software reliably distisguish a NF spec from N spec by its value? For example if the value is not a power of 2 and is smaller than some limit it is interpreted as NF, else N. What would be that limit? Any personal preferences on how to handle it? -a algo:nf or -a algo -n nf I still don't understand why the default NF=1024 worked on Nicehash (Leo). This was actually interpreted as NF=2. As far as I know scryptjane is not scrypt:n, is not only to change N, is different algoritm, in scryptjane algo in miners need to put some aditional parameters --starttime --nfmin and --nfmax, to automaticaly calculate NF, but in some miners is manual you need to put NF --scryptjane:NF. In Nicehash miner v1.3.0.3 (cpuminer_x64_AVX.exe) scryptjane algo work corect with -a scyptjane:NF, (tested with YAC -a scryptjane:18) I mined LEO at NF 16 and before NF 15 ... 14..., but with GPU. If I put cpuminer with -a scryptjane (NF16) to YAC (NF18) miner work but submited shares is rejected. That where the confuision arises, scrypt:n vs scryptjane:nf. I can make the software work either way so that scryptjane:18 and scryptjane:524288 would both work. It's a simple conversion: N = 1 << (Nf+1). The only question is whether there is any overlap where the same value could represent both a valid N or Nf. Do you know the lowest N value and highest Nf? I don't like the automatic NF setting because it requires 3 parameters instead if 1. It may work well if always mining the same coin but is more complicated when switching coins. |
|
|
|
Is it only a CPU mining or also GPU?
If GPU mining : where to download GPU windows exe and what is the speed on RX480?
Thanks
cpuminer-opt is CPU only. You'll have to search for other threads for GPU miners. |
|
|
|
my problem on ubuntu done. but now. i can't mining BSD (xevan) on Windows. i download " cpuminer-multi-rel1.3" and edit info in "cpuminer-conf.json" file "url" : "stratum+tcp://yiimp.ccminer.org:3739",
"user" : "BSD add", when i run mining. it don't work. [2016-11-23 16:35:10] Starting Stratum on stratum+tcp://yiimp.ccminer.org:3739
[2016-11-23 16:35:11] Stratum difficulty set to 0.125 fail to connect stratum. i need help. thanks you! I don't see a problem. If the stratum set difficulty it's connected. What happened after that? |
|
|
|
I know this old miner, it works, but I am curious if in this miner is some optimisations for scryptjane. It's aready optimized up to AVX2 so it's as good as it gets. Edit: Upon further analysis of the code scryptjane:18 might work for yac. When I first ported scryptjane I just did a quick functional test on Nicehash and it worked with default options. That was good enough and I Ieft it at that. I hadn't noticed that the default NF was 1024 which made no sense and that Nicehash was NF16. I'd like to retest at Nicehash with NF16 but the stratum is down due to lack of orders. I know nothing about scrypt so I have no idea of the effect of the wrong NF. If the wrong NF works maybe the right one works better. I'm not that interested in setting up a user on a yac pool just for a quick test but if it works for you I'd be curious. Thanks for your response. -a scryptjane:18 miner say "Unknown algo: scryptjane:18" -a scryptjane:16 seems to work, but as far I know, there is no coins at NF16 (LEOcoin switched to POS) to mine scryptjane need to use corect NF for respective coin Tue, 08 Aug 2017 16:15:28 GMT YAC NF will be 19 http://download.muuttuja.org/yacoin/countdown/ UTC will stay forever at NF 14 Are you sure the miner isn't expecting N instead of NF? So for NF18, maybe you should specify scryptjane:524288 instead (according to the table in the link you provided) That's part of it. There is inconsistent handling of N vs NF. The command line parser expects algo:n but scyptjane expects algo:nf. scryptjane:18 fails because it is not a power of 2. This is not an area I am familiar with so some suggestions are welcome. NF seems more user friendly than N. Is it a convention to use algo:n notation or is algo:nf acceptible? Can software reliably distisguish a NF spec from N spec by its value? For example if the value is not a power of 2 and is smaller than some limit it is interpreted as NF, else N. What would be that limit? Any personal preferences on how to handle it? -a algo:nf or -a algo -n nf I still don't understand why the default NF=1024 worked on Nicehash (Leo). This was actually interpreted as NF=2. |
|
|
|
I know this old miner, it works, but I am curious if in this miner is some optimisations for scryptjane. It's aready optimized up to AVX2 so it's as good as it gets. Edit: Upon further analysis of the code scryptjane:18 might work for yac. When I first ported scryptjane I just did a quick functional test on Nicehash and it worked with default options. That was good enough and I Ieft it at that. I hadn't noticed that the default NF was 1024 which made no sense and that Nicehash was NF16. I'd like to retest at Nicehash with NF16 but the stratum is down due to lack of orders. I know nothing about scrypt so I have no idea of the effect of the wrong NF. If the wrong NF works maybe the right one works better. I'm not that interested in setting up a user on a yac pool just for a quick test but if it works for you I'd be curious. |
|
|
|
Hi. How to use cpuminer-opt for scryptjane algo at NF 18?
Did you try "-a scrytpjane:18" ? Edit: That's not going to work. The Nf code is messed up. By default it runs scrypt(N,1,1) with N=2 which works on Nicehsash scrytjanenf16. Looking at the code I have no idea why it works and Nicehash is down due to lack of orders. If you know of anywhere I can test I can play with it. Thanks for your response. YAC pool (NF 18) http://yac.yacoin.club/UTC pool (NF 14) http://utc14.yacoin.club/Best regards. Have you tried this... https://bitcointalk.org/index.php?topic=1120634.msg12684868#msg12684868It looks like the same code I'm using except it sets the N factor automatically. |
|
|
|
Hi. How to use cpuminer-opt for scryptjane algo at NF 18?
Did you try "-a scrytpjane:18" ? Edit: That's not going to work. The Nf code is messed up. By default it runs scrypt(N,1,1) with N=2 which works on Nicehsash scrytjanenf16. Looking at the code I have no idea why it works and Nicehash is down due to lack of orders. If you know of anywhere I can test I can play with it. |
|
|
|
Is there an nvidia GPU miner for Zcoin? It's some sort of lyra2 variant.
Zcoin just tweaked their version of Lyra2 and are planning to change to MTP. That will be its fourth algo in its short life. There is no GPU miner for Zcoin. |
|
|
|
|
cpuminer.exe --help. Get the parameters from from the pool you want to mine.
|
|
|
|
Zcoin-xzc Algo was modified after block 8192 - lyra2z
It's not worth making the change, it will change again soon to something completely different. For those who compile their own it's a one line change in algo/lyra2/zcoin.c line 11: old: LYRA2Z(hash, 32, input, 80, input, 80, 2, height, 256);
new: LYRA2Z(hash, 32, input, 80, input, 80, 2, 8192, 256);
Ok, works fine : thank you :-). Any future optimisation for ZCoin ? We'll see when MTP comes out. If I have a good reason to release a new version before then it will include the above change. |
|
|
|
Zcoin-xzc Algo was modified after block 8192 - lyra2z
It's not worth making the change, it will change again soon to something completely different. For those who compile their own it's a one line change in algo/lyra2/zcoin.c line 11: old: LYRA2Z(hash, 32, input, 80, input, 80, 2, height, 256);
new: LYRA2Z(hash, 32, input, 80, input, 80, 2, 8192, 256);
|
|
|
|
i have taken a screen of the interesting part:  There's likely an unallocated stratum session id variable with value "deadbeef......" Like I said in my previous reply, very strange. Hex code that form highly visible words are often used to help debugging by making invalid data stick out in a hex dump. Those hex tags are very useful. The specific deafbeef tag was used in a product I supported and got us into trouble when we tried to sell to India. I this case deadbeef is used to initialize a local variable in uint256 code only used by the non-optimized hodl code. In other words this code does not get run on a 4770K. The invalid session id also contains two other hex tags: cafe & babe, that are only used in hamsi code which isn't used by hodl. It is also interesting that a valid share was hashed with the apparently invalid session id. These three observations are not related to each other and don't appear to be related to the crash which tells me process was corrupt. Either the program file is corrupt or the CPU is corrupting data. Since your system is running I assume the CPU is ok. Try downloading a fresh copy. I've had no other complaints about the download so it should be ok. |
|
|
|
Why it crashes with HODL?  I have i74770K (Haswell). Because you're doing something wrong. If you want a better answer, ask a better question. Back, sorry if I did not left enough info. I'm just doing the same that works for cpuminer-opt-3-3-8-windows version, that version is around half slower than cpuminer-opt-3.4.11-windows. I'm trying to mine here https://erc.suprnova.cc/index.php?page=dashboardHowever works as benchmark mode. My bat line is cpuminer-core-avx2 -a hodl -o stratum+tcp://erc.suprnova.cc:7674 -u Username.Worker -p x -t 7 -D pause Here is a video http://tinypic.com/player.php?v=1znv5hs%3E&s=9#.WC5TAWfrtkgThat's strange. Hodl was recently optimized with AVX2 but a 4770K supports it so it should work. I tested at Suprnova with a 4790K and it works fine with the AVX2 build. It looks like an issue with your CPU. Did you try any of the other builds? That will tell you if your CPU has AVX2 working. You could also test with another algo that uses AVX2 such as X11 or Lyra2REv2. I don't like unknown media sites so I didn't look at your video. It's better to just copy/paste or screenshot the text from the command window. |
|
|
|
Are there any improvements to make by building it with gcc-6 over gcc-4?
Some people have reported problems with newer compilers, one that comes to mind is -flto option seems to fail to break the compile. I don't have a GCC 6 build environment yet so I have no comparative performance data. It is my feeling there would be little miner performance gain from compiler improvements because most miner optimizations use ASM or intrinsic functions for the time critical code. Feel free to try and report your results. |
|
|
|
Why it crashes with HODL? I have i74770K (Haswell). Because you're doing something wrong. If you want a better answer, ask a better question. |
|
|
|
I've encountered the problem with all later versions of ccminer(tpruvot), which came out after ~April-May, 2016.
That's around the time he switched to using Cuda 8.0. You are probably better off with Cuda 6.5 for older algos that haven't been optimized for Cuda 8. |
|
|
|
|
I don't understand why people would buy new equipment for a new coin when they already have suitable equipment.
It's not like buying a new dress for a big night out. Then again I don't like Kool-Aid either.
|
|
|
|
Just put 2 more RX480 and started getting this: [ 327.726578] VM fault (0x02, vmid 2) at page 1641426, read from 'TC4' (0x54433400) (72)
[ 327.726582] amdgpu 0000:03:00.0: GPU fault detected: 147 0x07c84802
[ 327.726597] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001A82F1
[ 327.726613] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048002
[ 327.726629] VM fault (0x02, vmid 2) at page 1737457, read from 'TC4' (0x54433400) (72)
[ 327.726634] amdgpu 0000:03:00.0: GPU fault detected: 147 0x01484802
[ 327.726648] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0017865A
[ 327.726664] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048002
[ 327.726680] VM fault (0x02, vmid 2) at page 1541722, read from 'TC4' (0x54433400) (72)
[ 327.726684] amdgpu 0000:03:00.0: GPU fault detected: 147 0x08304802
[ 327.727325] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001BCEF3
[ 327.727865] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048002
[ 327.728406] VM fault (0x02, vmid 2) at page 1822451, read from 'TC4' (0x54433400) (72)
[ 327.728411] amdgpu 0000:03:00.0: GPU fault detected: 147 0x07d04802
[ 327.728943] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001B280A
[ 327.729472] amdgpu 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04044002
[ 327.729998] VM fault (0x02, vmid 2) at page 1779722, read from 'TC5' (0x54433500) (68) I've installed some old powered PCIe risers which are non usb/nor original asrocks but cards are recognized. Additional power to the motherboard H81 Pro BTC is not installed...may that be the problem? It's not so often but a few times every 10mins... and mostly doesn't seem to stop mining unless it completely freezes. ASROCK STATES THAT THE TWO MOLEX POWER CONNECTIONS MUST BE USED-- The auxilliary mollex power connecters are not an option, according to the manual. I know board chat goes either way, but non-powered ribbon risers are dangerous and flammable. --scryptr The on board power connectors shouldn't be an issue because powered risers don't draw any power from the mobo. It doesn't mean it's not a power issue. If your PSU is multi rail make sure the distribution is balanced. Is it same GPU every time? Intermittant nature suggests a bad connection, ie bad riser. |
|
|
|
Well depends on the view..90sol/s on a GTX1070 is fast no question.
And it seems to change from day to day. The competition is great, I've never seen so many publicly available miners for a new algo. |
|
|
|
thanks but it doesn't start any kernel on the devices. no ram usage, nothing. ubuntu 16.04, cuda 8. do I need cuda 7.5? I believe SA is all OCL. Why not use the entire SA miner instead of a transplanted kernel? Krnlx said his cuda port is faster. README.md says otherwise. |
|
|
|
|
Show Posts
