Looking for instructions on how to enable MADV_HUGEPAGE on Centos 6.5 , anyone ??
You can't, because CentOS is garbage. I had to add in a flag to disable some optimizations for that shit OS. I know it is, is there any other way to get it to run on centos ? If i compile on ubuntu and run on centos it complains about glibc version (2.14 required, centos runs 2.12). Any other way ? Is it possible to include glibc in the static binary ? EDIT : Removing MADV_HUGEPAGE from cpu-miner.c fixes the problem but with a significant loss in speed. I need the extra speed!! the static binary can include everything. did you try: ./configure --enable-static or CFLAGS='-static' ? |
|
|
|
|
My node went on a wrong fork again! :-(
|
|
|
|
|
Danbi! The difficulty on the pool dropped! Did it get into a wrong fork?
|
|
|
|
|
is it safe to replace connect with addnode now, or better wait?
i'd be happy to contribute a clean node to the network.
|
|
|
|
Did you not just illustrate the problem here? Everyone's diamond.conf was configured with a single addnode. All the attacker had to do was compromise the block chain at 193.68.21.19 and the whole diamond network was forked.
Unless it is in fact a bug as polanskiman is suggesting.
In any case, wouldn't it be a good idea to do away with the single point of failure and let the network be decentralized as it was designed to be? Remove all "addnodes" and "connect" as well as remove the "listen=0" and "noirc=0" statements and let the software do it's thing to find out on it's own which chain to use?
no, most wallets didn't have addnode or connect because it's isn't on by default. also please understand the difference between addnode and connect. some people added connect or addnode to try to be on the right chain AFTER the attack, as danbi suggested, and it worked. now when it's stabilised, everybody will remove the connect and eventually keep addnode. |
|
|
|
|
I've experienced this error:
diamondd: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
A couple times when stopping the daemon.
|
|
|
|
Is there a problem on your diamond pool?. Autopayouts are down.
Nothing for july 31..actually last payout was 9 pm july 30 on one machine.
Another machine after 8 hours 14 blocks and Nothing.
there was an attack on diamond. srcxxx please check your wallet. |
|
|
|
Instead of providing the documents on headless client compilation as promised, I will save the hassle to the interested people by sharing statically compiled binaries. I have successfully built the wallet using gnuroot and the Debian weezy image on a nexus 5 phone. It should work on most android devices and I have tested it with success on the qnap nas. Unfortunately there doesn't seem to be any performance advantage even though the compiler used is much newer than the qnap native one (gcc 4.6 vs 4.2). Here is the link to the public folder containing the wallet: https://www.dropbox.com/sh/si94t02tb8fjcq6/AAANVDqdx8FpnAeQRcNX5wOdaIf there is interest, I can write a doc on how to run on android, even though it'll never be simple, unless there is a GUI to use it with. Donations: dVrz69vZFrxJRH9AnKyHim7Hd3PhY3w9NQ |
|
|
|
|
What is the correct way of building the static headless client?
I've tried:
make STATIC=1 -f ....
with or without -static-libgcc and -static-libstdc++
but it doesn't statically link libc and libgcc,
with STATIC=all
it fails on linking libgcc_s
but before I go on linking manually or whatever, maybe it's easier than that...
EDIT: got it! this is the working commandline:
LDFLAGS='-static-libgcc' STATIC='all' make -f ....
|
|
|
|
Whereabouts do I need to put the "--disable-aes-ni" when compiling?
./autogen.sh CFLAGS='-march=native' ./configure --disable-aes-ni make -j<numberofcores> possibly "make clean" before "make" |
|
|
|
minerd-wolf-07-09-14 hits me hard with a decrease in performance. ~120 h/s
using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s
CPU is a 12 core Xeon E5-2430 V2 Is this expected?
are you sure you are using the same number of threads in both cases? |
|
|
|
Quite interested in having a purely OpenCL miner. I know Claymore is OpenCL, but it only works with AMD GPUs. The Intel HD series of GPUs are very poor I know, but they too utilize OpenCL - for those of us that are hoping to squeeze every little last bit from our systems using the onboard GPU would be very advantageous.
So you mean that I can use both AMD GPU and Intel HD graphics for mining on one computer? And your CPU, yes. They are separate devices with separate resource pools, despite the Intel HD GPU being on the same unit as the CPU. I have read up on it and other coin algos have miners for the Intel HD series and the use of it doesn't impact the CPU mining speed. Miner for Intel HD? Rough estimate on h/s on 4000/5000? on scrypt, gpu mined slower than cpu. but probably using less power. |
|
|
|
|
using yam miner:
[2014-07-22 13:12:10.856241] [0x00000000001df98c] [error] Error: boost::bad_any_cast: failed conversion using boost::any_cast
no sources, no recompile... any way to fix?
|
|
|
|
|
Any chance this will work on arm?
LucasJones version doesn't work either, the cryptonight part fails to link. I believe the problem is missing aesb-arm.S in that case.
Can't find the bitcointalk thread for it, though.
|
|
|
|
thanks for the answer.
a couple questions:
should cpu usage go down when coinage of my coins is over?
the cpu of my nas is very weak (currently at 70% usage): if I get more coins in the future, will I risk not being able to mint any longer?
If I remember right, the compiler you used is an older one (gcc 4.2.1?) -- this means much less optimizations and you might have resorted to -O0 to make it run. Compiler optimizations make very big difference. The wallet tries to pace down the PoS hashing, but it still has to do calculations. When you have more eligible coins, it wastes more CPU. When you have more addresses within the wallet, it wastes more CPU. Therefore, when you mint your coins, for a period of time you will have lower CPU usage. Look at compiler optimizations first  I used to compile it with the default setting of -O2. Just tried with -O3 but I don't see any difference. Maybe I should compile a newer gcc but it will take ages! Cpu usage has gone up a bit further (maybe the PoS difficulty has risen) and now it takes the whole cpu time; stakepower is going up so I think my NAS is done. That's a pity because it was a good node. Danbi do you think there is room for improvement on PoS minting performance? Is there something I can do or try? I'm a good C programmer and, if you can point me to the relevant code, I can try to make some modifications. |
|
|
|
|
devs need to speak or everydody will drop very soon.
nothing's worse than a coin with no support and with broken promises (PoS, at least).
|
|
|
|
|
just wanted to say that if you run on a single core cpu, by default it does nothing:
0 miner threads started, using 'cryptonight' algorithm
1 - 1 = 0 :-D
|
|
|
|
Why this one and not a larger exchanger? Bitcoin marketsBTC Market 24h volume: 0.06 BTC Seriously.. Because it's new :-) Let's get it started. |
|
|
|
We are already in PoS phase, no?
Yep from OP it seems so: PoW/PoS hyrbid after Block: 150000 Has anyone actually got a PoS block? I don't think the current wallet features PoS. I believe it's still in development (or not?). |
|
|
|
|
Show Posts
