I utilize less than a quarter of my RAM during imaging with my Rpi4 using SM-OS and was thinking I could use that unused RAM for a RAM Disk to give me more speed for some applications. I know it is a 'temporary drive' but I wanted to brainstorm ways to utilize that extra RAM. A 2GB RAM disk that held all temporary frames would be nice to start, so platesolving, image preview, focusing frames, would happen on the RAM drive and be exponentially faster than using the SD card. I could also use the RAM drive for lucky imaging with smaller sensors, although it would certainly fill up quickly. I suppose I could script the RAM drive to tail and copy to a slower flash drive or external SSD drive. A smart enough script could allow full-frame lucky imaging on a humble Pi4 that would take the exposure, save it to the RAM disk, and then copy the FITS/RAW to an external flash/SSD/NAS in the background.
This is really just a question of tinkering and not a feature request. Ideas?
then tweaking Stellarmate to configure it to output the files to the ramdrive - I don't own a Stellarmate but I think it's linux based and wouldn't be too difficult.
However I'd also think the bottleneck would be on the USB transfer speed from the camera to the RPI4.
It depends - I have an USB2 camera so putting things in ramdrive would not make much differences to me
Then look at rsync to copy the files from the ramdrive to permanent storage
Just a feeling that the performance gain will be limited - rsync would also need CPU + mem to operate
Yet writing to ramdrive would cause less writing to the SD card to avoid the SD card wearing..
Just wondering.....has anyone gone further with the idea of using a ramdisk? I'm about to add an SSD to my Pi4-4GB config, and wondered whether a layered SSD/ramdisk config might be an interesting option to put into play.
The Pi4 only uses about 1.1GB of memory +/-, so adding a ramdisk of say 100MB - 500MB shouldn't really impact free memory meaningfully. Looking at the Kstars/Ekos config, only the location for saved images is in play for ramdisk (default is /home/stellarmate which would change to the configured ramdisk). The Darks library seems hard configured to .local/share/kstars/darks, but maybe access is so infrequent that it wouldn't matter to try and make this more configurable? Root would still be reconfigured to SSD.
As is described by @Kaydubbed above, an rsync / script would need to move ramdisk image files to SSD during off-peak moments. It would need to do this frequently enough to remove any doubt over potential loss of data (i.e. system crash loss). The fly in the ointment might be that if an efficient recipe (i.e. timing) for doing transfers from ramdisk to SSD can't be found, then maybe the ramdisk would be wasted as the transfers must happen anyway? Thoughts? Seems worth an experiment to see what performance would look like....
I would not use a ram disk for files that are destined for the ssd unless you have an abundance of free memory (not rpi) . Linux uses most free memory for the page cache very efficiently. There are cases where a ram disk can help, but it is more likely to hurt performance than help unless you understand the access patterns and usage scenarios very well.
@geirert: Are you using rpi generically? (for all Pis, or specifically - first gen?). Do you think that even a 50-100Mb ram disk, sized for the 40Mb preview image + some overhead would not be worth the effort or detract from a 4Gb system? I can't imagine that this small loss to page cache would be worse than the file write (even if to SSD). I'll probably give it a test whirl if I can get through this fsck check and get the SSD going....seems to be taking longer than I thought for the first check....