Reducing CPU usage while accepting new block.
It is indeed a lot faster when accepting blocks, that's really what was needed, great! :-) But it will need to be tested and hard limits removed. Currently my test wallet hanged on trie sync, not necessarily related to the patch. Trie sync issue is another problem, but I never seen it, when I force wallet to sync from one node (connect=xcn.suprnova.cc). Thanks, I will try this. Maybe the faster AcceptBlock (which is actually a faster Activate), since it should speedup getslice as well, may make the trie sync issue much less common. Thus, when the network is updated, it may go away by itself. So people please test the krnlx patch to death, and also we need to set a much higher hard limit for block number or make it dynamic (without this we can't push the improvement to production). |
|
|
|
GUIDE: Compiling xcn wallet with TCMALLOC allocator.
Thanks for this guide! I linked it on the first post, if you don't mind. |
|
|
|
Hi,is it possible to solo mine? suprnova disconnect too often.
my conf is
" rpcuser=rpcuser
rpcpassword=rpcpass
rpcport=14443
listen=1
server=1"
after I started ccminer,It shows "No payout address provided,switchin to network",is it ok?
thanks.
Getwork, yes it's correct. |
|
|
|
|
Sorry if this has already been asked.
Bytes and blackbytes are two different currencies, right?
Then why do I need bytes to send blackbytes? Can't the fees be paid in blackbytes?
|
|
|
|
Reducing CPU usage while accepting new block.
It is indeed a lot faster when accepting blocks, that's really what was needed, great! :-) But it will need to be tested and hard limits removed. Currently my test wallet hanged on trie sync, not necessarily related to the patch. |
|
|
|
wallet takes 10 min to start, after sync it takes 6+GB RAMM + CPU load very huge  are you talking about the standard wallet or the new krnlx patch? the standard wallet takes less than 1GB on my machine. |
|
|
|
Reducing CPU usage while accepting new block.
I mean did you measure the time difference? |
|
|
|
With Valgrind/callgrind I found bottlenecks, related to slow block accept in cryptonite wallet. THIS IS ONLY FOR TESTING. IT IS DIRTY, AND WALLET WILL CRASH AFTER BLOCK 2097152https://github.com/krnlx/Cryptonite/commit/d0363d10ffa8d8cf1fa9e3d1749408827aed8961//TODO 1. Test everything many times : sync, sync from scratch, from snapshot, etc, mining, transactions 2. Automatic memory size adjustment of MAX_BLOCK 3. Reducing SAFE_UNIQ 4. Test again. Thanks very much! What kind of improvement are you getting with this patch? I will test it ASAP! :-) |
|
|
|
New blockchain snapshot posted: https://mega.nz/#!lAQFVaib!IZSFnI_QXdukM6Mc3qVa9Jy9wIeSYwkG7dkoNDLtVbE |
|
|
|
Version 1.2 is strongly outdated (2014 year)
Crash in compilation on Linux Mint 18.1 x64
at this moment i don't have a nvidia card. Can i compile without videocard Nvidia using MESA.?
mv -f .deps/ccminer-scrypt.Tpo .deps/ccminer-scrypt.Po
gcc -DHAVE_CONFIG_H -I. -msse2 -fopenmp -pthread -fno-strict-aliasing -I./compat/jansson -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME -g -O2 -MT ccminer-sha2.o -MD -MP -MF .deps/ccminer-sha2.Tpo -c -o ccminer-sha2.o `test -f 'sha2.c' || echo './'`sha2.c
mv -f .deps/ccminer-sha2.Tpo .deps/ccminer-sha2.Po
nvcc -g -O2 -I . -Xptxas "-abi=no -v" -gencode=arch=compute_30,code=\"sm_30,compute_30\" -gencode=arch=compute_35,code=\"sm_35,compute_35\" --maxrregcount=80 --ptxas-options=-v -I./compat/jansson -o heavy/heavy.o -c heavy/heavy.cu
/bin/bash: nvcc: команда не найдена
Makefile:1434: ошибка выполнения рецепта для цели «heavy/heavy.o»
make[2]: *** [heavy/heavy.o] Ошибка 127
make[2]: выход из каталога «/media/user/F/Work/Mining/ccminer/ccminer-1.2»
Makefile:1002: ошибка выполнения рецепта для цели «all-recursive»
make[1]: *** [all-recursive] Ошибка 1
make[1]: выход из каталога «/media/user/F/Work/Mining/ccminer/ccminer-1.2»
Makefile:440: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2
user@PC1 /media/user/F/Work/Mining/ccminer/ccminer-1.2 $
why not using cpuminer, then? |
|
|
|
|
what's the current market price for GBB?
|
|
|
|
A little thing I don't understand about XCN : in cmc, the value of XCN is almost all the time ~ 0.000005 BTC => https://coinmarketcap.com/currencies/cryptonite/But in bter, in exchange rate, it is half this value : about 0.0000028 BTC often So the rentability is half the real value of the coin. Why is it so 'cheap' on BTER tradign exchange, compared to the real value of XCN ? Probably they take that value from btc38, which is higher because you can't transfer coins to/from there. |
|
|
|
Another proof that sp's skunk was only copy paste from epsylon and alexis fork.
Epsylon and alexis kernels are mostly copy paste from my fork. The opensource is still slow It's all the same tricks over and over. I did the "part of the tables in cache" trick back in 2014 for groestl on amd. Then the "merge kernels", precalc, etc. All the same, nothing new. It's just a matter of applying and tuning. |
|
|
|
Could the previously talked about "bad nodes" have something to do with old Windows wallets? Would you believe this new version would easily fix btc38's issues (whatever they actually are - their messages to their customers are quite cryptic - perhaps you know more thanks to your contact?)?
It should make server nodes more solid, which in turn means the network will generally improve. The next step is not allowing incoming connections from old nodes (by increasing the protocol version). But, before doing that, we must be sure there are no exchanges, or other services, still running old wallets. |
|
|
|
ocminer not answer me. May be pallas can help - as I think my ip is banned by ocminer scripts. not web and stratum.
hey, this is my words  hehe I didn't notice, happened to me as well in the past. this is what some users do to increase their "activity": copy others post, so they look "in place". |
|
|
|
ocminer not answer me. May be pallas can help - as I think my ip is banned by ocminer scripts. not web and stratum.
I'm sorry Sir but I can't help you with his pool, if he banned your IP. |
|
|
|
Do you think that it is clean? // limit number of getslice from the same peer
Misbehaving(pfrom->GetId(), 2); Just ban node for many getslice? Or there is fixed number of getslice() for full sync? A clean sync should do less than 10 "getslice", but some broken clients are doing undredths, hence why the ban. It was also a possible attack vector: I feel much more confortable with a cap on possible requests of that kind. |
|
|
|
Faucet are dry.. need some donation here..  I will send some coins from the fund, as soon as I have access to the machine with the wallet (network issues). EDIT: meanwhile, if someone wants to send some coins, you are very welcome! This is the address: CVftwe8kKSnwM3ruTy6yRVypydtkQ1xvqU |
|
|
|
Pushed some commits to github:
- Avoid possible sync loop
- Fixed transaction export
- Bump version
If you compiled your own wallet, especially if you run in server mode (i.e. allowing incoming connections), please update.
Great! Though I'm assuming that there will be no compiled Windows version, so neither us Windows users without the proper knowledge or btc38 can take advantage of the new commits. Unless, of course, someone compiles one. And it didn't seem especially easy, not even for a friend of mine which is a developer. Something about no proper and clear instructions, I don't know. Don't ask because I don't know. There are no differences compared to any other coin forked from bitcoin around the same time (beginning of 2014), as far as compilation is concerned (i.e. same dependancies). I'm contacting bitfreak to ask for a windows build, he has a working windows compile environment. |
|
|
|
|
Pushed some commits to github:
- Avoid possible sync loop
- Fixed transaction export
- Bump version
If you compiled your own wallet, especially if you run in server mode (i.e. allowing incoming connections), please update.
|
|
|
|
|
Show Posts
