Jump to content
Sign in to follow this  
SkeinGraham

Skein Systems - validator public key

Recommended Posts

Hello zerpers,

After some patient months of tweaking and understanding the behaviour and perf characteristics of rippled, and now being happy with it's stability,  I have switched my validator to a new public key and verified the operating domain. It's now listed as `skein.systems`: nHDpmRw3nYVWsbTrBaSScqHDQvNvnZJSAo7pxa3CQXbG571MVGHo

I though it would be good form to introduce myself to put a (hopefully) friendly face to the validator/domain. I also like to public thank Rabbit, Alloy and Nik Bougalis for the extremely helpful advice!

Share this post


Link to post
Share on other sites

Welcome aboard! Great to get new validators on the network. How was the process of performance tweaking and setting up validator keys? Did you hit any wrinkles or challenges worth mentioning? If you've got any details you want to contribute back to the capacity planning or validator setup instructions, I'd love to help get that information published so others can follow in your footsteps! If everything went smoothly, that's also great feedback to hear, of course. ;)

P.S. if you're looking for your next project, may I suggest setting up an xrp-ledger.toml file?

Share this post


Link to post
Share on other sites

I found the performance tweaking part fairly enjoyable (as long as you're prepared to be patient) - the docs were fairly clear on the hardware requirements and also clearly state that the disk i/o is important. I did of course make a few early mistakes such as lowball the `node_size` despite having the RAM to use large/huge configurations and playing with RocksDB params netted nothing of value.

I think the one thing that sticks out to me is this. Anyone with experience of running sensitive systems would recognize that the cluster configuration where the validator uses a stock node in the cluster as it's proxy (and with peer_private = 1) is the most desireable configuration - however there's no advice in this scenario that suggests the validating node in the cluster should also connect to peers outside the cluster using entries in the [ips_fixed] section.

I raise this point because after taking metrics and monitoring I was scratching my head for a few weeks trying to understand why the validator was falling behind concensus. This is where I pinged a few seasonsed operators for advice and then came to understand that the validator needs more than just one or two peers from the cluster to propose a ledger in good time. I think it would be good to indicate that the validators may also need additional peers if the cluster is smallish.

One other thing I noticed - the popular peers/hubs are fairly busy with connections from lots of stock nodes. Because of that I had struggled with lots of insane/unknown peers ,and also peers that were old versions not behaving well connecting to my stock/proxy node. These were sometimes taking 40% or more of the peer connections. Rabbit pointed me at his ban hammer script for insane nodes that are out of concensus - I took some inspiration from that and wrote a daemon that temporarily firewall bans "unstable" peers, and also punts their connection.

https://github.com/gnanderson/rbh

This has helped my proxy/stock node maintain a very healthy list of peers which are are in concensus and also only current patch version -1 in age.

Validator keys setup was fine, it's simpler than clustering nodes - took me less than 5 mins to regenerate new keys then generate a new token and restart the validator.

I'll happily look at the capacity planning and setup instruction again and see where I can add some more detail or help. Is the new XRPL.org site published from this repo?: https://github.com/ripple/ripple-dev-portal

> P.S. if you're looking for your next project, may I suggest setting up an xrp-ledger.toml file?

I'll be all over that tomorrow :D

 

 

Edited by SkeinGraham
additional info

Share this post


Link to post
Share on other sites
1 hour ago, SkeinGraham said:

however there's no advice in this scenario that suggests the validating node in the cluster should also connect to peers outside the cluster using entries in the [ips_fixed] section

This is a clear risk, your validator shouldn't connect to untrusted servers. If you have servers you totally trust outside the ones you operate yourself, then you're really lucky (or maybe naive... ;-) ).

I guess peer connections are cheap enough (resource wise) to not care about "insane" peers, I'd just allow more connections and be done with it instead of micro-managing connections.

Edited by Sukrim

Share this post


Link to post
Share on other sites
1 hour ago, Sukrim said:

This is a clear risk, your validator shouldn't connect to untrusted servers. If you have servers you totally trust outside the ones you operate yourself, then you're really lucky (or maybe naive... ;-) ).

I guess peer connections are cheap enough (resource wise) to not care about "insane" peers, I'd just allow more connections and be done with it instead of micro-managing connections.

Very fair and valid points - fortunately operators in the current most trusted UNL offered to accept a peer connection from the validator.

I suppose if I didn't trust these node operators then by extension I would also not trust the UNL. There's a healthy sceptiscim in not trusting everything, that's a given :) - but there's the operational costs as well - I could try to spin up more stock/proxies in the cluster and have the validator only peer with them. That might be fine at some point in the future but it's not ideal right now at this stage for me.

I mentioned in the xrpl geek slack I didn't really want to be exclusionary with fiddling my firewall, and that's why each time the deamon makes the decision it's temporary. You're right though, it's more of a concern when the max_peers  value is either default or low - raising that helps. On the flip side I wonder if gentle pressure on node operators to upgrade or endeavour to join concencus more often would benefit the network as a whole?

Share this post


Link to post
Share on other sites

If you haven't already, you might want to disable pathfinding on your validator. The server does quite a bit of work to maintain some ledger indexes used to find paths for cross-currency payments and validators that don't originate transactions don't need to do this. The config stanza is:

[path_search_max]

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...