What CPUs do on rx/zecnero.

01How to measure, so the numbers compare

A hashrate only means something next to the conditions it was measured in. The board records those conditions in every row, and a result is accepted only when it follows the steps below. Numbers measured any other way are not comparable and are not listed.

• Native, never WSL2. Measure on native Windows or on bare-metal Linux. WSL2 gives neither huge pages nor MSR access, so its figures fall well below the same machine and tell you nothing about the hardware. Record which operating system the number came from.
• Huge pages on. RandomX in fast mode wants 2 MiB pages, and 1 GiB pages are faster still on most CPUs. Confirm the miner prints huge pages 100% before you read the number.
• The MSR mod on. It raises the hashrate by a large margin on both Intel and AMD. Confirm the miner reports the MSR registers were set.
• Steady state. Let the miner run for several minutes and read the stabilised 10s/60s/15m average, not the opening figure while the dataset is still building. The one-shot benchmark below gives a repeatable number without pointing the miner at a pool.
• Record the rest. Mining threads, RAM, and the xmrig-zecnero version. A result without them cannot be reproduced.

xmrig-zecnero --bench=1M -a rx/zecnero

The benchmark is local. Do not pass --submit: the XMRig benchmark service has no reference hashes for rx/zecnero, so a submitted run cannot be verified there.

02The board

Steady-state hashrate with huge pages and the MSR mod on, measured natively. Click a column heading to sort. The conditions sit beside every figure so you can judge whether two rows are comparable. The Algorithm column says which proof of work a figure was measured on: rx/zecnero today, and rx/zecnero2 after the next network upgrade activates it. A CPU runs the two at different hashrates, so compare figures within one algorithm. This board is about hashrate only: for an estimate of ZMR per day at the current difficulty, use the reward calculator on the mining guide. Nothing here is a statement about earnings or value, and testnet coins have no value.

Community results will appear here as they are submitted and reviewed. The first row is the project reference measurement; see the reference rig for its conditions.

Showing the built-in results.

03Submit a result

The board reads a data file in the site repository, site/mine/benchmarks.json. There is no form on this page and no endpoint that takes anonymous writes; every result is reviewed before it appears. To add yours:

1. Measure your hashrate by the steps in How to measure.
2. Open a merge request on GitLab that adds one object to site/mine/benchmarks.json and the matching row to the table in site/mine/benchmarks.html. If a merge request is more than you want to set up, open an issue with the same fields and a maintainer will add it.
3. Fill in every field: CPU, core layout, mining threads, RAM, operating system, xmrig-zecnero version, whether huge pages and the MSR mod were on, the steady-state H/s, and a link that backs the figure. Power in watts and H/s per watt are optional; if you give power, say whether it is package or wall power.

A maintainer checks the result against the method and the policy below, then merges it. The data file carries a comment describing each field.

04Anti-fake policy

The board is only useful if the numbers are honest, so a few rules keep it that way:

• Reproducible, with conditions. Every figure names the operating system, the thread count, the miner version, and whether huge pages and the MSR mod were on. A result missing them is held until they are supplied.
• Backed by evidence. A figure that sits far outside what a CPU's cache and memory bandwidth can support is held until a log or screenshot, or a second independent report, backs it.
• No WSL2 numbers. They understate the machine and are not comparable, so they are not listed.
• Power stated honestly. A watt figure says whether it is package power or whole-system wall power; the two are not interchangeable.
• Review before publishing. Because submissions go through review, a wrong or invented number does not reach the page in the first place, and one found later is removed.

05The reference rig

The project quotes one reference machine, an Intel Core i7-13700KF. Measured on it: 8,200 H/s on 16 mining threads, on native Windows, run as administrator, with huge pages, the MSR mod and virtualization-based security all on. That is the figure the board seeds with and the one the project uses when it talks about what a desktop does on rx/zecnero. It is an rx/zecnero (v1) figure. An rx/zecnero2 reference number waits on a re-measurement on the same machine once the upgrade activates, so the board carries no v2 figures until measured ones are submitted and reviewed.

RandomX is designed so the hardware that runs it best looks like an ordinary desktop. Its random programs mix integer, floating-point and memory work the way general-purpose processors are built for, and a GPU adds little. Zecnero uses RandomX version 1 with one changed salt, which gives it a hash function of its own, so Monero hardware cannot be pointed at it unchanged.

06Picking a CPU

Three things decide how a CPU does on rx/zecnero, and they have to be in balance. A chip strong in one and weak in another will not reach what its core count suggests.

Memory for mining is about 2,336 MB: a 2,080 MiB dataset and a 256 MiB cache, plus 2 MiB of scratchpad per thread. Solo, the node wants roughly another gigabyte. A machine with 8 GB of RAM has room to mine. Verifying blocks needs only 256 MiB, in light mode, a few milliseconds per hash.

07Tuning that matters

Huge pages

Fast mode needs 2 MiB pages for the dataset, the cache and each thread's scratchpad. In 2 MiB pages that is 1168 + <mining threads>. On Linux, reserve them before mining and make it permanent:

sudo sysctl -w vm.nr_hugepages=1188        # 20 threads
# permanent: /etc/sysctl.d/99-hugepages.conf

1 GiB pages are faster still on most CPUs. They need three free gigabytes of contiguous memory and root: sudo scripts/enable_1gb_pages.sh, then run the miner with --randomx-1gb-pages. On Windows, large pages need the "Lock pages in memory" privilege; running xmrig-zecnero.exe as administrator once grants it to the account, and it takes effect after you sign out and back in. Then the startup line reads HUGE PAGES supported and the dataset shows 100%.

The MSR mod

The MSR mod raises RandomX hashrate by a large margin on Ryzen and on Intel, and the miner applies it on its own when it has the rights.

• Linux: run as root, or give the binary CAP_SYS_RAWIO and load the msr module; scripts/randomx_boost.sh does the same from a shell. Look for msr register values ... set successfully in the log.
• Windows: run as administrator, with WinRing0x64.sys next to xmrig-zecnero.exe (the build puts it there).

Threads and affinity

By default the miner picks a thread count from the CPU's cache, often most of the cores, and pins each thread to a core with hwloc. Pinning matters most on a hybrid chip such as the 13700KF, where the performance and efficiency cores are not interchangeable. Leave one or two threads free with --threads=<n> if you want the machine responsive, or free for the node when solo.

Windows against Linux

On the same machine, native Windows and bare-metal Linux are close when both have huge pages and the MSR mod. WSL on Windows has neither, so it runs slower; it is fine for the testnet but is not a reference number. When you report a figure, say which of the three it came from.

The key epoch pause

The RandomX key changes every 2,048 blocks, about every 42.7 hours, and the miner rebuilds its dataset when it does. Expect a short pause; with huge pages it takes a few seconds. Measure your steady-state number away from that rebuild.

08Build a home rig

A home rig for rx/zecnero is an ordinary desktop, picked for the three things in Picking a CPU:

• CPU: a current desktop chip with generous cache per core. Match the thread count you will run to the cache and memory, rather than to the core count alone.
• Memory: at least 8 GB, in two channels so both memory controllers are used; faster memory helps when the cores can use it.
• Cooling and power: mining is a sustained full-load workload, so steady cooling holds the clocks up and keeps the hashrate from throttling. A laptop runs but gets hot and throttles; fewer threads and mains power help.
• Operating system: native Linux or native Windows for the hashrate above; configure huge pages and the MSR mod as under Tuning.

Once it is running, measure it by the method above and add it to the board. For the commands that download and start the miner, see the mining guide; for how mining works end to end, how to mine.