@camosoul, I just said to my hubby, John, that you and he were so much alike, AKA tolerating people. He quipped that you were both excellent at tolerating people, "'cause just look, all those stupid people are still alive!"
Bingo. If I really were a terrible, evil, ammosexual everything-o-phobe;
there wouldn't be anyone around to say so and complain about how bad I make them look by being so much better than they are at everything forever...
Anybody know if the SPECs for MN's will be changing on the next release?
As in Server requirements?
I can't see a reason for them to change... Due to the multisession mixing, there may be an increase in CPU use and maybe RAM and bandwidth, but probably not a lot. Mixing still uses the same resources, but in much more rapid bursts. The parallelism in the clients will be reflected in the hosts doing the jobs. So, a bit more RAM and CPU usage. My 8core Xeons probably won't notice. But slow ARMs will be noticeable. Nothing critical. Think of it like, 8core Xeon has a ceiling so tall you can't see it. ARMs, well, you can just barely see it... You'll be using more, but still not enough to worry about.
My containers get 1x full clocked core, 512 RAM, and 256 Swap. I don't anticipate that changing for 12.1. They barely touch my available bandwidth. Even if they increased by an order of magnitude, it still wouldn't be a problem.
We're still not storing any info beyond the chain, so storage space, which will be the biggest future change, is still not in play.
My virtualization host is still pulling roughly 3% to 5% of it's bandwidth. CPUs are a smidge above idle. RAM is maxed out... That's the only thing I can see being an issue, but it's a longshot maybe. If you run like I do, with cron simply trying to restart the client every 5 minutes, low RAM crashes should manifest as proof of service strikes that never quite get bad enough to kick you off (until traffic increases, then it will), as a first symptom. I know it's crude, and there are much more graceful watchdog scripts, but this method comes with crude diag....
Watch swap.
An upgraded virtual host will also have upgrade hard drive space, so those two problems should solve each other at the same time.
These are things MN operators should be learning about and preparing for months ago... 12.1 will show us a small increase in CPU/RAM and possible bandwidth. But full-blown Evolution will have as significantly higher demand, though still, probably not critical. Anyone running very minimal nodes is going to start crying, just like CPU miners did when GPU mining became a thing... Then FPGAs and ASICs...
@ all MN operators; If you're not planning ahead, you're doing DASH a dis-service. Irresponsible retards should not be running masternodes. If you run an MN and aren't watching the testing thread, you're a dick. It shouldn't be hard to deduce the resource needs from the feature changes. Hell, run a testnet MN... Or a dozen. 1000 tDASH costs nothing. 3 faucets... Actually DO it and you'll know...
Also, ESXI is gay because VMWare is fighting hard to become the Lotus Notes of Virtualization. Use Proxmox.
Independent operators with only 1 to a few nodes, should consider pooling resources for their own pizza boxes, instead of playing with middle man VPSes. It's going to make more sense that way.
If you've got affordable statics on Pis, sufficient pipe at home, you should be good for the foreseeable future, even Evolution.
I don't know if the MN protocol can support compression, but it might be a consideration for large spews of data, like lists, chain to new nodes, etc... Bandwidth will be a problem long before CPU. Might as well use it to lighten the load.
Certain forms of encryption provide natural compression on larger datablocks... If my node finds itself pumping 27gigs of chain to a new node in 2025... It'd be nice if that only used 10gigs of pipe to do it, or a version of bit torrent to draw from the whole network in conjunction with compression, too... Especially any transition to a 500DASH node split. That'll be a lot of pipe... Think of it now, not when it's too late... A node split may even be considered simply to diversify the data shards, not necessarily service-related.
