src: bump network speed 4x #9770
Conversation
|
The limit defines appear to have been introduced by |
Well presumably, a future hardfork will force everyone to run updated software, so the downloads will only be hampered until a hardfork. Maybe we should consider higher default limits than the 4x proposed here. I remember some rationalization for the lower limits being that we don't want the monero software to render a user's computer unusable during sync, as this may drive the user to stop the sync to regain computer functionality. Of course, a slow sync can also lead a user to abandon the sync process..... |
|
There's a certain irony in the current limits: Asymmetric up/down speed applies to some channels, like cable, but, I suspect the typical users of those channels have even more asymmetric usage patterns, greatly favoring downloads and barely using upload bandwidth. So, if anything, if you don't want to anger users, you'd push default upload higher and download lower. For nodes in a data center with a fast connection, uplink speeds could matter, as data centers might charge for egress, but 8KiB/s works out to ~240GiB/year, which on, for example, EC2, costs ~$21.60/year. To clarify, I don't think the download limit here is too high, simply because most connections have gotten a lot faster since 2018 than the 4x change in this commit. But, the upload limit could probably go higher, maybe 2-4x where it sits right now. |
|
More important than the average speed is the "burst" speed (uploading blocks quickly). you could argue that download doesn't have to be any higher than upload. i definitely wouldnt decrease download to less than upload. You could also argue to keep downloads higher than uploads, which makes downloading the queue faster as you can download spans from 4 peers who are uploading at 8MiB/s. (Though monero does tend to use 1 peer, it doesnt always.) note: these limits do not have any effect on rpc. (afaik, rpc is effectively unlimited) |
Agreed, I probably wouldn't even take it to parity, but could see a case for 1/2 download, rather than 1/4. |
|
As this PR already has approvals, I should clarify that I don't advise any changes to it; a discussion of changing the up/down ratio would be better confined to a follow-on PR, if any. |
i could send a second commit to bump upload to 16384, and if its reapproved squash it? If not reapproved i can drop the second commit. 16384 would be a bit more conservative than nielsons law |
I'd of course be fine with the higher limit, but it's your call. I suggested a second PR simply because this one has the necessary approvals on all branches and would improve the situation, even if it can be further improved. |
2048 and 8192 are an unnecessarily low bottleneck for initial chain sync. Noticable if blocks grow (2MB/s is very low) and if using a dynamic block sync size.
I presume FCMP++ will also benefit from higher speeds.
note: a lot of configs floating around already recommend bumping to 1GB/s. This only bumps by 4x to 8192/32768.