Show us your SSD performance 2

[garuda]

Everything is through the roof but the read access time appears ok but not that great. I wonder what is going on here.

If READ/WRITES are high, but access times are only moderate/high, maybe AS-SSD is reading access time from the SSD itself, but also getting READ/WRITEs stats from data moving in the RAM image of the drive and thinking it's the SSD doing it all instead of the RAM. That might explain the discrepancy betw access times and Read/Write speeds.... just a guess.

 

[whs]

Would be nice if one could read them.

Click on the image, wait for the new popup, click again.....brings up full size image. I know it is a bit hard to read, due to the dark theme, but it is readable.

I know all that. But if you have eyes with 40% vision, you need contrast.

 

[whs]

Crucial M500 @ $140 for a 240GB is a good deal (see promo code)

Newegg.com - Crucial M500 240GB SATA mSATA Internal Solid State Drive CT240M500SSD3

 

[gldndragn]

@ WHS

True......I hadn't thought about that Sorry.

 

[paulpicks21]

I was just testing this PrimoCache out, it certainly gives some impressive numbers.

 

[mjf]

The numbers are impressive but are you testing the RAM rather than the SSD? Does the caching give a noticeable improvement in typical PC activities when using the SSD? For example if you copy a large file on the SSD do you notice those blistering sequential R/W speeds?

 

[paulpicks21]

The numbers are impressive but are you testing the RAM rather than the SSD? Does the caching give a noticeable improvement in typical PC activities when using the SSD? For example if you copy a large file on the SSD do you notice those blistering sequential R/W speeds?

A good point and something that I have just tested out. It certainly does not equate to the figures in the benchmark but it appears there is some difference.
I tested it out using the BF4 file and copied it to desktop, once with the cache enabled and once without, I gave it enough time in both instances to level out to a stable rate. The difference was 52MB/s in favor of the cache.

 

[whs]

That's a noticable difference - nearly 30%.

 

[paulpicks21]

That's a noticable difference - nearly 30%.

Yes, also the speed appears to increase with the amount of RAM you allocate to the cache. The original test I did was with 4GB allocated, with 12GB allocated it improved some more.

I think I need to do further testing to record the actual time taken for all 3 runs to give firm evidence that it is a good improvement.

 

[whs]

This is for the rich who have acres of RAM,

 

[paulpicks21]

OK the results are in, it started off real strong with 12GB allocated but dropped off a fair bit in the end.

So the actual times for transferring the 24.1GB file are as follows -

Without the cache tool running - 2m 38s
With 4GB of ram allocated - 2m dead
With 12GB of ram allocated - 2m dead

So the extra ram actually serves no purpose in relation to transferring large files. But at any rate with the cache enabled it saved nearly 40 seconds which is quite impressive for the total time we are talking about.

Paul.

 

[gldndragn]

Hmmmmm............it seems as if I may have uncovered a little gem, eh?
Most daily activities don't seem to be affected, but it still works. We are gonna have to follow the development of this proggie.......no?

It seems to be along the same lines as Samsungs "rapid mode" from their "evo" line.

 

[Britton30]

Would it be more meaningful to copy a single large file such as a HD video file? I run tests to compare USB 2 vs. USB 3 and it was suggested I do the same.

I'm unsure how Rapid mode works, with it enabled I show all RAM (16GB) available and resource monitor shows no large amount in reserve for it.

 

[mjf]

I clearly need a rethink on caching. The SSD is essentially a solid state memory device which is slower than your high speed RAM and even SATA 3 speeds can't be met. Can multiple threading be assisting here? (probably a dumb question).
Also, can PrimoCache assist with HDDs? - yes I know try it out yourself!

I also need to try out Samsung's Rapid mode since I've got a couple of them.

I find this useful interaction

 

[gldndragn]

I clearly need a rethink on caching. The SSD is essentially a solid state memory device which is slower than your high speed RAM and even SATA 3 speeds can't be met. Can multiple threading be assisting here? (probably a dumb question).
Also, can PrimoCache assist with HDDs? - yes I know try it out yourself!

I also need to try out Samsung's Rapid mode since I've got a couple of them.

I find this useful interaction

According to the devs, It can....as l2 cache. (level 2)
Visit the page and read the FAQs....I believe it says so there.
I have not used that feature.

 

[Britton30]

Yes Michael Primo does work with HDDs as well. Not SSD speeds but much faster as they show in some snips.

 

[garuda]

OK the results are in.... So the actual times for transferring the 24.1GB file are as follows -

Without the cache tool running - 2m 38s
With 4GB of ram allocated - 2m dead
With 12GB of ram allocated - 2m dead

So the extra ram actually serves no purpose in relation to transferring large files. But at any rate with the cache enabled it saved nearly 40 seconds which is quite impressive for the total time we are talking about.

Ordinarily, I try not to get caught up in the SSD-speed fervor, since in the end I agree with “whs” — it’s real world performance that truly matters, not ideal-situation benches. But when the bench numbers exceed 10K on READ or WRITE, I can’t help but become curious as to how they do it — since over 10K exceeds the speed of current RamDrive technology using the fastest memory available. But I’m having difficulty finding any real specifics on how Primo does it, other than their webpage block diagram.

Paul, your first example comparing Primo/no-Primo file xfers was 158secs Xfer. Your 2nd w/Primo was 120secs at 4G RAM. Then again #3 was 120secs at 12G RAM setting. You concluded that RAM size doesn't matter. I’m not so sure I agree with that in the long run over time.

Based on my vague understanding of Primo’s block diagram, and drawing somewhat on my limited RamDisk knowledge — I’m guessing that the reason xfer #2 and #3 were the same length of time, is because Primo likely uses RAM allocated cache to store and retain certain data from previous transactions (and their webpage description seems to suggest this). Therefore perhaps the #2 and #3 were both the same time (120secs) because the #2 xfer was still stored in the RAM cache or the “Fancy Cache” as they call it — so naturally one would expect all subsequent xfers containing the same data or file would be the same time period; because it’s using the same data from the same cached memory.

That’s just my guess. I’m going to try to get more detail on how Primo does it, to see if it’s different from RamDisk techniques. I speculate it’s just a variation of RamDrive technology. And likely the huge bench numbers are the product of simply reading RAM speeds, not from using SSD real estate activity. I’ll post if I come up with anything concrete on how it works.

I hope you guys appreciate my additional research on Primo, because it’s really cutting into my “old geezer” 4-hour mid-afternoon nap time! lol

 

[gldndragn]

OK the results are in.... So the actual times for transferring the 24.1GB file are as follows -

Without the cache tool running - 2m 38s
With 4GB of ram allocated - 2m dead
With 12GB of ram allocated - 2m dead

So the extra ram actually serves no purpose in relation to transferring large files. But at any rate with the cache enabled it saved nearly 40 seconds which is quite impressive for the total time we are talking about.

Ordinarily, I try not to get caught up in the SSD-speed fervor, since in the end I agree with “whs” — it’s real world performance that truly matters, not ideal-situation benches. But when the bench numbers exceed 10K on READ or WRITE, I can’t help but become curious as to how they do it — since over 10K exceeds the speed of current RamDrive technology using the fastest memory available. But I’m having difficulty finding any real specifics on how Primo does it, other than their webpage block diagram.

Paul, your first example comparing Primo/no-Primo file xfers was 158secs Xfer. Your 2nd w/Primo was 120secs at 4G RAM. Then again #3 was 120secs at 12G RAM setting. You concluded that RAM size doesn't matter. I’m not so sure I agree with that in the long run over time.

Based on my vague understanding of Primo’s block diagram, and drawing somewhat on my limited RamDisk knowledge — I’m guessing that the reason xfer #2 and #3 were the same length of time, is because Primo likely uses RAM allocated cache to store and retain certain data from previous transactions (and their webpage description seems to suggest this). Therefore perhaps the #2 and #3 were both the same time (120secs) because the #2 xfer was still stored in the RAM cache or the “Fancy Cache” as they call it — so naturally one would expect all subsequent xfers containing the same data or file would be the same time period; because it’s using the same data from the same cached memory.

That’s just my guess. I’m going to try to get more detail on how Primo does it, to see if it’s different from RamDisk techniques. I speculate it’s just a variation of RamDrive technology. And likely the huge bench numbers are the product of simply reading RAM speeds, not from using SSD real estate activity. I’ll post if I come up with anything concrete on how it works.

I hope you guys appreciate my additional research on Primo, because it’s really cutting into my “old geezer” 4-hour mid-afternoon nap time! lol

Seems like a good idea to me. I would like to know more myself on this.
Please post back with your results/findings. Thanks

 

[paulpicks21]

OK the results are in.... So the actual times for transferring the 24.1GB file are as follows -

Without the cache tool running - 2m 38s
With 4GB of ram allocated - 2m dead
With 12GB of ram allocated - 2m dead

So the extra ram actually serves no purpose in relation to transferring large files. But at any rate with the cache enabled it saved nearly 40 seconds which is quite impressive for the total time we are talking about.

Ordinarily, I try not to get caught up in the SSD-speed fervor, since in the end I agree with “whs” — it’s real world performance that truly matters, not ideal-situation benches. But when the bench numbers exceed 10K on READ or WRITE, I can’t help but become curious as to how they do it — since over 10K exceeds the speed of current RamDrive technology using the fastest memory available. But I’m having difficulty finding any real specifics on how Primo does it, other than their webpage block diagram.

Paul, your first example comparing Primo/no-Primo file xfers was 158secs Xfer. Your 2nd w/Primo was 120secs at 4G RAM. Then again #3 was 120secs at 12G RAM setting. You concluded that RAM size doesn't matter. I’m not so sure I agree with that in the long run over time.

Based on my vague understanding of Primo’s block diagram, and drawing somewhat on my limited RamDisk knowledge — I’m guessing that the reason xfer #2 and #3 were the same length of time, is because Primo likely uses RAM allocated cache to store and retain certain data from previous transactions (and their webpage description seems to suggest this). Therefore perhaps the #2 and #3 were both the same time (120secs) because the #2 xfer was still stored in the RAM cache or the “Fancy Cache” as they call it — so naturally one would expect all subsequent xfers containing the same data or file would be the same time period; because it’s using the same data from the same cached memory.

That’s just my guess. I’m going to try to get more detail on how Primo does it, to see if it’s different from RamDisk techniques. I speculate it’s just a variation of RamDrive technology. And likely the huge bench numbers are the product of simply reading RAM speeds, not from using SSD real estate activity. I’ll post if I come up with anything concrete on how it works.

I hope you guys appreciate my additional research on Primo, because it’s really cutting into my “old geezer” 4-hour mid-afternoon nap time! lol

Hello garuda,

It is certainly interesting testing things out like this, and I will also be interested to hear your findings.

Now regarding what I have highlighted in red, If this is indeed true then I should be able to test it by simply ending the current Cache process, restarting the PC and then creating a new Cache process with 12GB of ram used. Am I correct in thinking that will delete any previously stored data?

I am going to test this out now anyway to see if it makes any difference.

Paul.

 

[paulpicks21]

The time was 1m 59.3s so essentially the same time as the 2 previous runs.