LFS: Benchmark read/write performance, investigate opportunities to increase write performance

[DeflateAwning]

• Setup a macro to disable debugging UART prints in the critical path of LFS writes (i.e., in the FLASH and LFS drivers/implementations).
• Create a telecommand to benchmark the read/write performance by reading and writing large files. Output a report with the speeds.
• Find ways to optimize these speeds, if required (TBC).

[parker-research]

Started a branch (parker/lfs-benchmarking-i57).

Prelim LittleFS

On reading a 31-byte file, it takes 96ms with debugging prints enabled, and 86ms with them disabled.

Flash Benchmark

After creating a flash driver benchmarking (so no LittleFS) involvement, the benchmark shows the following (127 byte test):

Received telecommand (len=47): 'CTS1+flash_benchmark_erase_write_read(0,0,127)!'↴
======= Telecommand ======↴
Received telecommand 'flash_benchmark_erase_write_read'↴
======== Response (duration=475ms, err=0) ========↴
Erase: 472 ms↴
Write: 2 ms↴
Read: 1 ms↴
↴
==========================↴

That is, the erase is the part that takes the longest (by a large margin), but the read/write also take a surprisingly-long time.

With a 512-byte test, timing was 4ms read and 4ms write. 512 bytes per 4ms is 1.024 Mbps (megabits per second) = 128 kB/s (kilobytes per sec), which is on par with the current bus speed configuration. No problems at the flash level, thankfully.

[parker-research]

LFS benchmarking appears to show that there's a memory leak or similar, because it slows down on each subsequent benchmark execution.

The first benchmarks (fastest at the start) were 127 bytes per 50 ms = 20 kilobits per second. More work is required.

[JohnathanBurchill]

I've played with the LFS code.

-Mounting the filesystem takes a few seconds. -Listing a directory takes a few seconds, even with just a few files -Truncating a file to 1337 bytes takes a few seconds

[DeflateAwning]

I'm kinda thinking we might need to "stream" the MPI data directly into the flash memory as raw data, and then copy it into a file (and store metadata, like timestamps/location associations) for downlink upon stopping the MPI data collection.

This won't be an issue imo, because we have 4 memory modules. We could use one flash module as this temporary store, and the others for LittleFS, if we're still having really bad performance.

[JohnathanBurchill]

That could work very well. Let's see how it goes with profiling LFS.