Update Reference Hardware Specs

[ggwpez]

Updating to the new hardware specs. CPU got slower but disk faster. This was the trade-off for chosing Cloud VM machines.
The new numbers were generated on a Cloud reference server with:

./target/production/substrate benchmark machine --dev --memory-duration 60 --verify-duration 60 --hash-duration 60 --disk-duration 60

Value changes:

Bench	Old	New	Relative Change	Unit
Blake2256	1029.0	783.27	-23.88 %	MiBs
Sr25519Verify	666	560.67	-15.82 %	MiBs
Memcopy	14.323	11.49	-19.78 %	GiBs
Disk Seq Write	450	950	+111.11 %	MiBs
Disk Rnd Write	200	420	+110.0 %	MiBs

I rounded the new disk speed down a bit (971->950, 445->420) since the disk benches are known to not be as consistent as the CPU ones.

Closes #13308. Marking as noteworthy so this is mentioned in the change log.

[99Kies]

@ggwpez Disk Seq Write and Disk Rnd Write values mainly affect which part of the function, my current Disk Seq Write's Disk Rnd Write values are 290.10 MiBs and 125.07 MiBs respectively, can I go run polkadot's verifier node.

[ggwpez]

Disk Seq Write and Disk Rnd Write values mainly affect which part of the function, my current Disk Seq Write's Disk Rnd Write values are 290.10 MiBs and 125.07 MiBs respectively, can I go run polkadot's verifier node.

You are probably using a network drive and not a NVMe SSD disk as mentioned in the wiki. In AWS it is probably possible to use multiple disks like in GCP. We should extend the explanations in the wiki for that. In GCP I used 4 network disks to archive performance close to a local disk. cc @bakhtin
Polkadot will update to use the same stats as soon as this merges.

[bkchr]

Why do we need faster disks? Instead of a faster CPU?

[ggwpez]

Why do we need faster disks? Instead of a faster CPU?

It would be nice to have faster CPU as well, but the most widely available cloud hosters only offer server CPUs, like Xeon and EPYC. These are mostly inferior in single-thread speed when compared to consumer hardware like Intel i7 or i9.
That is the trade-off for allowing machines to be virtual instead of bare metal.
Most validators used VMs anyway despite the old bare-metal recommendation, so this should help them to pick good VMs.

[bkchr]

Okay, ty for the explanation!

[99Kies]

@ggwpez Disk Seq Write's Disk Rnd Write values are 290.10 MiBs and 125.07 MiBs.

My main confusion is, can I use this configuration to run polkadot/kusama validator-node. I mainly want to avoid slashing my assets, which should be related to the outgoing blocks of the node, so as long as I have the CPU and Mem up to par, is it possible to run the node. (And then I don't have to worry about my assets getting slashed?

---

And I think we should offer three configurations, minimum, medium and maximum. It will makes it easier for validator to select the most cost effective machine.🤔

[ggwpez]

My main confusion is, can I use this configuration to run polkadot/kusama validator-node. I mainly want to avoid slashing my assets, which should be related to the outgoing blocks of the node, so as long as I have the CPU and Mem up to par, is it possible to run the node. (And then I don't have to worry about my assets getting slashed?

I cannot tell you that on a case-by-case basis. These are just recommendations; they are not hard requirements nor exhaustive.
It allows for quickly sorting out bad hosters and VM types. That is mostly the indented use-case.

For more concrete advice you can ask in the 1KV Program matrix/discord chat, they often talk about their server hardware.

[shawntabrizi]

What is the sTPS after this change? (as compared to 1,500)

[99Kies]

@ggwpez I can't find the matrix/discord link you mentioned. I would like to confirm that the machines running kusama are not also of this standard. Aren't there many parallel chains on the kusama network. Compared to polkadot, does kusama require the same machine performance as polkadot?

[shawntabrizi]

@99Kies if this PR goes in, you should probably assume that both Polkadot and Kusama are updated to the same standard. Generally speaking, Kusama will always be as close to Polkadot as possible in these kinds of things, as that is the purpose of the canary network.

[bkchr]

BTW the discussion around this change continues in the issue: #13308

We will not merge this before we have not solved the weight noise issue.

[ggwpez]

@99Kies see https://thousand-validators.kusama.network/#/getting-started the matrix channel is #KusamaValidatorLounge:polkadot.builders.

What is the sTPS after this change? (as compared to 1,500)

Currently getting a build error in the VM ref hardware image 🤦‍♂️. Will need to update the DB weights first.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[kianenigma]

Not sure if the aforementioned issues are solved, but seems like something that we want to see merged.

[ggwpez]

@oleg-plakida just to check: Substrate and Polkadot is updated? Now just Cumulus, or?

[oleg-plakida]

@oleg-plakida just to check: Substrate and Polkadot is updated? Now just Cumulus, or?

Rococo and cumulus remain.

[ggwpez]

bot rebase

[paritytech-processbot]

Rebased

[ggwpez]

bot merge

[paritytech-processbot]

Error: Required status check "pr-custom-review" is cancelled.

[ggwpez]

bot merge