this post was submitted on 31 Oct 2023
1 points (60.0% liked)

Monero

1712 readers
1 users here now

This is the lemmy community of Monero (XMR), a secure, private, untraceable currency that is open-source and freely available to all.

GitHub

StackExchange

Twitter

Wallets

Desktop (CLI, GUI)

Desktop (Feather)

Mac & Linux (Cake Wallet)

Web (MyMonero)

Android (Monerujo)

Android (MyMonero)

Android (Cake Wallet) / (Monero.com)

Android (Stack Wallet)

iOS (MyMonero)

iOS (Cake Wallet) / (Monero.com)

iOS (Stack Wallet)

iOS (Edge Wallet)

Instance tags for discoverability:

Monero, XMR, crypto, cryptocurrency

founded 2 years ago
MODERATORS
 

Hey,

I think monero is interesting and want to support it a little. To do so i setup a public full node on my home-server (3900x with NVMe SSD) and configured it so that it is allowed to use up to 50% of my bandwidth (i have 500 MBit/s down and 40 MBit/s up)

I'm now not that sure how to configure in-peers and out-peers in a way that strengthens the network. My assumption would be that a high number of out-peers is bad because my server would be blocking in-connections of other nodes, and a high number if in-peers is good because i allow more people to download the chain.

Are these assumptions correct?
What would be some good values for in-peers and out-peers?
I currently configured 128 out-peers and 1024 in-peers. Is one of these exessive or not enough?

Update: I decided to go with 64 out-peers and 256 in-peers for now. See this comment for an explanation

top 11 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

I currently configured 128 out-peers and 1024 in-peers. Is one of these excessive or not enough?

This is likely excessive. There are over 20k nodes out there so just set up your node with reasonable settings like 16-32 peers and more importantly get some Monero and use it in the real world economy.

When it is running you can use commands like monerod print_net_stats to see what it is consuming in terms of bandwidth.

[–] heikomat 2 points 1 year ago (1 children)

Thanks for pointing out monerod print_net_stats! Will leave it running for a day or two and see how much is used. Currently the network usage is minimal, but that is probably because i only increased the peer-count 2 hours ago.

get some Monero and use it in the real world economy

easier said than done, but i do keep my eyes open for opportunities to use monero instead of other currencies. My next mullvad payment will be in monero

[–] [email protected] 2 points 1 year ago (1 children)

My next mullvad payment will be in monero

That is a good start, paying for online services with Monero is very convenient.

Other places where you can spend Monero and buy almost anything you need.

cakepay.com

coincards.com

allark.io

moneromarket.io

cryptwerk.com

https://xmrlistings.online

monerica.com

https://anonshop.app

shopinbit.com

https://xmr.directory

[–] [email protected] 2 points 1 year ago

I'm working on yet another directory site as well c:

[–] [email protected] 1 points 1 year ago (1 children)

Well, it sounds like you would only be able to serve 20mbps worth of in peers whatever that number may be. I think mine is set to 8 out and 16 in but i only have 50mbps/10mbps

[–] heikomat 1 points 1 year ago (1 children)

That's kinda what i want to find out - how much bandwidth does a peer need on average?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Since you brought it up, I've been experimenting. What you can do is set --limit-rate-up. I set mine to 1024 (1MB/s (8.1mbps)) the default is 2048 (2MB/S (16.2mbps.)). I upped my numbers to 64(out)+64(in) and i am finding on average its using ~12% of the 1MB/s (8.1mbps) i have it limited to. Mind you, most peers already have the chain so mostly its going to be relaying new blocks. But that is why i set the --limit-rate-up so my network isnt murdered if a peer needs the whole chain.

Edit: Also, it took me quite a while to establish 64 inbound connections over an hour anyway. The 64 outbound connections were established within seconds, but it takes a while to get the incoming peers.

[–] [email protected] 1 points 1 year ago (1 children)

fyi p2pool README says:

--out-peers 64 --in-peers 32 is needed to (1) have many connections to other nodes and (2) limit incoming connection count because it can grow uncontrollably and cause problems when it goes above 1000 (open files limit in Linux). If your network connection's upload bandwidth is less than 10 Mbit, use --out-peers 16 --in-peers 8 instead.

[–] heikomat 1 points 1 year ago* (last edited 1 year ago) (2 children)

ok, so if i read this correctly, then the p2pool folks say: if you have 10 MBit/s or more use 32 in-peers (that's 40KB/s per in-peer). Don't use more than 1000 because of the linux file limit (which can be changed)

So according to their numbers, with my 20 MBit/s limit i set i should choose about 64 in-peers.

I just looked at the upload-traffic of the last 21 hours. In total i used 44.55 GB of upload-bandwidth in that time, which is about 4.71 MBit/s or 603 KB/s. There were about 130-140 connected peers in that time. That equals about 0.03492 MBit/s or 4.47 KB/s per connected in-peer

With my 20 MBit/s limit that should allow for ~573 peers. This is average speed though, and there are probably spikes in network usage all the time. So if i apply a buffer of ~50% i should be able to serve about 256 in-peers with an average of 10 KB/s per in-peer.

I'll set it to 64 out and 256 in and let it run a couple of days and see how it goes :)
There have not yet been more than 150 connected peers anyway

[–] [email protected] 1 points 1 year ago

Yes, actually trying and seeing is the best way, if you’d really like to fine-tune anything. I don’t have much technical knowledge but empirically, any value may be about as good as another, if not too extreme. The end results might be about the same no matter which you use: 64, 80, 96, 128, etc. and just using the default settings may be good enough.

P2Pool may be somewhat special, as it’s not just about running a full-node but you have to run like 3 tools (each possibly resource-hungry) at the same time.

[–] [email protected] 1 points 1 year ago

@[email protected] If you’re still interested, now the recommendation is, that “in” is bigger: https://monero.town/post/1163754