[-] heikomat@lemmy.world 5 points 1 year ago

If the comments tell you "what" happens, then yes, they can geht outdated fast. The details of how something works can change quickly.

But comments documenting "why" something is done (a certain way) - explaining the intent - are probably valid for mich longer.

In the best case comments aren't viewed as something that is seperate from the code, but part of it. So that if someone changes the code, the comments has to be checked aswell (if the explanation of "why" something is done actually changed).

[-] heikomat@lemmy.world 15 points 1 year ago* (last edited 1 year ago)

Exactly that! Everyone can See "what" is happening, the code is right there. But the code usually doesn't tell you "why" that is happening - good comments help understand the authors intent and give context, so you don't have to guess.

Good comments should explain the things that are not obvious.

Good comments more than once prevented me from accidentially undoing a fix.

[-] heikomat@lemmy.world 1 points 1 year ago* (last edited 1 year ago)

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

[-] heikomat@lemmy.world 1 points 1 year ago

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

[-] heikomat@lemmy.world 2 points 1 year ago

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

1
submitted 1 year ago* (last edited 1 year ago) by heikomat@lemmy.world to c/monero@monero.town

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

heikomat

joined 1 year ago