RasPi 4, 4gb, dietpi w/ RasPi OS default config: https://pibenchmarks.com/benchmark/59605
That’s not the issue. Is there any possibility of a negotiation issue with the USB 3.0 port? It’s almost as if its speed is that of a 2.0 port. Just an idea. Or perhaps an issue with the SSD controller in the argon one case? The controller is ASM1153E. Just spitballing ideas.
You did reboot after replacing the config.txt, right?
One more idea:
hdparm -B 254 /dev/sda
If /dev/sda is the benchmarked root drive. This basically disables the “advanced power management”. E.g., if the drive supports it (modern ones often do not) it prevents spindown, of course not relevant for an SSD, but AFAIK it is the drives firmware/driver what it does with it. Can be made persistent in /etc/hdparm.conf.
Ah, and in /etc/modprobe.d/ we blacklist WiFi, Bluetooth and some GPU feature modules. Should all not affect disk I/O, but since we are at the end of the obvious possible reasons…
I did reboot, quite a few times, I tried to replace the cmdline config, it borked the whole system. Figured ‘when in Rome’. I will make the adjustments in your post and post results. It’ll be later tonight.
The root=UUID=… needs to stay the same, else the kernel cannot find the root filesystem to mount 
.
Also net.ifnames=0 needs to stay, else network won’t come up until it gets reconfigured with “predictable” instance names.
I did keep the UUID from the original DP config. But I could’ve messed something up, missing space or some such. It was pretty late.
@gentoonix Any updates? Im really curious in what is causing this issue
I apologize for letting this post wither, I recently moved across the country and I have just now got things set back up. I am currently updating dietpi, I’ll post again when I run some tests. Before I get too involved, should I spin up the beta and see if the issue is still present? I ran an IO bench before updating, mid 30sMB/s both ways.
So, I enabled idle time (hdparm command) and my write jumped from 24-25MB/s to 126MB/s and read went from 28MB/s to 330MB/s. It’s not as fast as RasPiOS (EDIT: it is, I went back to check), but it’s definitely a massive improvement. Thanks guys!
After using hdparm, my speeds are back. I ran a bench using the same tests as the links before, my score is back in the 7000s, here is the link. Dietpi is amazing. Thank y’all, so much, for helping and your patience with my absence!
Setting persistence in hdparm.conf, OCed to 1900mhz, performance governor: Benchmark #61520 - pibenchmarks.com
Great, so it’s indeed APM which has such a massive effect on the M.2 SSD. Quite surprising, especially since I cannot imagine that lower speed has such an effect on power consumption here (considering that slower also means longer load). APM makes sense for spinning drives which may lower rpm from 7200 to 5400 or so, and where idle spin down really means no rotation, but on an SSD or flash drive 
?
Not sure now whether thinks is a rare case or whether we need to change our default hdparm.conf to touch APM and spin down for rotating drives only. But this makes it complicated since we’d need to check for every drive individually, e.g. when detected by dietpi-drive_manager or so.
I don’t think I have another SATA m.2 to test. But I’ll definitely look around and check. This micron drive is a bit older, maybe 2015-2017, I bought the argon one case specially for this useless (otherwise) drive. All my other drives are NVMe. I will mention this tidbit; when I tried to set hdparm -M, I did get an error, I was just trying to see if the kernel saw it as a mechanical drive or not before setting APM persistent in the config. But it definitely made a difference. I changed the APM on a new install, stick settings, and it increased from 25(ish)MB/s to over 130MB/s. I wasn’t expecting to saturate the drive, it’s interfacing through USB3.0, I’m friggin happy. 
I’m more than happy to help ya test, though.
I looked up the release date on my SSD, it was 2016. I played around with OC and governor settings, there isn’t much of a difference.
Stock clocks, schedutli: Benchmark #61555 - pibenchmarks.com
1900mhz, perf gov: Benchmark #61554 - pibenchmarks.com
There are some improvements in disk speed with either OC or gov changes, but not enough to prematurely kill my SBC.
I think I may have another m.2 SATA. I’ll check it out and let y’all know.
Some interesting results, not really sure how to take them. The 16GB SATA m.2 I have has the same performance regardless of HDPARM settings. I haven’t tested it with RasPi OS, but that is next, I’ll edit this post with those results. I’m also going to test a Samsung 980 NVMe drive in an enclosure, to see if my Micron drive is just a fluke.
16GB, DietPi, Stock Clocks, Stock HDPARM:
16GB, DietPi, Stock Clock, HDPARM APM = 254 SpinDown = 0:
virtually no change between them.
NVMe via USB 3.0 Sabrent enclosure, stock clocks, stock hdparm, MATE:
Interesting, so it’s the one older NVMe controller which reacts to APM. However, looks like we at least need to add drive specific settings for it to dietpi-drive_manager.
The two older drives aren’t NVMe, they’re SATA. They’re m.2 form factor, but not NVMe. The NVMe drive I tried had zero issues. But the 16gb SATA I tried today has extremely poor write performance on USB-C, too, around 52MB/s, I tested it after dietpi. I just didn’t have any other m.2 SATA drives to try.
Can you describe what exaxtly did you do? (How to enable the idle time and how to make it persistent in hdparm.conf)
Sure, I typed ‘nano /etc/hdparm.conf’
Changed apm = 254. Ctrl + o, enter, ctrl + x. Then reboot.
The change btw disables idle spin down (for most spinning drives, which support APM at all) by setting Advanced Power Management to the highest level/highest performance. For HDDs to spin down on idle timeout usually APM needs to be 127 or lower, while this does not yet affect RPM.
I know this is a solved thread, hdparm is definitely the solution to this specific issue. I had a bit of a snafu and had to reinstall my trusty dusty Pi 4. Upon fresh reinstall, the initial issue persisted, after editing my hdparm.conf and issuing the corresponding command, the issue was resolved. Using the same pibenchmarks.com bench, my score pretty much doubled. Stock: 3642 Hdparm: 6496. Just wanted to let y’all know my very specific issue is still an issue, but an easy one to overcome. A huge thanks to the dietpi team!
The fastest USB storage options for Raspberry Pi | Jeff Geerling
Jeff Geerling did a test on speeds
Raspberry Pi USB Boot - UASP, TRIM, and performance | Jeff Geerling