crashes for me (ubuntu 16.04). All hail the nix master race! You should ask him what distribution he has and dependencies so you can install exactly what he has to get it working. ~_~ Surprised Nicehash hasn't torn it apart yet for the tasty bits. he uses 14.04 |
|
|
|
|
is there any api for stats planned? like workers, balance, etc
|
|
|
|
Hi all,
2 questions please about ZCoin mining :
1) Is there others optimized miners than the CPUMiner from OCMiner (SuprNova) ? Windows ? Ubuntu ?
2) Is there some project(s) of GPUs Miners ? Windows ? Ubuntu ? AMD ? NVidia ?
Thank you :-)
You can try this one which has slight improvements to it: https://github.com/Optiminer/cpuminer-xzcNo GPUminers. I've also spoke to the core devs on this and they confirm that they're working on MTP algorithm. i recommend everyone to use joblos miner, it contains optiminers avx2 improvements and displays H/s |
|
|
|
|
currently zcoin or cryptonight coins, depends on your cpu. thats what im mining
|
|
|
|
is github down right now folks ?
dyndns was/is under ddos attack |
|
|
|
My mistake, I was assuming shared memory.
ah yes, with shared memory a second cpu would not speed things up i suppose shared memory only exists in specific systems nowadays? |
|
|
|
Given the 12 thread performance was similar to 48 it looks like it was using both CPUs. With only one CPU I would expect the
performance to drop by half.
I take that back. Adding another CPU doesn't increase memory bandwidth. A dual CPU is overkill, an i7 is overkill. The only way
to improve performance is with LGA2011 which has a 4 channel memory controller.
afaik each cpu has its own memory, so using multiple cpu actually should multiply the hashpower by the amount of cpus used. if one cpu wants to access the memory of another cpu it would need to do so via qpi. each memory bus per cpu is unique and shouldnt slow down other cpus, only qpi access slows down significantly. increasing cpu <-> memory speeds should also increase the hashpower That wasn't the point. A single CPU has access to 4 memory channels instead of 2 doubling the memory bandwidth, The 2nd CPU is still overkill. i dont seem to understand your point taken a system with multiple (say 2) cpu sockets exists and both cpus are present: - each cpu has dual or quad memory channel (if its dual or quad doesnt matter in this scenario) - each cpu gives X H/s, like a normal single cpu system would, just two cpu+ram on one mobo - each cpu uses their own dual/quad memory channel using one cpu produces X H/s, using both cpu produces 2x X H/s taken a system with a single cpu socket exists: - the cpu has dual memory channels upgrading the dual channel to quad channel through a mobo/cpu upgrade results in (likely) doubled hashrate im missing the point where a second cpu doesnt speed up the total hashrate of the system if the second cpu has its own memory channels or do you imply the one cpu should use the other dual channel memory for the other cpu and thus doubling its memory bandwith? cause that wont work afaik |
|
|
|
18H/s on a 6700K, I wonder what's the daily income for that hashrate.
yeah that's what I get with the default miner not the one linked in the last few threads , pretty pathetic hashrate imo well the algo is memory limited, what did you expect? |
|
|
|
Given the 12 thread performance was similar to 48 it looks like it was using both CPUs. With only one CPU I would expect the
performance to drop by half.
I take that back. Adding another CPU doesn't increase memory bandwidth. A dual CPU is overkill, an i7 is overkill. The only way
to improve performance is with LGA2011 which has a 4 channel memory controller.
afaik each cpu has its own memory, so using multiple cpu actually should multiply the hashpower by the amount of cpus used. if one cpu wants to access the memory of another cpu it would need to do so via qpi. each memory bus per cpu is unique and shouldnt slow down other cpus, only qpi access slows down significantly. increasing cpu <-> memory speeds should also increase the hashpower |
|
|
|
@felix
you mean your fork or joblo's one?
btw i got 256 gb of ram on that dual xeon server
will follow your advices later...
i only have a copy of the src in my github acc, no modifications made, im talking about joblos cpuminer-opt the amount of memory is largely irrelevant, its more the speed from cpu to memory that dictates the hashpower my xeon e3 has 8 cores, though using more than 4 cores does not result in more hashpower with 2x 24 threads (2 cpu) i assume the optimum thread count per cpu is about 6-10, maybe a bit more or less depending on the power of each individual core now on linux placing procs on specific cpus is easy, not sure how to do this on windows. im unsure how cpuminer-opt handles the placement of threads in a multi cpu environment, if you only specify 12 threads (6 per cpu) it might spread them on cpu0 and cpu1, but it might also spread them only on cpu0 which would result in only half the hashpower |
|
|
|
|
yup those numbers could add up to the actual hashrate, try with very low core nums like 3,4,5 and post the results, this algo is very memory bound, more cpu power doesnt speed things up but can make things worse actually
also if this system is using multiple cpu you will need to spread the few threads on the other processors to achive maximum hashpower (to use multiple memories), i dont know if this is possible with plain threads (procs work fine) other option would be to start multiple cpuminer for each cpu with low thread count
|
|
|
|
what about renaming the binaries to the corresponding arch? 4.8.x didnt include this (thats why you where not able to compile westmere, or in general other arch's by their name) gcc 4.8.5, 4.9.4, 5.4.0 and 6.2.0 indicate the following: core2 == core2 corei7 == nehalem corei7-avx == sandybridge core-avx-i == ivybridge core-avx2 == haswell missing in 4.8.x: westmere (4.9.4) broadwell (4.9.4) skylake (6.2.0) i suppose there is no easy way to upgrade gcc in a mingw environment on windows, im using gnustep which is the current version and only ships with gcc 4.8.x sadly i also attempted cross compiling but ran into issues with linking the libs in the last step, has anybody done that before? |
|
|
|
i did not find anything using google and the faq, i accidentally minted a zerocoin, does this apart from the transaction fee result in a loss of xzc when converting back after 7 confirmations?
That's the way to obfuscate the originating UTXO! You sent your coin to the accumulator, made a Zerocoin and once you convert it back to XZC you have a brand new looking, shiny XZC (minus tx fee). At least that's how I understood the white paper. its working exactly like this, thanks just "spent" the matured zerocoin and have 1 xzc as unconfirmed incoming |
|
|
|
|
i did not find anything using google and the faq, i accidentally minted a zerocoin, does this apart from the transaction fee result in a loss of xzc when converting back after 7 confirmations?
|
|
|
|
Last Block Found 3,891 Time Since Last Block 1 hour 24 minutes 50 seconds  Something is not right I think. No pool,no big hash,slowest block found wait until self-regulating algorytm stabilize to current power. i dont understand, can you elaborate? |
|
|
|
I compiled the new wallet from git.
ubuntu 16.04.
first time it loaded, then I did "setgenerate true" and it crashed:
terminate called after throwing an instance of 'std::runtime_error'
what(): CreateNewBlock() : ConnectBlock failed
after that, every time I load the wallet it hangs on:
init message: Loading wallet...
using 100% cpu.
then I need to kill it with SIGKILL.
did you use the latest git commit (5hrs ago)? i read something about a broken function when mining today in the telegram chat which got pushed to git afaik |
|
|
|
@ocminer: is this orphan rate valid? seems a bit high  |
|
|
|
|
here are the results (surprised me that the packaged builds did better on lyra2*, last time i tested them they where worse):
fx-8320e:
lyra2re:
aes-avx: 396kh/s
corei7-avx: 412kh/s
core-avx-i: 411kh/s
lyra2rev2:
aes-avx: 539kh/s
corei7-avx: 568kh/s
core-avx-i: 568kh/s
cryptonight (8 threads):
aes-avx: 229h/s
corei7-avx: 228h/s
core-avx-i: 229h/s
cryptonight (7 threads):
aes-avx: 231h/s
corei7-avx: 230h/s
core-avx-i: 229h/s
a10-6800k:
lyra2re:
aes-avx: 311kh/s
corei7-avx: 314kh/s
core-avx-i: 317kh/s
lyra2rev2:
aes-avx: 344kh/s
corei7-avx: 364kh/s
core-avx-i: 364kh/s
cryptonight (4 threads):
aes-avx: 48h/s
corei7-avx: 47h/s
core-avx-i: 47h/s
cryptonight (3 threads):
aes-avx: 56h/s
corei7-avx: 58h/s
core-avx-i: 58h/s
|
|
|
|
|
Show Posts
