[How To] Using the Argon One case for the Pi 4B together with piCorePlayer (7.x)

[paul-]

What are you using to test speed? It could be just your method of testing.

[chill]

What are you using to test speed? It could be just your method of testing.

That's certainly possible - I'll admit I don't have a good understanding of the conditions required to get an accurate result.

I found the basic commands here, and I made the script below.

# clear cache
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
#write test
echo "Write test"
sync; echo 3 |sudo dd if=/dev/zero of=./test.tmp bs=500K count=1024
# clear cache
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
# read test
echo "Read test"
sync; sudo time dd if=./test.tmp of=/dev/null bs=500K count=1024

To run it I simply cd to the root of the drive to be tested then call the script from /home/tc. If I delete test.tmp before running the test, the write speed is somehow about twice as fast, faster even than the subsequent read speed.

tc@pCPServer:/mnt/Music$ rm test.tmp
rm: remove 'test.tmp'? y
tc@pCPServer:/mnt/Music$ /home/tc/rwtest.sh
3
Write test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 1.862952 seconds, 268.4MB/s
3
Read test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 2.146489 seconds, 232.9MB/s
real	0m 2.14s
user	0m 0.01s
sys	0m 1.15s
tc@pCPServer:/mnt/Music$ /home/tc/rwtest.sh
3
Write test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 2.997269 seconds, 166.8MB/s
3
Read test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 2.119096 seconds, 235.9MB/s
real	0m 2.12s
user	0m 0.01s
sys	0m 1.14s
tc@pCPServer:/mnt/Music$ /home/tc/rwtest.sh
3
Write test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 3.249851 seconds, 153.9MB/s
3
Read test
1024+0 records in
1024+0 records out
524288000 bytes (500.0MB) copied, 2.139627 seconds, 233.7MB/s
real	0m 2.14s
user	0m 0.01s
sys	0m 1.15s

Before flashing the new firmware, I ran this test a few times (without deleting test.tmp) and obtained write speeds ranging from 210-245MB/s, and read speeds ranging from 255-300MB/s. Looking at the second and third tests above (after flashing the firmware) the write speed is around 160MB/s and the read speed is around 235MB/s.

[chill]

I couldn't resist looking into this further, so I've ordered another of the Argon M.2 adapter trays. I'll keep this new one strictly 'factory', but it will allow me to double-check my original speed tests.

I've also discovered the 'ASMTool' project to read and dump the original firmware, which is a feature not included in the flashing tool from ASMedia. I thought it might give me some clues about the speed difference - maybe the dump will include the necessary configuration, and I can write it back to my original M.2 adapter tray.

ASMTool is a C# project, which I've managed to build using Mono under Raspberry Pi OS, apart from one Linux-specific file for which the given compile command fails:

pi@raspberrypi:~/ASMTool/AsmTool $ gcc -fPIC -Ofast Linux/AsmIOLinux.c -o libAsmIOLinux.so
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/crt1.o: in function `_start':
(.text+0x34): undefined reference to `main'
collect2: error: ld returned 1 exit status

That's got me stumped at the moment.

[paul-]

add a -c to the gcc commandline. This is a library, and does not have a main routine.

[chill]

Thanks Paul - that allowed the library to compile without error, so I'm a step further on. The instructions say to "Place the resulting .so file next to the ASMTool executable (obtained by building this project)", so I moved it into the /bin/Debug folder, where there's an AsmTool.exe, but when I then attempt to run that exe file I get the same error as I did without it.

pi@raspberrypi:~/ASMTool/AsmTool/bin/Debug $ ./AsmTool.exe 
Unloading ASM Driver...
Loading ASM Driver...

Unhandled Exception:
System.DllNotFoundException: AsmIOLinux.so
  at (wrapper managed-to-native) AsmTool.LinuxNativeIO.LoadAsmIODriver()
  at AsmTool.LinuxAsmIO.LoadAsmIODriver () [0x00001] in <fbb7d40e103846ea973443f2e32cdf1d>:0 
  at AsmTool.Program.Main (System.String[] args) [0x00022] in <fbb7d40e103846ea973443f2e32cdf1d>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: AsmIOLinux.so
  at (wrapper managed-to-native) AsmTool.LinuxNativeIO.LoadAsmIODriver()
  at AsmTool.LinuxAsmIO.LoadAsmIODriver () [0x00001] in <fbb7d40e103846ea973443f2e32cdf1d>:0 
  at AsmTool.Program.Main (System.String[] args) [0x00022] in <fbb7d40e103846ea973443f2e32cdf1d>:0

I'm out of my depth here. I tried renaming the .so file to AsmIOLinux.so, but that made no difference. Maybe I'll try the Windows build.

[paul-]

With linux systems, you typically need to tell the shared object linker where the library is.

Try copying the library to /usr/local/lib (or /usr/lib)

Then run sudo ldconfig (This command finds all the .so libraries in the configured search paths and build the cache for the linker)

[chill]

Thanks Paul - I tried that (4 times: both locations and with the original and renamed .so file), but the executable always fails with the same error.

I don't want to take any more of your time, so I'm going to see how I get on with the speed tests on a factory-fresh adapter. If there's really a distinct difference I might revisit this, but if not I'll just stick with the more recent trim-enabled firmware.

[chill]

My new factory-fresh Argon M.2 adapter tray arrived today (same firmware as the original one had: 140704a10000), so I've done some comparative speed tests. And after all that there's no difference between this one and my original version(firmware upgraded to 141126a1ee82)! Using the same M.2 SSD drive swapped between the adapter trays, I ran my earlier speed testing script 5 times - the first time with the test.tmp file deleted, and the subsequent four times without deleting it each time. I then averaged the results of the latter four tests.

                    New Adapter   Old Adapter
Ave write (MB/s)     145.1         145.0
Ave read (MB/s)      227.5         225.9
Min write (MB/s)     137.2         135.3
Max write (MB/s)     163.0         170.3
Min read (MB/s)      226.8         222.0
Max read (MB/s)      228.1         227.2

I had made a written note of the results of this test performed when I first received the adapter tray and the SSD, so it's not my memory playing tricks. It was definitely about 50% faster (although I can't be sure whether I was consistent about deleting test.tmp or not, but its presence doesn't affect the read speeds). I can only guess that maybe the difference is down to the drive now having about 180GB of music files on it, whereas initially the tests were done with an empty drive. Could that affect the speed tests? I'm not about to delete everything just to redo these tests, but I'm happy now that the trim-enabled firmware has not affected the read and write speeds.

So now I have a spare Argon One M.2 adapter tray. What to do with it..... Maybe I should buy another Argon One case and another Raspberry Pi!

[Greg Erskine]

Thanks carsten_h,

Added "Setup the Argon One case for the Raspberry Pi 4B" in Projects section.

Still have some formatting to do, but its a good start.

[carsten_h]

but its a good start.

Yes it is! Thank you!