also i just remembered the mysterious bug/error where cpuminer-opt would crash in my lxc containers with a buffer overflow, its not happening anymore, seems it was indeed some lxc or kernel related issue edit: it might also be related to me not catching the stdout/stderr when spawning cpuminer-opt as a child process, anyways its working now  |
|
|
|
What options? I will try to build it with those optoins on my Intel and see if it works well on your AMD.
you can compile with: "-maes -mavx", this results an a binary with sse2, aes and avx support (none of my amd cpus has avx2) ill gladly test it on a side note: benchmark of lyra2z was broken in ocminers miner and yours as well, are you planning on fixing it or just wait till mpt (or whatever the new zcoin algo is named) gets released? |
|
|
|
joblo, regarding compiling, is there anything up against replacing the windows compiles with "-march=<some march>" by compiles with just the extensions added (-msse2/-maes/-mavx/-mavx2) like nicehash does it for their compiles? would boil the resulting bins down to essentially 3 or 4 and the right one can easily be identified
cheers
My intent is to do something similar but continue to compile on architecture boundaries instead of cherry picking features. If I ignore the manufacturer differences there are 4 levels I want to support: SSE2, +AES, +AVX, +AVX2. Unfortunately Westmere doesn't have its own compile arch defined but is SSE4.1+AES. I am targetting redundant builds one at a time. For AMD I'm relying on your advice of what special AMD builds would be useful, meaning there isn't a compatible Intel build with the same critical features. I would also need to be able to build it which could be an issue. For now I'm targetting btver1. Any reason to keep it? for cryptonight the difference between a native amd compile and a generic "-maes -mavx" compile is minimal, like sub 10 H/s for lyra2re the difference was (afaik) larger, however all other compiles packaged resulted in even worse performance for zcoin the difference is not observable as a conclusion best amd compile is native, and after that a generic with -m flags I can't build native for any AMD arch, that's why I want to know which don't have an equivalent Intel build. yes i know there is no native compile, best compile for my fx and a6/a10 cpus was a generic compile (after native), every one of the intel compiles was slower than the generic one |
|
|
|
thanks, it seems a bootstrap file is just all blk files concatted, as there is only one till now this one should suffice (blk00000.dat) |
|
|
|
can any one pls upload Zcoin data blocks to sharing file and post link here? sync wallet its very loooong  how do i do that? He's asking for a bootstrap! Sync is slow... and im asking how to create a bootstrap as my wallet is synced |
|
|
|
can any one pls upload Zcoin data blocks to sharing file and post link here? sync wallet its very loooong how do i do that? |
|
|
|
joblo, regarding compiling, is there anything up against replacing the windows compiles with "-march=<some march>" by compiles with just the extensions added (-msse2/-maes/-mavx/-mavx2) like nicehash does it for their compiles? would boil the resulting bins down to essentially 3 or 4 and the right one can easily be identified
cheers
My intent is to do something similar but continue to compile on architecture boundaries instead of cherry picking features. If I ignore the manufacturer differences there are 4 levels I want to support: SSE2, +AES, +AVX, +AVX2. Unfortunately Westmere doesn't have its own compile arch defined but is SSE4.1+AES. I am targetting redundant builds one at a time. For AMD I'm relying on your advice of what special AMD builds would be useful, meaning there isn't a compatible Intel build with the same critical features. I would also need to be able to build it which could be an issue. For now I'm targetting btver1. Any reason to keep it? for cryptonight the difference between a native amd compile and a generic "-maes -mavx" compile is minimal, like sub 10 H/s for lyra2re the difference was (afaik) larger, however all other compiles packaged resulted in even worse performance for zcoin the difference is not observable as a conclusion best amd compile is native, and after that a generic with -m flags |
|
|
|
|
joblo, regarding compiling, is there anything up against replacing the windows compiles with "-march=<some march>" by compiles with just the extensions added (-msse2/-maes/-mavx/-mavx2) like nicehash does it for their compiles? would boil the resulting bins down to essentially 3 or 4 and the right one can easily be identified
cheers
|
|
|
|
I have encrypted DOGE wallet from 2014,without privatekey and without password.
Do not repeat my mistake.
good old doge days have some myself, too bad they are worth nothing now |
|
|
|
|
its fun to mine with asics, roi for myself is 8-10 months, but i dont care if its longer, its not like its producing a lot of heat so it can run during summer when my gpu rigs are sold and not running
second mini miner incoming with this new batch
|
|
|
|
tried cpuminer-xzc, it shows weird (?) 220-230 kh/s hashrate but a pool shows about 60-70 h/s, 48 threads
are you referring to ocminers cpuminer-xzc or cpuminer-opt by joblo? please share the parameters used to start the miner for further debug, might just be a wrong algo specified |
|
|
|
to me are mostly fx 8350 and a few pieces i5 1156 e now in this the miner shows me the h / s eg Fx 8350 accepted 367H, 6,84H / s if this is normal
I can't say what's normal for AMD but your CPU has AES and AVX so you might get better performance using an Intel build (assuming you're using the binaries) with those features, depending on the algo. those where the numbers i got, amd is pretty weak in zcoin algo, though they change it to mpt soon, so that might change |
|
|
|
cpuminer 3.4.8 is released. Source code: git: https://github.com/JayDDee/cpuminer-opttarball: https://drive.google.com/file/d/0B0lVSGQYLJIZMnVmX0Qwcjg1cmc/view?usp=sharingWindows binaries https://drive.google.com/file/d/0B0lVSGQYLJIZQkRWSEx1WVNOaWs/view?usp=sharingIt adds support for zcoin lyra2 using either "-a zcoin" or "-a lyra2z". Lyra2RE (lyra2) and lyra2REv2 (lyra2v2) still work as usual. Although I have optimixed it for AVX2 there was no observable change in performance in my testing. I suspect the algo is I/O bound meaning the CPU spends a lot of time waiting on data from memory. LGA2011 systems with 4 channel DDR may do better. Feedback is appreciated. The diff display for cryptonight in the API has been fixed. Changes in diff will now be displayed by default (--show-diff). Use "--hide-diff" to disable. Removed some cpuminer-multi artifacts. I am considering dropping the btver1 build from the Windows binaries package. Before I do so I would like to know if anyone is using it and whether it performs better on an AMD CPU than any of the Intel builds. The btver1 build does not include any optimizartions so is not suitable for recent AMD CPUs. testing, thanks! version reports 4.3.8-dev, is this intended for releases? (also 3 and 4 are swapped it seems) |
|
|
|
small question regarding the wallet: every time i start it it keeps "reindexing blocks" starting from block 0 till current block, this process takes quite some time. i have not seen this in other wallets from different coins, is this true for everybody, or is it just me (tried with windows and linux)? seems rather odd to have to wait for every block ever created to be processed each time the wallet is started.
same here.. Wallet seems to be stuck on block 2625 here. Very frustrating. I encountered no problem so far when i compiled mine. use dev branch. git clone -b dev https://github.com/zcoinofficial/zcoin.gitill try that, lets hope the best The devs warned us not to compile from the dev branch. I guess we just have to wait.... What sort of warning he gave? This build does not reindex but i do notice when it fetches new block and scryptminer initiates, shows the hashmeter, then after that shows zero hash when you call gethashespersec. I do wonder if the cpuminer can be pointed to the wallet? any ideas felix? can confirm current dev branch does not reindex, i suppose this patch will be included in the next regular release |
|
|
|
small question regarding the wallet: every time i start it it keeps "reindexing blocks" starting from block 0 till current block, this process takes quite some time. i have not seen this in other wallets from different coins, is this true for everybody, or is it just me (tried with windows and linux)? seems rather odd to have to wait for every block ever created to be processed each time the wallet is started.
same here.. Wallet seems to be stuck on block 2625 here. Very frustrating. I encountered no problem so far when i compiled mine. use dev branch. git clone -b dev https://github.com/zcoinofficial/zcoin.gitill try that, lets hope the best |
|
|
|
small question regarding the wallet: every time i start it it keeps "reindexing blocks" starting from block 0 till current block, this process takes quite some time. i have not seen this in other wallets from different coins, is this true for everybody, or is it just me (tried with windows and linux)? seems rather odd to have to wait for every block ever created to be processed each time the wallet is started.
same here.. Wallet seems to be stuck on block 2625 here. Very frustrating. actually i dont think its stuck, there are some points where the level db much likely has to increase in size and these are the points its stuck. however this reindexing should only occur on broken blocks not sure why this is happening here |
|
|
|
|
small question regarding the wallet: every time i start it it keeps "reindexing blocks" starting from block 0 till current block, this process takes quite some time. i have not seen this in other wallets from different coins, is this true for everybody, or is it just me (tried with windows and linux)? seems rather odd to have to wait for every block ever created to be processed each time the wallet is started.
|
|
|
|
I'm aware but there is some stuff in the backend (statistics) that break completely when I bump that decimal. Since the algo will be changing to mtp anyway it's not worth the hassle now if I have to change it again later IMHO.
i see it the same way, just fyi, did not know you are already aware  |
|
|
|
|
Show Posts
