OVH do the same, almost all of those cheap VPS are not on server grade HW, but using regular PCs. Just get so called bare-metal server from hetzner and checkout what motherboard you have there, you will be surprised.
It is easy to blame just one VPS provider, when in reality there is almost no difference between Hetzner, Contabo or OVH.
Downtimes: yes sure Hetzner never had them or OVH(LOL, burn it all!) or even AWS.
I tested Hetzner and OVH, and they have a much better quality. Hetzner’s quality is great, I am not sure how it was in 2015, when this picture was taken… I am however not recommending Hetzner, since they have in their terms of use rules against all crypto activities and they can interrupt your service anytime.
Well, I got the Contabo setup below and after 4.3 days of uptime have the below results. A very big improvement, as good as it gets with a service like Contabo or any other tweeks I could do?
CLOUD VDS S
3 Physical Cores
AMD EPYC 7282 2.8 GHz
24 GB RAM
180 GB NVMe
More storage available
250 Mbit/s Port
32 TB Traffic*
If you are happy with the 1470 missed slot leader checks, then it is fine.
I have 171 missed slot leader checks on my BP, 125 from the transition to epoch 394 and 46 from the transition to epoch 395, and 0 from the rest of 7 days and more than 18 hours of running except the epochs transition. My BP is also running on a VPS with AMD EPYC dedicated CPU Cores.
In the same time, my backup BP has 176 missed slot leader checks, running on a different VPS in a different location than the primary, with Intel Virtual CPU Cores.
I am using +RTS -N3 -xn -T -A32m -n1m -AL512m -C0 -I0.3 -Iw3600 -O4000m -RTS to start the node on VDS S with Contabo and have 187 missed check for 8 days. Just for comparison
As you can see MUCH better! What I’m not 100% sure of is what fixed it.
I changed cnode.sh to CPU_CORES=3 manually and put export GHCRTS=‘-N3 -xn -T -A32m -n1m -AL512m -C0 -I0.3 -Iw3600 -O4000m’ in bashrc.
It looks like though the bashrc changes didn’t take as my default still shows:
-T -I0 -A16m -N2 --disable-delayed-os-memory-return (yes did full reboot after changes made)
At any rate I can live with 0.0xxx range.
cardano-node +RTS --info
[("GHC RTS", "YES")
,("GHC version", "8.10.7")
,("RTS way", "rts_thr")
,("Build platform", "x86_64-unknown-linux")
,("Build architecture", "x86_64")
,("Build OS", "linux")
,("Build vendor", "unknown")
,("Host platform", "x86_64-unknown-linux")
,("Host architecture", "x86_64")
,("Host OS", "linux")
,("Host vendor", "unknown")
,("Target platform", "x86_64-unknown-linux")
,("Target architecture", "x86_64")
,("Target OS", "linux")
,("Target vendor", "unknown")
,("Word size", "64")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
,("Flag -with-rtsopts", "-T -I0 -A16m -N2 --disable-delayed-os-memory-return")
You can also add RTS parameters in cnode.ch on line 39. The trick is that each one should be in separate brackets. In your case: “-N3” “-xn” “-T” “-A32m” “-n1m” “-AL512m” “-C0” “-I0.3” “-Iw3600” “-O4000m”. You can skip “-N3” as it is set via “-N${CPU_CORES}” and CPU_CORES=3 parameter.
After some more looking around I used the below setting and it took, NODE restarted:
My question would be, is it actually doing anything coded this way?
Actually seems that you haven’t understood correctly my post - you should not amend the first part prior to the && CPU_RUNTIME=(. The whole line with the settings you want to use should be:
[[ -n ${CPU_CORES} ]] && CPU_RUNTIME=( “+RTS” “-N${CPU_CORES}” “-xn” “-T” “-A32m” “-n1m” “-AL512m” “-C0” “-I0.3” “-Iw3600” “-O4000m” “-RTS” ) || CPU_RUNTIME=()
Thank you for your help. I couldn’t get those settings to take.
+RTS -N2 --disable-delayed-os-memory-return -I0.3 -Iw600 -A16m -F1.5 -H2500M -T -S -RTS --your-usual-parameters` (with " " for each).
This took and resulted in systemctl status cnode showing the change buy TX count went WAY down.
I set back to the default and just set CPU_CORES=3 and so far after 24hrs got 2 (0.0186 %)
