| |
alterus
Registered: Feb 2016
Posts: 10 |
Fastest SD2IEC performance
I'm currently using an SD2IEC as a system drive for my BBS. I've been experimenting trying to get the best performance possible out of the SD2IEC, especially with a large number of files. I currently have approximately 400 files on the subs partition using a FAT32 format. It can take up to 5 seconds to seek some files. My goal is to have several thousand files on the SD card and still have reasonable performance.
Does anyone here have experience with different SD2IEC configurations, including formatting type or SD card type, to optimize SD2IEC seek performance? I might add, I'm also using JiffyDOS. |
|
| |
jcompton
Registered: Feb 2006
Posts: 70 |
Have you considered directly asking Ingo Korb, the firmware developer, for tips? I've found him pretty responsive in the past. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
I'd use ide64 with sd adapter. Soci worked his ass off to make it fast and reliable for years and years. |
| |
ilesj
Registered: Jun 2012
Posts: 27 |
Quoting alterusDoes anyone here have experience with different SD2IEC configurations, including formatting type or SD card type, to optimize SD2IEC seek performance?
I have understood that the typical SD card speed ratings have very little to do with random access read performance. All in all the speed class ratings indicate write performance, and the speed class ratings starting from Class 10 are for sequential write. So it might be that some older card with Class 6 or 4 may outperform some "faster" cards in random access read and write with small files. |
| |
soci
Registered: Sep 2003
Posts: 479 |
It's slow because it has to go through a lot of data for all those filenames. Especially for FAT where you have the 8.3 entry plus some additional long filename entries for the same file.
Simply don't put that many files in a single directory. Instead organize them to several directories if this works with the BBS.
Long directories are not that much an issue for modern filesystems using hashes and trees on directories. FAT uses lists so searching performance is not all that good.
The CFS filesystem I made for IDEDOS 0.9x is using lists for directories too. But each entry is only 32 bytes so it needs to read and process much less data for searching the same number of files.
CFS was designed to store C64 stuff so it's using 16 character entries with a 3 character type. This might feel limiting but it's better for compatibility for software expecting floppy disks or CMD hardware.
Just for fun I've timed the worst case (file not found) for a directory with 400 entries on CFS. It's roughly 0.3 seconds with a CF card on a stock C64 and ~15 milliseconds using a SuperCPU.
So there's a serious performance problem there if even a 985 kHz 6502 beats it by this much. My opinion is that a little fine tuning will not give the sort of performance boost you're hoping for. |
