Question 2022 RAM Drives

[cellarnoise]

I've done some searching on this sub-forum and the googlees, and probably most is over my HPU's... should be single cpu / head HCPU head , but whatever.

Anyone know of any projects related to the DC effort that benefits much from a RAM drive? It appears that I have a few puters only on the "DC" that have at least twice (2X the RAM) RAM that is needed. I'm adding extra RAM references to help the search engine I hope? What the R.A.M. do I know?

I have forgotten more ram, r.a.m. , RAM, and Random Access Memory, and RAM DRIVE, and ram drive, and r.a.m. drive than I can know remember. RAM is important none the less ram / 'RAM' / "ram drive"......

Please help, though it will be a nothing burger? Just have NVME 3 or 4 and life will be goodish! in 2022 ish

 

[StefanR5R]

If you already have flash-based mass storage and a good amount of RAM, there is likely no need for a RAM disk for any of the DC projects:

• Read latency of most flash based storage devices (even SATA, not just NVME) is already low enough to serve the needs of the various DC related applications very well.
• Write latency is hidden well enough by the operating system if there is enough RAM for filesystem buffers.

Actually some are of the opinion that flash storage is overkill for DC nodes, and rotating disks are adequate. I on the other hand don't want to deal with computers which have their active working data (e.g. a boinc data directory), or worse: their operating system, on high-latency mass storage such as spinning disks, as I have no patience for such things.

- - - - - - - -

Also related to your question: Recently I tried if putting the boinc data directory into a RAM disk would help with "rosetta python projects" troubles. (Notably, the vboxwrapper which is supplied by R@h often claims that a VM has become unmanageable.) It didn't help with this one, even though "rosetta python projects" appears to be heavy on disk I/O. That is, whatever issue with responsiveness between vboxwrapper and VM there is, it couldn't be fixed by reducing the already low latency of flash memory + RAM buffers further to even lower latency of a RAM disk.

 

[cellarnoise]

So, are there any silver bullets for D.C. currently?

Just the usual hardware and a few software tweaks when they are available?

Linux versions can sometimes provide some bump, and?

 

[Endgame124]

So, are there any silver bullets for D.C. currently?

Just the usual hardware and a few software tweaks when they are available?

Linux versions can sometimes provide some bump, and?

Outside of using Linux and current hardware, there aren’t a ton of ways to increase ppd outside of over clocking.

On the flip side, if you want to increase points per watt, there are highly likely a number of things that could be done. On my Pi 4s with some significant effort in tweaking, I was able to decrease power usage 25% for basically 0 impact on ppd.

 

[StefanR5R]

The Windows/Linux thing can of course go both ways. Apart from projects which may only have work for one of the two, there are also occasional projects whose application version for either Windows or Linux is performing somewhat (or a lot) better than the other. This is can be caused by differently optimized libraries linked into the executables. Or there a few cases of a native application build made available for one platform but only a virtualized application for the other platform. The latter will invariably bring lots of storage and RAM overhead, might contain a lesser optimized exe, and is typically a major PITA to get running and to keep running.

And another obvious point: Downclocking, power limiting, and other power efficiency related tweaks actually increases PPD for folks whose production is not limited by the hardware capacity, but instead by available electric circuits, or cooling capacity of the home, or by allowable cooler noise, or notably by the budget for electric power bills.

But back to the subject of this thread: Unfortunately, DC nodes either have much more RAM than they really need for one application, or much less RAM than they could use for another (badly optimized, or worse: virtualized) application. In those cases where there is much more RAM than really needed, the idea of supplying a RAM disk to hold the BOINC data directory sounds intriguing; but in most cases the performance benefit will be practically zero, while you add in the risk of major data loss at a sudden power loss.

 

[Ken g6]

The first thing I do when I install a Linux is put /tmp in a ramdisk. I add these lines to /etc/fstab:

# /tmp in RAM:
none /tmp tmpfs nodev,nosuid,mode=1777 0 0

However, I don't think that helps DC any.