Mailing List Archive: RAMDISK

RAMDISK

Nov 1, 2002, 8:15 AM

Post #1 of 4 (1608 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Did some quick calculations; 30 seconds of buffering at 3300Kbps
would require 12-13 megabytes of DRAM. Do we know if the linux
buffer cache architecture is smart enough to handle this case without
requiring a re-read from disk? I won't have access to my linux box
until this weekend, so I can't test it out on my own. Any thoughts
on whether having a ringbuffer in DRAM on a RAM disk would help, with
a worker thread writing from the in-memory buffer to disk rather than
reading and writing directly to disk? It might help smooth out some
hard drive issues, where concurrent access on slower hard drives
might cause hiccups.

Just a thought.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPcKMmvc1NpCTlP0JEQJnZQCg8kXRz7J19F7pGvdcy7WA0fR9u80AoNtK
0qA46oqMb0iX9wfY6SSMbnPq
=9HDw
-----END PGP SIGNATURE-----

Re: RAMDISK [ In reply to ]

ijr at po

Nov 1, 2002, 3:33 PM

Post #2 of 4 (1555 views)

Permalink

On Friday 01 November 2002 10:15 am, Robert Kulagowski wrote:
> Did some quick calculations; 30 seconds of buffering at 3300Kbps
> would require 12-13 megabytes of DRAM. Do we know if the linux
> buffer cache architecture is smart enough to handle this case without
> requiring a re-read from disk? I won't have access to my linux box
> until this weekend, so I can't test it out on my own. Any thoughts
> on whether having a ringbuffer in DRAM on a RAM disk would help, with
> a worker thread writing from the in-memory buffer to disk rather than
> reading and writing directly to disk? It might help smooth out some
> hard drive issues, where concurrent access on slower hard drives
> might cause hiccups.

Too complicated to do properly -- and once the reader gets more than 30
seconds away from the writer, you're back to the same amount of disk activity
as before.

Isaac

RE: RAMDISK [ In reply to ]

rkulagowski at thrupoint

Nov 4, 2002, 8:51 AM

Post #3 of 4 (1572 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Did some quick calculations; 30 seconds of buffering at 3300Kbps
> > would require 12-13 megabytes of DRAM.
> Too complicated to do properly

Right, I was just thinking that something like the RAMDISK would help
smooth out any jitters related to I/O starvation through the hard
drive. You're right that if the reader and writer got too far out of
sync you'd get stuck in the continuous reading from hard drive case.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPcaJVPc1NpCTlP0JEQKo2wCcCiAU5kf1X19WlPFh7tEm1uazAx4AnA3n
hGZK5rnsqPZqSNHHM++Fba+X
=fg1G
-----END PGP SIGNATURE-----

Re: RAMDISK [ In reply to ]

mdz at debian

Nov 4, 2002, 10:47 AM

Post #4 of 4 (1569 views)

Permalink

On Mon, Nov 04, 2002 at 09:51:00AM -0600, Robert Kulagowski wrote:

>
> > > Did some quick calculations; 30 seconds of buffering at 3300Kbps
> > > would require 12-13 megabytes of DRAM.
> > Too complicated to do properly
>
> Right, I was just thinking that something like the RAMDISK would help
> smooth out any jitters related to I/O starvation through the hard
> drive. You're right that if the reader and writer got too far out of
> sync you'd get stuck in the continuous reading from hard drive case.

You're better off letting the kernel manage the buffer cache in this case, I
think, rather than forcing it to dedicate a lot of memory to this.

--
- mdz