Skip to main content

Custom monitoring graphs for xrp.ninja validator

xrp.ninja Ripple validator returns normal since two day ago

There's been some problems with the validator ever since it crashed about a week ago. It doesn't crash any more since I added much more disk space. But it easily falls behind and needs to play catch up several hours after each restart. I learned this from state_accounting field in the output of "rippled server_info". I created a metric and a chart from it. This is what the chart looks for the last week.
The "Full" mode state means it is fully synced and participating in consensus process. You can see it is now asymptotically approaching 100 now. The value means the percentage of uptime the validator stays in each mode.

I figured out why the disk was out of space. It was because the validator fell behind. When that happens, online delete is disabled. See this code:


I saw some "Not deleting" messages in the log which led me to the above code.

I still can't determine the exact reason why it fell behind. I suspect it was caused by some "insane" testnet peer. So I blocked some peers with iptables. But now it's almost 100% full and it still has an insane testnet peer.

However I do know why it didn't recover after disk is enlarged. I believe it's because I changed the db to NuDB from RocksDB and still have online_delete set in the config. I changed it because I learned NuDB works better on SSD. But it doesn't support update or delete. It is meant to be used in full history validator. It appears that when it tries to do online_delete, it starts to fall behind. Now I have switched back to RocksDB and everything is fine.

Comments

Popular posts from this blog

xrp.ninja Ripple validator upgraded to 0.81.0

Information about this version can be found here https://ripple.com/dev-blog/rippled-version-0-81-0/.

This happened at about 1:45pm local time.

There were some behavior changes after the upgrade:

How exactly is XRP going to work as a bridging digital asset?

Maybe this is obvious all along to some people. Anyway, I just figured this out. So I thought maybe it's worth sharing.

Previously I thought the bridging consists of two transactions, both on XRP ledger. One from fiat currency A IOU to XRP, the other from XRP to fiat currency B IOU.

Then I saw this:

https://www.xrpchat.com/topic/10981-xrapid-uses-crypto-exchanges-to-route-payments-in-real-time/

So Miguel Vias said in the pilot they used liquidity on bitstamp and bitso. However it's seems the trading volume of XRP/bitso.MXN since the beginning of 2017 is so low that it's virtually no liquidity there. See this:

https://xrpcharts.ripple.com/#/markets/XRP/MXN:rG6FZ31hDHN1K5Dkbma3PSB5uVCuVVRzfn?interval=1d&range=1y&type=candlestick

Then I realized, just like bitstamp, bitso has its own exchange and the liquidity there is much better.

https://bitso.com/trade/market/xrp/mxn

So now it's clear to me there is another way for XRP to bridge cross-border payments. The originat…

You have to know these about ripple wallet and secret key

TL;DR:

It's possible to find out others' secret keys but it's so improbable that it's almost impossible. Make sure you have a good entropy source when generating your address/secret key.Use multi-sign https://ripple.com/build/how-to-multi-sign/
See the discussion here: https://www.xrpchat.com/topic/6054-questions-about-secret-keysripple-wallet-addresses/