From owner-freebsd-hackers Sun Oct 29 20:35:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA00705 for hackers-outgoing; Sun, 29 Oct 1995 20:35:20 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA00695 for ; Sun, 29 Oct 1995 20:35:17 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id UAA09703; Sun, 29 Oct 1995 20:35:02 -0800 From: Julian Elischer Message-Id: <199510300435.UAA09703@ref.tfs.com> Subject: Re: Buffer cache , lmbench part 3 To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Sun, 29 Oct 1995 20:35:01 -0800 (PST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510300409.UAA10427@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 29, 95 08:09:22 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1079 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk How do you know it's buffer_cache? you could put the 'sync' (update) frequency to 1 sysctl -w kern.update=1 (I think) and try again.. (I presume he has it on tape....) you don't want to go synchronous but you don't want to be so asynchronous that the ram fills up and you end up waiting on disk.. try this.... > > > Jim Lowe recorded the last space shuttle launch on his FreeBSD box;however, > he ran into a minor gotcha the buffer cache. If you want to see the > buffer cache in action just play the mpeg movie and look for pauses on > on the movie. So the question now is: Is the buffer cache tuneble to > avoid this kind of behavior? > > I was thinking that video capture without compression eats up enourmous > amount of disk space so it would not be too unconceivable to bypass the > file system and buffer cache and just do raw I/O to the disk. > > Here is a pointer to Jim's mpeg version of the space shuttle launch it > is about 1.7mb and the original was 300MB : > > ftp://ftp.cs.uwm.edu/pub/shuttle_gifs/sts73.launch.mpg. > > Enjoy, > Amancio > > >