Conclusion
Yup. It's faster.
Helps with long smps simulation.
Please cite how much "faster".
Total simulation time for each, with and without the Ramdisk?
...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
By what percentage improvement on a given problem?
How does it compare with using SSD with/without RAID?
Regards,
Martin Brown
>On Sun, 17 Jan 2010 13:09:28 -0800, D from BC
><myreal...@comic.com> wrote:
>
>>I'm tried out a trial version of 'Ramdisk' and set aside 4G of memory
>>(I have 8G) to be used as a ramdrive for the raw file created during
>>an LTSPICE simulation..
>>
>>Conclusion
>>Yup. It's faster.
>>Helps with long smps simulation.
>
>Please cite how much "faster".
>
>Total simulation time for each, with and without the Ramdisk?
>
> ...Jim Thompson
Darn.. I was hoping to dodge the burden of proof which takes time.
It's my observation that ltspice seems faster when the raw file is on
a ramdrive.
Theoretically there should be an improvement in ltspice simulation if
there is a large .raw file say ~2GB and one needs to see many test
points in an smps.
Generally ram transactions are faster than SSD or harddisk.
Maybe try out the trial.
http://www.superspeed.com/desktop/ramdisk.php
It seems like a 30% to 50% speed improvement in drawing graphs when
picking different test points in an smps.
But....it still could be bogus like noticing a driving improvement
after filling up with top octane gas.
Unfortunately, I can't back up my claim without creating a research
project within my research project.
While I fully understand the benefit of using a RAM disk on a 32 bit
platform (e.g. 386+) with a large physical RAM running some 16 bit
operating system (MS-DOS/Win 3.x), I do not understand why anybody
would want to run some kind of RAM disk on a 32 bit virtual memory OS
(except CDROM/Flash booted systems).
On a virtual memory operating system, the page fault mechanism has
much less overhead than the traditional file I/O.
Exactly for this reason large (hundreds of GB) disk based data bases
are handled in 32/64 bit virtual memory operating systems as memory
mapped files, actually treating the small (1-64 GiB) RAM just as a
large L3 cache.
If some RAM disk implementation is actually going to give some
improvement, much more improvement could be gained by persuading the
software vendor to understand, how virtual memory is effectively used.
You have 8 G of RAM? What OS? What mainboard? How did you do that?
Michael
You can get 24G with Win7 64 and an I7 1366 (6 SIMM sockets for triple
channel), but the 4G DDR3 PC3 12800 sticks are still extremely
expensive (down from obscenely expensive a few months ago-- about
$1600 US retail for 24G right now (Mushkin).
afaik LTSPICE does not attempt to fill memory and then spill over to
virtual memory.
afaik LTSPICE directly dumps it's data onto disk.
I've watched the ltpsice .raw file grow in size as a simulation runs.
Ltspice doesn't first fill physical memory and then switches to
virtual memory. Seems to me Ltspice dumps straight to physical disk
disregarding whatever system memory exists..
win 7
gigabyte ga-ma770t-ud3p
Supports 16G mem
Freaky huh?
I dished out a bit more coin just to test out ramdisk apps with
ltspice.
Whenever I click on a new test point, the graphing seems faster as
ltspice is accessing the .raw file from memory and not from a spinning
drive.
Appending..
Win7 64
I've found that using a ram drive makes a huge difference when probing
around a circuit that has finished the simulation run.
Especially when probing points that have not been loaded before.
Probing around a SMPS circuit that has created a 500MB
RAW file takes my machine(admitedly not a very fast one) about 15-25s
per trace.
From a ram disk it takes less that 3s.
just my 2c