" G'day again,
I've just done some testing with RAM disks and have noticed that the maximum transfer rate I can get is only 8.7Mb/sec.

Now to me, that sounds rather dismall considering I'm not accessing any drives. I'm conducting the test by copying a 25Mb file from the RAM Disk to a folder on the RAM Disk ( by holding down the option key). I'm getting the value of 8.7Mb/sec from Speed Doubler's interface window.(verifying is off)

The test was conducted on a 7600(604e@180MHz) equipped with 208Mb of RAM. "

He's asking for others to run tests and report their transfer rates.

Most interesting below is that it seems a 4 drive Raid array is faster than Apple's Ramdisk.

Reader Feedback:

" The Apple RAM disk has always been slow. We reported the problem to Apple back in August of '95, when we discovered that a Quadra 950 was running much slower (performing Saves and Save As...) with Photoshop and a RAM disk, then it was with it's RAID 0 setup, as follows:

Apple RAM Disk Test, 8/4/95 Q950 w/ATTO RAID.

Volume: RAM Disk . . . . . . . . . . . . . . . . . Size: 5036K
test size = 1512K
(using a temporary contiguous file of size 1512K)

Pass 1:
Latency = 0.54 ms
Write transfer rate = 4222 KBytes/Sec.
Read transfer rate = 13271 KBytes/Sec.
Simulated "Typical" rate = 2311 KBytes/Sec.
While RAM disk speed has improved, it still has a problem with the write transfer rates, even on newer systems, such as:

Apple RAM Disk OS 7.6.1, 7/5/98 7500/233.
----------------------------
Volume: RAM Disk . . . . . . . . . . . . . . . . . Size: 4532K
test size = 512K
(using a temporary contiguous file of size 512K)

Pass 1:
Latency = 0.09 ms
Ave. Seek = 0.00 ms, (access = 0.09 ms)
Max. Seek = 0.00 ms, (access = 0.09 ms)
Write transfer rate = 10485 KBytes/Sec.
Read transfer rate = 31457 KBytes/Sec.
Simulated "Typical" rate = 10598 KBytes/Sec.

----------------------------
Volume: RAM Disk . . . . . . . . . . . . . . . . . Size: 4532K
test size = 1512K
(using a temporary contiguous file of size 1512K)

Pass 1:
Latency = 0.09 ms
Ave. Seek = 0.00 ms, (access = 0.09 ms)
Max. Seek = 0.00 ms, (access = 0.09 ms)
Write transfer rate = 15482 KBytes/Sec.
Read transfer rate = 30965 KBytes/Sec.
Simulated "Typical" rate = 9600 KBytes/Sec.

----------------------------
Volume: RAM Disk . . . . . . . . . . . . . . . . . Size: 4532K
test size = 2512K
(using a temporary contiguous file of size 2512K)

Pass 1:
Latency = 0.11 ms
Ave. Seek = 0.00 ms, (access = 0.11 ms)
Max. Seek = 0.00 ms, (access = 0.11 ms)
Write transfer rate = 15433 KBytes/Sec.
Read transfer rate = 30867 KBytes/Sec.
Simulated "Typical" rate = 9953 KBytes/Sec.

----------------------------
Volume: RAM Disk . . . . . . . . . . . . . . . . . Size: 4532K
test size = 3512K
(using a temporary contiguous file of size 3512K)

Pass 1:
Latency = 0.11 ms
Ave. Seek = 0.00 ms, (access = 0.11 ms)
Max. Seek = 0.00 ms, (access = 0.11 ms)
Write transfer rate = 16598 KBytes/Sec.
Read transfer rate = 35962 KBytes/Sec.
Simulated "Typical" rate = 9600 KBytes/Sec.

This slow write transfer rate drives our graphic design clients mad, when dealing with large color scans and saving various adjustments as they work with them in Photoshop, trying to use a RAM disk to speed-up the process.

Even a modest (5400 RPM UltraSCSI) RAID 0 system will still outperform the RAM disk in terms of the sustained write rates, as shown here:

4-Drive RAID 0, Seagate Hawks, ATTO DC, 7500/233 OS 7.6.1

Volume: PR4 RAID . . . . . . . . . . . . . . . Size: 2095112K
test size = 1512K
(using a temporary contiguous file of size 1512K)

Pass 1:
Latency = 5.50 ms (5454 RPM)
Ave. Seek = 7.08 ms, (access = 12.58 ms)
Max. Seek = 9.83 ms, (access = 15.33 ms)
Write transfer rate = 30965 KBytes/Sec.
Read transfer rate = 30965 KBytes/Sec.
Simulated "Typical" rate = 1909 KBytes/Sec.

As you know from our earlier E-Mail's, we prefer Roger Bates' Time Drive, which, incidently, was originally written to test RAM Disks, as he worked to refine his own RAM Disk software.

Because the random access and read speed is so high for a RAM disk, we think it is best used for caching browser data. Other than this, we haven't found much use for it, other than temporary storage.

Hope this input is helpful.
-Rod
---------------------------------------------------------
ASTEC Company, Inc. Purcellville, Virginia, USA
Consulting, Systems Integration and Systems Management
Services for Apple Macintosh Business Users, since 1988. "

" Hi,
I tested my RAM disk performance with HDT 2.5, got 32MB/sec read and write as an average.

The Speed Doubler does not show accurate numbers, so I would not recommend it for any comparisons.

System is a 9500/G3 350/234/45 Mhz with 304 MB RAM, OS 8.1 US with many extensions.
Tobias Jachmann "

" I may run some tests myself, (as I am considering boosting my PowerCenter 150's current RAM from 160MB to 256MB) but when I have played with ramBunctious 1.3 (and a 60MB RAM disk), I have seen gotten read/write benchmarks over 27MB/sec according to FWB HDTK.
Yours,
David Minton "

" HI Mike
I tested copying from my hardisc to my ram disc. I copied a 38mb file. Using Speed doubler it says I get a max transfer rate of 1 mb a sec.

However, the 38 mb transfer is executed in around a second, maybe a bit less.

This would be in line with the data transfer rates of the RAID, 25mb a sec, with 85mb bursts around 2 seconds. The above tests run with ATTO disc test program.

PS: This is a 266/G3, 384mb ram, twin cheetah, twin 2940 RAID.

I notice that the data write to the ram disc in IE 4.0.1 is a noticeable improvement over using the hardisc location for the cache. Thanks again for a wonderful site.
Greg Santilli "

" I ran the same tests in a 7600 G3 325/325 with 208 megs the transfert rate was 12.7 Megs/sec.
you have the best site Mike
syncope "

" Hi Mike,
You probably don't remember me, but I last wrote to you concerning what I thought of my 8600/250. Anyway, I decided to do a few tests in ramBunctious 1.3. My system is an 8600/250 (Mach 5) with 160 MB RAM running a rather basic set of extensions in OS 8.1 (no LibMoto, no SpeedDoubler, VM off, disk cache set to 96kB).

Anyway, to get to the point right away, speeds MUCH faster than ~9 MB/s can be achieved. I don't have a very good way of estimating the copy speed (not enough RAM or large enough files to make transfer times of more than a second or two, hard to measure), but as you will see below, I think 50 MB/s is a reasonable ballpark figure for the transfer rate of a RAM disk.

I made a 90 MB RAM disk and copied a roughly 20 MB file to it. (Don't have any bigger files sitting around.) Not counting a slight hesitation by the Finder (about a second), copying from disk took a few seconds (6?); a bit slow, but reasonable. Duplicating (by pressing command-d) took under a second. Copying to another folder (by holding down the option key) took under a second. Both times ignore the slight hesitation by the Finder.

So I explored the slight hesitation. I took two files that are roughly 20 MB long and copied both of them to the RAM disk. The hesitation when duplicating them on the RAM disk grew slightly (but certainly wasn't twice as long), but the time spent actually copying was well under two seconds.

I don't think the hesitation should be taken into account when measuring the maximum transfer rate of a drive. The OS has some inefficiencies, and it must determine what it is supposed to do when you choose the duplicate command. Then, it must make a list of the files to be duplicated and >verify that there is enough free space. Copying large folders on any disk, one finds that the hesitation gets larger and larger as the number of files grows, but no files are actually duplicated until _after_ this hesitation. My test results are consistent with that, except the hesitation seemed unusually long for such a small number of files. My guess is that the overhead caused by having ramBunctious control the disk rather than having the OS control it directly caused the extra hesitation.

So what is the maximum transfer rate? Well, I duplicated at about 25-30 MB/s. But that's reading and writing. So the maximum transfer rate should be around 50-60 MB/s. Possibly more if you allow a sustained transfer, but that's kind of hard to do unless you have a REALLY big RAM disk. I believe this rate will improve in OS 8.5 as rumor has it disk performance improves greatly. Perhaps ramBunctious is significantly faster than the OS's RAM disk. I doubt it, but it's possible. The other possibility is that somehow, having a VERY small disk cache improved my transfer rate. This is quite possible. After all, if you have a large cache, there is more I/O going on. A cache is useful if your medium can't keep up, but the RAM disk certainly can keep up. A cache only sidetracks the data. I wish we could somehow disable caching for RAM disks. (I don't remember where, but I saw a study of cache sizes and sustained transfer rates on the web somewhere... optimal in that study was something like 256 kB).

Caching for hard drives is a more iffy issue since unless you have a fast RAID system, the hard drive can't always keep up. I don't believe there's much an advantage. I did a test on a Performa 6300CD (100 MHz 603e, 1.2 GB IDE disk--SLOW, 16 MB RAM, OS 7.5.5, SpeedDoubler 1, RAMDoubler 1) at home about 1.5 years back. With about 3500 files on the hard drive, I asked FindFile to find every file. With 1024 kB disk cache, the time to find all the files and sort them was some amount of time something like 3 minutes. With 2048 kB disk cache, the time improved a mere 2 seconds. It was reproducible. And this was with a slow hard drive. With a faster hard drive, the results would be smaller, or even reversed. So it seems to suggest that a large disk cache is generally not worthwhile. The only exception I could see is if you generally work with files in the 1-5 MB range. Then if you can make large enough a disk cache, the file can be written instantly to the disk cache and then transferred to the hard drive at a more leisurely pace. If your files are larger, transferring to the disk cache is just excess I/O and doesn't really save time since everything must eventually be written to disk anyway.

Sorry to rant on so long, but hope some of this helps.
Regards,
Jason Chen"