Romex Software Forum

Hi SUpport,

Will there a plan to give user advance option to relocate the overhead memory to some other place like SSD? I think newer SSD these days should be fast enough to handle the overhead constant changes to track cached data. For a little performance loss, this would give the back the extra memory, especially on restrict laptop, to reallocate memory for a larger L1, 4K sector, or just for Windows. There any consideration for this option in the future?

Thanks,

minhgi

Change what would normally be a few nanosecond operation to be more like 20-30 miliseconds? Sounds like a change that would slow everything down.

Pro-tip: don't use 4k cache sectors. I found the best for reading/writing is 64k on my machine. Even if you use 16k the overhead in Primo isn't bad on a smaller cache (which you would have on a RAM-limited laptop). 4k was never very useful in my opinion - larger means you take advantage of pseudo-read-ahead on defragmented spindle drives (exactly what you'd use on an older laptop).

Yeah. So I set sector to 4K for a week and 16K another week, it seem the 16kb is over all faster due to the pseudo-read-ahead. It just I lost cache space in the L1\L2 cache. Oh well, you can't have a full cake but just a slice. It fine for now. Maybe another year downline, my request may get fulfil. Thanks for the suggestion, Jaga.

As Jaga said, this will affect the speed a lot, so we don't have plans to support this. However, we'll continue studying to reduce overhead.

I have a 10GB L2 SSD cache (approximately) and 16k cluster size and the overhead is 800 bytes per cached cluster (just over 500 MB overhead), which seems like a lot of metadata to track a cluster in a cache.

I know it's hard work to make code more efficient. I appreciate your hard word and I like this software (I paid).

Can the 800 bytes per cluster overhead be reduced to 400 with clever coding, or more tightly packed structure, or ???

Thanks for listening.

V3.x already reduced the overhead amount a lot compared v2.x, making structure tightly packed. Other possible ways to reduce overhead will cost performance speed, so we haven't adopted them yet.