Some cloud providers sell CPU types by clock speed, such as "5 GHz" or "3 GHz". We wanted to know what that difference means for real file jobs: compressing a PDF, turning its pages into JPGs and encoding a video. So we ran the same test script on ten cloud machines at the same time, five from a 5 GHz class and five from a 3 GHz class, and recorded which chip each one actually had.
The short version
- The 5 GHz class was faster on every operation. On average, the 3 GHz class needed 37% more time to compress a PDF or encode a video, and 43% more to turn PDF pages into JPGs.
- The label hides a mix of chips. Ten machines gave us nine different AMD chips, from a 2019 EPYC to recent Zen 5 parts.
- The best 3 GHz chips caught up with the slower 5 GHz ones. The oldest chip took 2.3 times as long as the fastest one to compress the same PDF.
- On every machine, 2 vCPUs were one physical core. Two files on one core finished about 35% sooner than running them one after the other.
How we tested
- Ten cloud machines, with 2, 4, 8, 16 and 32 vCPUs in each class, all tested at the same time on 8 November 2026.
- Ubuntu 24.04, Ghostscript 10.02.1, FFmpeg 6.1.1, gzip and Perl.
- The same 50 MB test PDF on every machine: 103 A4 pages of 300 dpi photo-like images, built from fixed seeds, so every copy was the same size.
- Every job ran on one thread, pinned to its own vCPU with
taskset. The results show the speed of a single thread, which is what decides how long one file takes. - Each one-file test ran 3 times. The clock speed was read from the system 2 seconds into each run.
| Operation | What it ran |
|---|---|
| Compress PDF | Ghostscript, /ebook setting (images reduced to 150 dpi) |
| PDF to JPG | Ghostscript, every page at 150 dpi, JPEG quality 85 |
| Video | FFmpeg, H.264 (x264 medium, CRF 23), one thread, a 6 second 720p clip with added grain (81 MB) |
| gzip | Level 6 on 160 MB of random text |
| Calculation | A Perl loop of 187 million steps, a pure CPU check |
The chips and their times
One file at a time, in seconds. Lower is faster.
5 GHz class
| vCPUs | Chip | Clock | Compress PDF | PDF to JPG | Video |
|---|---|---|---|---|---|
| 2 | EPYC 4564P (Zen 4) | 5.0 GHz | 32.4 | 4.90 | 15.1 |
| 4 | Ryzen Threadripper 7960X (Zen 4) | 4.8 GHz | 33.8 | 5.00 | 14.9 |
| 8 | EPYC 4565P (Zen 5) | 5.5 to 5.6 GHz | 25.0 | 4.16 | 12.2 |
| 16 | EPYC 9575F (Zen 5) | 5.0 GHz | 27.8 | 4.39 | 13.5 |
| 32 | EPYC 9575F (Zen 5) | 5.0 GHz | 27.9 | 4.28 | 13.4 |
3 GHz class
| vCPUs | Chip | Clock | Compress PDF | PDF to JPG | Video |
|---|---|---|---|---|---|
| 2 | EPYC 9655P (Zen 5) | 4.3 to 4.55 GHz | 31.1 | 4.92 | 15.4 |
| 4 | EPYC 9654 (Zen 4) | 3.7 GHz | 44.0 | 6.53 | 19.6 |
| 8 | EPYC 7702P (Zen 2, 2019) | about 3.3 GHz | 56.4 | 10.13 | 26.2 |
| 16 | EPYC 9355 (Zen 5) | 4.4 GHz | 31.6 | 4.96 | 15.1 |
| 32 | EPYC 9965 (Zen 5c) | 3.7 GHz | 38.0 | 5.88 | 18.2 |
Averages
| Operation | 5 GHz class | 3 GHz class | Extra time on 3 GHz |
|---|---|---|---|
| Compress PDF | 29.4 s | 40.2 s | 37% |
| PDF to JPG | 4.55 s | 6.48 s | 43% |
| Video | 13.8 s | 18.9 s | 37% |
| gzip | 4.07 s | 5.11 s | 25% |
| Calculation | 5.04 s | 5.57 s | 11% |
The 8 vCPU EPYC 7702P machine stopped partway through the test, before its gzip and calculation runs. The 3 GHz averages for those two use four machines.
What stood out
- The clock label is a class, not a chip. Two of the "3 GHz" machines had Zen 5 chips running at 4.4 and 4.5 GHz.
- Newer chips closed most of the gap. The EPYC 9655P and 9355 compressed the PDF in 31.1 and 31.6 seconds. That's faster than two of the 5 GHz machines, at 32.4 and 33.8 seconds.
- The old chip was the outlier. The EPYC 7702P, a 2019 Zen 2 part without AVX-512, took 56.4 seconds: 2.3 times as long as the EPYC 4565P.
- A simple CPU loop hides the difference. The Perl loop was only 11% slower on the 3 GHz class, while real file jobs were 25 to 43% slower.
- Clocks held under full load. With every vCPU busy, the 5 GHz chips dropped by 0.3 GHz at most (the EPYC 4565P went from 5.5 to 5.3 GHz). The 3 GHz chips didn't drop at all.
vCPUs are threads, not cores
- On every machine, 2 vCPUs were the two threads of one physical core. No core was shared with anyone else, and steal time was 0.
- A single-threaded job used 99 to 100% of one vCPU, never more.
- With two files on the two threads of one core, each file ran slower, but the pair finished sooner than running them one after the other:
| Operation | Each file slower by | Pair finished sooner by |
|---|---|---|
| Compress PDF | 27 to 30% | 35 to 36% |
| PDF to JPG | 50 to 60% | 20 to 25% |
| Video | 32 to 40% | 30 to 34% |
| gzip | 30 to 41% | 29 to 35% |
| Calculation | 57 to 121% | -11 to 22% |
Real file jobs gained a lot from the second thread. The pure calculation gained little, and on some machines it was slower as a pair than one after the other.
What we chose
For file jobs, the 5 GHz class was clearly faster, and also more predictable. Its Compress PDF times stayed between 25.0 and 33.8 seconds, while the 3 GHz class ranged from 31.1 to 56.4.
We ran these tests while choosing the machines for FilesOkay. That's why every file job on FilesOkay runs on the faster 5 GHz CPUs, with the 3 GHz ones kept only as a backup.
These were test machines on one day, and another day may give you different chips. If you rent cloud CPUs for file work, check which chip you actually got before trusting the label; lscpu is enough.
I used an AI assistant to organise the data and edit this post; the tests and numbers are ours.
