PassMark for VPS: Repeat Tests Before Comparing V10 Scores
PassMark for VPS: Repeat Tests Before Comparing V10 Scores

PassMark is a useful tool for comparing VPS CPU, Memory Mark and Disk Mark results, but only when you run it more than once and check which PassMark version produced the numbers. A single test on a shared host can swing wildly due to neighboring workloads, so the smart approach is multiple runs, a median comparison, and a clear eye on CPU Mark, Memory Mark and Disk Mark separately. We at AceRDP build our infrastructure around high-performance virtual servers.
TL;DR:
- For RDP and interactive apps, prioritize single thread CPU performance; for CI builds, compare multi core CPU Mark because parallel compilation uses multiple cores.
- Match Disk Mark to access patterns: sequential throughput suits backups and transfers, while small block IOPS better reflects database reads and writes.
- PassMark V10 changed subtest methods, so compare results only within the same major version; cross version CPUMark is roughly comparable only for CPUs from the same generation.
- Treat scores as directional: noisy neighbors and virtualized timing can skew runs, while network latency and application bottlenecks remain outside PassMark’s tests.
- Run the full suite at different times, record each timestamp and score, then compare medians and ranges; use disk test files larger than RAM cache.
Table of Contents
- What PassMark measures for VPS: CPU Mark, Memory Mark and disk tests
- Why PassMark results vary on a VPS
- How to run PassMark on a VPS for repeatable results
- Interpreting typical VPS PassMark scores for real workloads
- Impact of VPS plan tiers on PassMark performance metrics
- Comparison of PassMark scores across VPS providers for context
- Using PassMark scores to match VPS plans to specific workload requirements
- How virtualization technology affects PassMark VPS benchmarks
- Limitations of PassMark benchmarks for real-world VPS performance
- How to run PassMark benchmarks on Windows and Linux VPS environments
- AceRDP perspective: how infrastructure choices shape the numbers
- How AceRDP can help you benchmark with confidence
- FAQ
- Sources
- Authoritative links for verification and replicating tests
What PassMark measures for VPS: CPU Mark, Memory Mark and disk tests
PassMark’s PerformanceTest suite breaks performance into a handful of composite scores, and each one maps to a different kind of VPS workload.
CPU Mark aggregates integer math, floating point operations, prime number finding, and single-thread performance into one number. A VPS running batch jobs or compilation benefits from strong multi-core CPU Mark results, while remote desktop sessions and interactive apps lean more on single-thread speed, since most RDP operations do not parallelize well.
Memory Mark combines bandwidth, latency, and database operation tests. These matter most for workloads that keep large datasets in RAM, like caching layers or in-memory databases, where latency spikes translate directly into slower queries.
Disk Mark covers sequential throughput and small-block IOPS scenarios (commonly tested around 4K block sizes). NVMe-backed VPS plans tend to separate from SATA SSD or shared-storage plans most visibly on the IOPS side rather than on raw sequential speed, since random access is where virtualized storage layers show their overhead.
- CPU Mark: integer, floating point, prime finding and single-thread subtests, best read separately for multi-core versus interactive workloads.
- Memory Mark: bandwidth, latency and database operations, most relevant to in-memory and caching workloads.
- Disk Mark: sequential throughput and 4K-style IOPS, where NVMe tends to separate from shared storage.
Why PassMark results vary on a VPS
Virtualized environments introduce sources of noise that a bare-metal benchmark never has to deal with. The hypervisor schedules your virtual CPU alongside other tenants’ workloads, and when a neighboring instance spikes its usage, your scheduled CPU time can get delayed even though your own VPS configuration never changed. This is the classic “noisy neighbor” effect, and it shows up as inconsistent CPU Mark and Disk Mark results across otherwise identical test runs.
Timekeeping adds another layer of uncertainty. Many CPU benchmarks rely on a hardware timestamp counter (TSC) for precise timing, and virtualized TSC behavior can drift or get re-synced by the hypervisor, which skews short-duration measurements more than long ones. This is one reason a single quick PassMark run on a VPS is less trustworthy than a longer, repeated test series.
PassMark’s own version history is a reliability factor too. The V10 release changed how individual subtests run internally, so V10 scores are not directly comparable to V9 results, even though the composite CPUMark was scaled to stay roughly comparable for CPUs from the same hardware generation. If you are comparing a score you found online against a fresh test you just ran, confirm both used the same major PassMark version before drawing conclusions.
- Hypervisor scheduling and noisy neighbors can shift CPU Mark and Disk Mark results run to run, independent of your plan’s actual specs.
- Virtualized TSC behavior can distort short timing windows, making brief single-pass tests less reliable than repeated runs.
- PassMark V10 changed individual subtest algorithms, so cross-version comparisons require checking the version number first.
How to run PassMark on a VPS for repeatable results
Getting a trustworthy PassMark reading on a VPS takes more discipline than running the tool once and screenshotting the result. A short protocol fixes most of the common mistakes.
- Provision a clean test instance and record its vCPU count, RAM size, disk type (NVMe, SSD, or shared), and the PassMark version you plan to run.
- Run the full suite multiple times, spacing the runs across different hours and including both peak-traffic and off-peak windows.
- Log the exact timestamp of each run alongside its CPU Mark, Memory Mark, and Disk Mark results, then calculate the median across the set rather than trusting any single number.
- For disk tests specifically, use test file sizes large enough to exceed available RAM cache, and disable write caching where the test allows it, since cached writes inflate throughput numbers in ways that do not reflect sustained real-world disk performance. PassMark’s own disk FAQ notes that small test files or caching effects routinely produce misleadingly high throughput figures.
- Record the full spread, not just an average: save the minimum, median, and maximum, and note any outlier runs that might point to a noisy neighbor on the host.
Pro Tip: Schedule your test runs with a cron job or Windows Task Scheduler entry so they fire automatically at the same times each day, removing the temptation to only run tests when the VPS “feels fast.”
Interpreting typical VPS PassMark scores for real workloads
A raw CPU Mark number means little without context. For remote desktop responsiveness, single-thread performance usually matters more than total CPU Mark, since many interactive RDP tasks rely on a small number of threads rather than spreading evenly across every vCPU. A VPS with a lower total CPU Mark but strong single-thread results can feel snappier in daily use than one with a higher aggregate score spread across many weaker cores.
For disk-bound applications, the right metric depends on the access pattern. Sequential throughput matters for large file transfers and backups, while small-block IOPS matters far more for databases, which perform constant small reads and writes rather than long sequential streams.
Memory Mark expectations should account for architecture generation as well as raw numbers. DDR5-based hosts generally show lower latency and higher bandwidth than DDR4 equivalents, which benefits in-memory caches and database operations that are sensitive to memory access speed, a distinction worth understanding in more depth in our DDR5 vs. DDR4 comparison for VPS hosts.
Rather than chasing the single highest score available, it helps to check your results against a standardized dataset. The open VPS benchmark repository on GitHub collects CPU, disk, and network results from multiple providers using consistent tools, which gives a fairer baseline than comparing isolated numbers pulled from marketing pages.
- Single-thread CPU Mark tracks interactive responsiveness more closely than aggregate multi-core scores.
- Sequential Disk Mark suits backups and transfers; small-block IOPS suits databases and transactional workloads.
- DDR5 memory generally improves latency and bandwidth over DDR4 for memory-sensitive workloads.
Impact of VPS plan tiers on PassMark performance metrics
Moving up a VPS provider’s plan ladder typically changes PassMark results in predictable but uneven ways. Higher tiers usually add vCPU cores and RAM allocation, which lifts CPU Mark and Memory Mark proportionally, but the improvement is rarely linear across every subtest. A plan that doubles vCPU count might show a close-to-double multi-core CPU Mark, while single-thread performance barely moves, since it depends more on clock speed and CPU generation than on core count.
Disk Mark tends to shift differently across tiers. Many providers tie higher plans to faster storage classes, such as moving from shared SSD pools to dedicated NVMe allocations, which can produce a much larger jump in IOPS than the CPU or RAM increase alone would suggest. In other cases, the underlying storage hardware stays identical across tiers and only the allocated bandwidth or priority changes, which produces a smaller but still measurable Disk Mark improvement.
Memory Mark scaling is the most tier-dependent of the three. Bandwidth-focused subtests often scale well with added RAM channels or capacity, but latency-sensitive subtests, including database operations, can stay flat if the underlying memory controller and channel configuration do not change between tiers. This is why checking Memory Mark alongside the specific plan’s advertised memory type and channel count matters more than comparing RAM size alone. For workloads that depend heavily on consistent memory latency, it is worth confirming whether a higher tier actually changes the memory architecture or simply allocates a larger slice of the same shared pool.
Comparison of PassMark scores across VPS providers for context
Comparing PassMark scores across different VPS providers is useful for spotting broad patterns, but it requires controlling for more variables than most comparisons account for. Two providers advertising similar vCPU counts and RAM can produce meaningfully different CPU Mark and Disk Mark results depending on their underlying CPU generation, hypervisor choice, storage hardware, and how aggressively they oversubscribe shared resources.
A fair cross-provider comparison starts with matching the PassMark version used in each test, since version mismatches alone can account for differences that have nothing to do with the hardware. From there, looking at a standardized dataset rather than isolated scores pulled from different sources reduces the risk of comparing apples to oranges. The standardized VPS benchmark repository stores provider, plan, region, and specs alongside each score, which lets you filter for comparable configurations before drawing conclusions.
It also helps to treat any single provider’s published PassMark number as a snapshot rather than a guarantee. Scores collected at one point in time, on one test instance, under one set of neighboring workloads, will not necessarily match what you see on your own instance even from the same provider, which circles back to the core recommendation: run your own tests on the specific plan and region you intend to use rather than relying entirely on someone else’s published number. Our own high-CPU VPS testing results show this kind of reproducible approach, where the testing method is documented alongside the scores.
Using PassMark scores to match VPS plans to specific workload requirements
The most practical use of a PassMark score is matching a plan to the actual job it needs to do, rather than picking the highest number on a spec sheet. A developer running CI builds cares most about multi-core CPU Mark, since parallel compilation jobs scale with available cores. A trader running an automated strategy around the clock cares more about consistent single-thread performance and low-latency networking than about peak aggregate CPU Mark, since most trading scripts execute on a single thread and depend on timing consistency rather than raw throughput.
Database-heavy applications should weight Memory Mark’s database operations subtest and Disk Mark’s small-block IOPS more heavily than sequential throughput, since transactional workloads perform constant small reads and writes rather than large sequential transfers. Remote desktop users, meanwhile, benefit most from strong single-thread CPU performance and low network latency, since session responsiveness depends on quick individual operations rather than parallel processing power.

Once you know which metric matters most for your workload, the plan-selection process becomes a filtering exercise: rule out plans whose relevant metric falls short, then compare price among the remaining options rather than treating every PassMark subtest as equally important for every use case. This workload-first approach avoids the common mistake of chasing the single highest CPU Mark number on a provider’s page without checking whether that number reflects the specific subtest that matters for the task at hand.
How virtualization technology affects PassMark VPS benchmarks
The hypervisor underneath a VPS plan shapes PassMark results in ways that are easy to overlook when comparing raw numbers. KVM, Hyper-V, and Xen each handle CPU scheduling, memory overcommitment, and I/O virtualization differently, which means two VPS instances with identical advertised specs can post different Disk Mark and Memory Mark results purely because of the hypervisor layer.
KVM-based instances generally pass through hardware virtualization extensions efficiently, which tends to keep CPU Mark closer to bare-metal equivalents compared to older or more heavily paravirtualized setups. Disk I/O virtualization method matters even more for Disk Mark: a VPS using para-virtualized drivers (such as virtio under KVM) typically shows better IOPS consistency than one relying on fully emulated device drivers, since emulated I/O adds overhead on every disk operation.
Memory overcommitment policy also plays a role that is invisible from the outside. A hypervisor configured to overcommit RAM across more tenants than physical memory can comfortably support will show more Memory Mark variability under load, even if your own VPS plan’s allocated RAM never changes. This is part of why identical-looking plans from different providers, or even different host nodes from the same provider, can produce different PassMark results, and it reinforces the earlier point about running tests on your own actual instance rather than trusting a single published number.
Limitations of PassMark benchmarks for real-world VPS performance
PassMark is a synthetic benchmark, which means it measures isolated subsystem performance under controlled conditions rather than the mixed, bursty load pattern of a real application. A VPS can post an excellent CPU Mark while still feeling sluggish under an actual production workload if that workload depends heavily on network latency, disk queue depth under concurrent access, or application-level bottlenecks that PassMark’s subtests never touch.
The tool also cannot measure network performance directly, which matters significantly for remote desktop sessions, API-driven automation, and anything latency-sensitive, since a VPS with a top-tier CPU Mark and Disk Mark can still deliver a poor remote desktop experience if the network path between the user and the server is congested or geographically distant.
Database and application-specific research has used PassMark results as one data point among several when evaluating virtualized Windows environments, which reflects how practitioners typically treat it: useful for a quick comparative signal, not a complete performance picture. A VMware community discussion thread, for instance, reports PassMark observations on vSphere instances as practitioner-level reference points rather than guaranteed outcomes, underscoring that these numbers vary by configuration and should be treated as directional rather than definitive.
For a complete picture, pairing PassMark results with a workload-representative test, such as a real build pipeline run or an actual database query benchmark, gives a more honest read on whether a VPS plan fits your specific use case than any synthetic score alone.

How to run PassMark benchmarks on Windows and Linux VPS environments
Running PassMark on a Windows VPS is the most straightforward path, since PerformanceTest is natively built for Windows and installs directly through its standard setup wizard. Once installed, running the full suite produces CPU Mark, Memory Mark, Disk Mark, and 2D/3D graphics scores in one pass, though graphics scores are largely irrelevant for a headless VPS used for RDP, automation, or server workloads.
Linux VPS environments require a different approach, since PassMark’s PerformanceTest suite itself does not run natively on Linux. Many Linux-focused VPS buyers instead use comparable open tools, such as sysbench for CPU and memory testing or fio for disk I/O testing, which is exactly the approach the standardized VPS benchmark dataset uses to keep cross-provider comparisons consistent. If a direct PassMark number is required on a Linux instance, running it inside a Windows virtual machine hosted on that Linux VPS is one workaround, though the added virtualization layer introduces its own overhead and should be accounted for when reading the results.
Whichever platform you test on, checking Windows processor scheduling behavior can help explain inconsistent CPU Mark results, since scheduler changes affect how work gets distributed across available threads. A step-by-step Windows processor scheduling verification guide walks through confirming scheduler settings before you chase phantom performance differences that are actually scheduling artifacts rather than hardware differences.
AceRDP perspective: how infrastructure choices shape the numbers
We build our Windows RDP and KVM VPS hosts on modern AMD Ryzen processors and NVMe storage, specifically because those choices move CPU Mark and Disk Mark in the directions that matter for demanding workloads. We focus on delivering high-performance virtual servers for demanding workloads. If you want to reproduce a benchmark yourself, our support team can help.
— AceRDP
How AceRDP can help you benchmark with confidence
If you want a VPS built for demanding workloads, our AMD Ryzen-based KVM and Windows RDP plans pair NVMe storage with low-latency remote server access. 
We offer 24/7 technical support for our Windows and Linux virtual servers.
- Spin up a test instance on any plan from Bronze through Legend to run your own PassMark series.
- Check our knowledgebase guides for step-by-step help running and reading PassMark results on your instance.
Pick a plan, provision an instance, and run your own multi-pass PassMark series against it to see where it lands for your specific workload.
FAQ
Is PassMark reliable?
PassMark is reliable as a comparative signal when you run it multiple times and check the median result, since a single run on a VPS can be skewed by noisy neighbors or hypervisor scheduling. It is less reliable as an absolute measure of real-world application performance, since it tests isolated subsystems rather than mixed production workloads.
Which is better, VPS or cloud hosting?
A VPS and cloud hosting both run on virtualized infrastructure, so the real comparison is between specific plans and their resource guarantees rather than the category labels themselves. Choosing between them depends on whether you need predictable fixed resources, which most VPS plans provide, or elastic auto-scaling, which cloud platforms emphasize.
How much RAM does a VPS need?
The right amount of RAM depends entirely on the workload, with lightweight remote desktop or automation tasks needing far less than database or in-memory caching workloads. Checking Memory Mark alongside your application’s actual memory footprint gives a more useful answer than a generic RAM recommendation.
Can I find a $5 VPS server?
Very low-cost VPS plans exist across the hosting market, though pricing varies by provider, region, and resource allocation. For a performance-focused option, see AceRDP: current prices are on AceRDP’s website.
Sources
- PerformanceTest FAQ - V10 Results
- PerformanceTest FAQ - Hard Disk Results
- Memory benchmark - Database Operations in virtualized operating system - PassMark Support Forums
- README.md at main · devguoo/vps-benchmark-results
Authoritative links for verification and replicating tests
- PerformanceTest FAQ - V10 Results
- PerformanceTest FAQ - Hard Disk Results
- Memory benchmark - Database Operations in virtualized operating system - PassMark Support Forums
- README.md at main · devguoo/vps-benchmark-results