This will probably be the final update log before HF24, as a (semi) final date for the hardfork has been set at 14:00 UTC, 22nd September 2020, provided if there is a supermajority (17/21) of the top witnesses running the new version before the date.
As of writing this post, 0 top 20 witnesses and 6 backup witnesses are signing blocks on v1.24.0. The hardfork is scheduled to happen in 5 days, but given that only 1 witness in the top 21 is running the new version it is very likely that it will be rescheduled again.
I have been testing out v1.24.0 on the Hive mainnet since I wrote the previous witness update log 3 weeks ago against different environments on my local machine.
Here are the specs:
AMD Ryzen 7 1700, 8C 16T CPU @3.7GHz Asus Prime B350M-A motherboard Corsair Vengeance 16GB DDR4 3000MHz C15 RAM 500GB Samsung 960 Evo NVMe SSD 256GB Samsung PM810 SATA 2 SSD 500GB WD Blue 7200rpm HDD
The test has been conducted on two separate environments, one being on macOS Mojave (Clover bootloader) with VirtualBox (Ubuntu Server 20.04 guest), and another on PopOS 20.04 running natively without virtualization. Both BMIC MMAP and MIRA have been tested with
To save space on the SSD, I have placed the
block_log.index files on the spinning disk as the bottlenecks are either the CPU or the SSD (where the state files are stored) at all times during the replay. The state files (as well as the PopOS 20.04 installation) are stored in my spare SATA 2 SSD, and the macOS installation is stored in the NVMe SSD. As tested, storing the state files in the faster NVMe SSD did not help with the replay times.
So here are the results.
As I expected, I managed to complete a full replay with BMIC MMAP in 19 hours, which is 1 hour longer than the duration claimed in the v1.24.0 release notes. I had to set the
shared-file-size to 18G to complete the replay, or else it will run out of memory at 45.1M blocks and crash. This involved setting the shared memory filesize above the physical RAM I have, but it managed to sync with the head block without any issues. Therefore, for those who are building (or renting) a Hive witness server I recommend at least 32GB of RAM as 16GB may only be sufficient for a Hive node in the short term, probably until the end of 2020.
Looking at the result for VirtualBox, it managed to replay with BMIC MMAP up to 25.3M blocks, after which it ran out of memory as the host OS (Mojave) became unresponsive so I had to stop there.
What I was surprised was the MIRA results in both OS environments. MIRA replay in v1.24.0 became very slow at 13M blocks, eventually reaching 0.75 blocks/second at 13.4M blocks. I thought it was a bug or a misconfiguration, so I asked the Hive community on Discord and this is what I got back:
So apparently MIRA is no longer supported post HF24 except for the
account_history_rocksdb plugin, which means the cost of running a Hive node may increase after HF24 especially for backup witness running on MIRA as it will no longer be possible to run a Hive witness on 8GB of RAM.
I will definitely miss those days where you could run witnesses with as little as 6GB of RAM with low-cost RocksDB chain state storage.
Unscheduled RPC node maintenance
Due to HF24, my RPC node (hived.techcoderx.com) will be going offline for a few days as v1.24.0 update will require a full replay. techcoderx.com API will be redirected temporarily to another public node to prevent disruption of any Hive applications using my API endpoint.
Let's see how well my witness performed lately :)
Current rank: 93rd (active rank 85th)
Votes: 4,006 MVests (finally!)
Voter count: 111
Producer rewards (7 days): 26.32 SP
Producer rewards (30 days): 105.36 SP
Missed blocks: None!
Server resource statistics
This section will be present in every witness update logs (if any of my nodes are online) to provide new witnesses up-to-date information about the system requirements for running a Hive node.
block_log file size: 284 GB
blockchain folder size: 708 GB
Account history RocksDB size: 300 GB
RAM usage: 7.9 GB
Server network utilization (last 30 days)
Currently subsidising server expenses myself for the first year. If you like what I'm doing, please consider supporting by voting for me.