You are comparing benchmarks with random numbers generated by hdparm (which was a benchmark last century but not today any more).
This is 5 times hdparm with a cheap Kioxa consumer SSD (the junk currently mounted on my Rock 5B):
Timing buffered disk reads: 622 MB in 3.00 seconds = 207.27 MB/sec
Timing buffered disk reads: 1506 MB in 3.00 seconds = 501.95 MB/sec
Timing buffered disk reads: 2670 MB in 3.00 seconds = 889.99 MB/sec
Timing buffered disk reads: 4894 MB in 3.00 seconds = 1630.62 MB/sec
Timing buffered disk reads: 4242 MB in 3.00 seconds = 1413.98 MB/sec
First two are with cpufreq on lowest setting, next two with cpufreq on the highest setting. Always a little core first followed by a big one.
With Radxa’s OS images until recently (see here for details) and with Armbian still and most probably forever the needed tweaks aren’t applied to ramp up CPU clockspeeds with I/O workloads. As such with hdparm in ‘fire and forget’ mode you’re ‘benchmarking’ the cpufreq scheduler/governor more than storage. And as can be seen above this makes a difference of 210 - 1630 MB/s.
Last check above was with default settings (random behaviour based on what scheduler and cpufreq governor do). Are these 1413.98 MB/sec the ‘drive performance’?
No of course since hdparm uses a block size from last century (128KB were huge back then when Linux developers added the -t and -T switches to the tool when they dealt with spinning rust attached to an IDE interface or worse). And also the --direct switch was missing.
Today we should check with 1M or better 16M. With my junk Kioxa SSD this then looks like this using taskset -c 4 iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1:
kB reclen write rewrite read reread
1024000 16384 1046735 1047446 2572526 2582696
That’s more close to ‘drive performance’ than misusing hdparm. 1000/2600 MB/s write/read.