[ANN][CROC] Official CrocodileCash Update Board [Strength in Basking]

[heratys111]

Hey,

With regards to there being any potential problems at Cryptohub...

Staking CROC seems to be working as normal within my own wallet (new CROCs being generated at about the expected frequency and amount).

There did seem to be a problem mining at Cryptohub; I've been renting Bitmain S9s.  Due to there being perhaps a problem, I shifted the hash over to Pickaxe.online and am receiving essentially the anticipated amount per payout-period (the period being 20 mins there) of the POW-generated CROC from that pool.

It seemed to take awhile before the network hash rate [in the daemon/command-line and at Cryptohub] increased to roughly the level that could seen at the CROC address here (http://pickaxe.online/#miners).  But now the network rate at the terminal and at Cryptohub seems to be accurate with what I figure is the overall CROC-network hash-rate.

I don't know if it's related at all but the 23-Skidoo/CHAO chain may be buggy; although my level of trust in the operators of Infernopool is also extremely low at the moment too. That pool supposedly paid an amount in the last 24-48 hours (0.00141595 CHAO to a deposit address).  According to the interface at Infernopool it was sent 29 hours ago but there doesn't seem to be any evidence of the payment being made according to either the CHAO blockchain explorer (https://chainz.cryptoid.info/chao/) or the wallet interface.  Maybe the CHAO or another wallet is screwing things up with CROC at Cryptohub???

[Mikanoshi]

So... Anyone is looking into RAM usage problem? crocodilecashd is the only daemon that eats shit ton on memory...
My server is at 90% already and starts to swap a little. It's KVM VDS with SSD, so it's not that slow.
Anyway, if daemon appetite keeps growing, I'll have to shut down the block explorer...

 

[currypto]

So... Anyone is looking into RAM usage problem? crocodilecashd is the only daemon that eats shit ton on memory...
My server is at 90% already and starts to swap a little. It's SSD VDS, so it's not that slow.
Anyway, if daemon appetite keeps growing, I'll have to shut down the block explorer.

 

Yep, we are looking into it.

The "ultimate fix" is going to be rebasing off of the latest Peercoin code, and modify it so we can continue using our chain and same rules.

[Mikanoshi]

Or maybe someone knows how to free some memory in FreeBSD 11? Wired for example consumes 870MB out of 3GB

[john_W]

just a reminder some time ago @bumbacoin offer he's help on the old threat if is needed

bumbacoin is wallet dev, you can see all he's work from over the years here :
https://bitcointalk.org/index.php?topic=1200970.0

He does update the threat every time he's done with a new wallet.
So, contacting him could be a good move if the Proposal fork goes forward

[telematico2]

upgrade: bitcoin core changes need to be merged with ours.

[startsts]

@heratys111 @currypto

CROC at cryptohub works again.   after sync from zero seems a little faster.   I will get wallet.dat from server and try at local machine so I will know if problem is large wallet.dat or  another thing

[currypto]

@heratys111 @currypto

CROC at cryptohub works again.   after sync from zero seems a little faster.   I will get wallet.dat from server and try at local machine so I will know if problem is large wallet.dat or  another thing

OK good to hear.

"little faster" - you said up to 90 seconds before. What does it seem to be now?

[startsts]

@heratys111 @currypto

CROC at cryptohub works again.   after sync from zero seems a little faster.   I will get wallet.dat from server and try at local machine so I will know if problem is large wallet.dat or  another thing

OK good to hear.

"little faster" - you said up to 90 seconds before. What does it seem to be now?

time /root/CrocodileCash/src/CrocodileCashd getinfo

real   0m41.782s
user   0m0.008s
sys   0m0.000s


time /root/CrocodileCash/src/CrocodileCashd getblocktemplate

real   0m7.318s



So all methods delay too much and wallet can't submit valid block from stratum.  No way to mine it here

[startsts]

I see in log file such strings  all the time:

Flushing wallet.dat 9433ms
Flushing wallet.dat 13237ms

If I use "top" command I see

6.3 us,  2.4 sy,  6.0 ni, 23.7 id, 61.6 wa

61.6% waiting of I/O  it's a lot, so disk is really overloaded.  

This can be reason of slow work  and how to resolve the problem?  To have separate disk/server for every coin?  


command "iotop"  that shows I/O waiting processes shows me that CrocodileCashD and QubitCoinD - 2 coins with 30 seconds block time (Croc even worse since it has PoS), so no idea what to do with that coins
For now I'm going to delist qubit coin


Searching in internet give me no solution.  Actually it is not a common thing when PoW, PoS and deposits (addresses generating) work on the same wallet

[currypto]

I see in log file such strings  all the time:

Flushing wallet.dat 9433ms
Flushing wallet.dat 13237ms

If I use "top" command I see

6.3 us,  2.4 sy,  6.0 ni, 23.7 id, 61.6 wa

61.6% waiting of I/O  it's a lot, so disk is really overloaded.  

This can be reason of slow work  and how to resolve the problem?  To have separate disk/server for every coin?  


command "iotop"  that shows I/O waiting processes shows me that CrocodileCashD and QubitCoinD - 2 coins with 30 seconds block time (Croc even worse since it has PoS), so no idea what to do with that coins
For now I'm going to delist qubit coin


Searching in internet give me no solution.  Actually it is not a common thing when PoW, PoS and deposits (addresses generating) work on the same wallet

Yes, you need to give it its own disk then...Lots of random access all over the place when you are running many coins

[startsts]

I see in log file such strings  all the time:

Flushing wallet.dat 9433ms
Flushing wallet.dat 13237ms

If I use "top" command I see

6.3 us,  2.4 sy,  6.0 ni, 23.7 id, 61.6 wa

61.6% waiting of I/O  it's a lot, so disk is really overloaded.  

This can be reason of slow work  and how to resolve the problem?  To have separate disk/server for every coin?  


command "iotop"  that shows I/O waiting processes shows me that CrocodileCashD and QubitCoinD - 2 coins with 30 seconds block time (Croc even worse since it has PoS), so no idea what to do with that coins
For now I'm going to delist qubit coin


Searching in internet give me no solution.  Actually it is not a common thing when PoW, PoS and deposits (addresses generating) work on the same wallet

Yes, you need to give it its own disk then...Lots of random access all over the place when you are running many coins

I understand, but it is not good solution. It will be impossible to have dedicated server for every coin daemon.
There is a discussion about same problem https://bitcointalk.org/index.php?topic=1242364.0

Maybe there is a way to increase interval of writing file wallet.dat to disk  ?   If I set 20 minutes instead of 1 minute (seems so for now) I think problem will be resolved.
I don't see any reason to write it so frequently.

Let's find in code something about that

found in code:
walletdb.cpp  line 559

if (nLastFlushed != nWalletDBUpdated && GetTime() - nLastWalletUpdate >= 2)

so it wants to write to disk every 2 seconds.... such a shit... let see if problem resolves if I set here 200

[startsts]

Yeah    that is I call a success

After setting wallet.dat flushing interval 200 seconds  for CROC and Q2C  waiting I/O in average is only 5% now  (were 60%),   CROC wallet responds all commands immedeately

[currypto]

Yeah    that is I call a success

After setting wallet.dat flushing interval 200 seconds  for CROC and Q2C  waiting I/O in average is only 5% now  (were 60%),   CROC wallet responds all commands immedeately

Nice!

My only question is, what does this imply? I think this will take more RAM.

[startsts]

Yeah    that is I call a success

After setting wallet.dat flushing interval 200 seconds  for CROC and Q2C  waiting I/O in average is only 5% now  (were 60%),   CROC wallet responds all commands immedeately

Nice!

My only question is, what does this imply? I think this will take more RAM.

Don't think so.  It keeps wallet data in memory anyway,  only writes it to disk with different interval


Actually all wallets do this shit, but on coins with large block time and that has few pool blocks wallet.dat is not so heavy




That flushing wallet.dat to disk after every block was creating in bitcoin with block time 20 minutes,  on modern coin with block time 1-2 minute, especially on CROC with ~15 seconds it should be reworked.  It has no sense rewrite that file if there is no new tx in that new block. 

[buyercontact]

Not bad guys. I am in

[heratys111]

@startsts

Awesome work digging up the problem and implementing that solution.  I'm going to make that change in my copy of that file now too...

[startsts]

@startsts

Awesome work digging up the problem and implementing that solution.  I'm going to make that change in my copy of that file now too...

It makes few sense if you wallet.dat is small.    Actually I didn't implement anything.   The dev (when he will exist) should add launching parameter to manage that wallet flushing interval

[currypto]

@startsts

Awesome work digging up the problem and implementing that solution.  I'm going to make that change in my copy of that file now too...

It makes few sense if you wallet.dat is small.    Actually I didn't implement anything.   The dev (when he will exist) should add launching parameter to manage that wallet flushing interval

Like I said, we are going to migrate to newest Peercoin code whenever we can. I wonder if this option has been added up there?

[startsts]

@startsts

Awesome work digging up the problem and implementing that solution.  I'm going to make that change in my copy of that file now too...

It makes few sense if you wallet.dat is small.    Actually I didn't implement anything.   The dev (when he will exist) should add launching parameter to manage that wallet flushing interval

Like I said, we are going to migrate to newest Peercoin code whenever we can. I wonder if this option has been added up there?

What is average block time in Peercoin?  Seems 10 minutes,  so they don't need this option