public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Karol Pietrzak" <noodlez84@earthlink.net>
To: linux-kernel@vger.kernel.org
Subject: Re: slow CD ripping from moving from 2.4.4 to 2.4.17
Date: Sat, 5 Jan 2002 14:01:56 -0500	[thread overview]
Message-ID: <3C370754.15459.B7184@localhost> (raw)

Hello.
I am the original poster, and I am happy to say that my problem 
has been solved thanks to Mark Hahn.  The solution was to tweak 
the VM (via /proc/sys/vm/bdflush).

Here's the excerpt from fs/buffer.c which I looked at:

union bdflush_param {
	struct {
		int nfract;	/* Percentage of buffer cache dirty to 
				   activate bdflush */
		int dummy1;	/* old "ndirty" */
		int dummy2;	/* old "nrefill" */
		int dummy3;	/* unused */
		int interval;	/* jiffies delay between kupdate flushes */
		int age_buffer;	/* Time for normal buffer to age before we 
flush it */
		int nfract_sync;/* Percentage of buffer cache dirty to 
				   activate bdflush synchronously */
		int dummy4;	/* unused */
		int dummy5;	/* unused */
	} b_un;
	unsigned int data[N_PARAM];
} bdf_prm = {{40, 0, 0, 0, 5*HZ, 30*HZ, 60, 0, 0}};

After a little tinkering, this is now in my 
/etc/init.d./boot.local :
echo "10 0 0 0 500 3000 5 0 0" > /proc/sys/vm/bdflush 

Thus, the only modified numbers are:
1. nfract : from 40% to 10% (Percentage of buffer cache dirty to 

activate bdflush)
2. nfract_sync : from 60% to 5% (Percentage of buffer cache 
dirty to activate bdflush synchronously)

I don't quite understand what all that means (my knowledge of C 
is very limited), but it works :)

Once again, thank you.  You've made me a happy Linux user...  
Ripping performance, with these changes in place, is now around 
26-30X, where before, it was 13-15X.

On 31 Dec 2001, linux-kernel@vger.kernel.org wrote:

> Hello.
> Using 2.4.4 up to, I believe, 2.4.14, CD ripping was fine.  My
> Plextor 12/10/32S (S for SCSI) ripped audio CDs at around 25X,
> even sometimes at 30X.  While ripping, my hard drive would work
> continuously, and so would my CDRW drive.
> 
> Now with 2.4.17, my hard drive can't keep up with my CDRW drive:
> everything happens in bursts.  My CDRW drive starts ripping as
> fast as possible, but my hard drive doesn't do anything (0-5
> seconds).  Then, my hard drive decides to start writing, which
> stops the CD ripping process (5-8 seconds).  Now that the hard
> drive is done, the CDRW drive continues ripping... for 4 seconds
> and the process continues over and over again.  This brings down
> the ripping speed down to ~18X, a far cry from the 30X achieved
> with 2.4.4 and very close to the writing speed of my CDRW drive
> (12X), which is ridiculous.
> 
> As stated before, ripping is fine in 2.4.4 (which I still keep
> around because of this problem).  What does help in 2.4.17,
> however, is manually entering running the 'sync' command ever
> second or so on another console.  This makes the ripping process
> a lot more "continuous," like 2.4.4.
> 
> I can't burn CDs in 2.4.4, however, because that freezes up my
> computer, for some reason.  That happens a lot less often in
> 2.4.17 (but that's another matter).
> 
> I am using SuSE 7.2 Pro with the latest cdda2wav (1.11a12).
> 
> Linux linux 2.4.17 #2 Fri Dec 21 17:14:19 EST 2001 i586 unknown
> 
> Gnu C                  2.95.3
> Gnu make               3.79.1
> binutils               2.10.91.0.4
> util-linux             2.11b
> mount                  2.11b
> modutils               2.4.5
> e2fsprogs              1.19
> reiserfsprogs          3.x.0k-pre15
> PPP                    2.4.0
> Linux C Library        x    1 root     root      1343073 May 11 
> 2001 /lib/libc.so.6 Dynamic linker (ldd)   2.2.2 Procps          
>       2.0.7 Net-tools              1.60 Kbd                   
> 1.04 Sh-utils               2.0 Modules Loaded         ppp_async
> ppp_generic slhc nls_cp437 vfat fat
> 
> I am using a Pentium I 233 with 32MB of RAM.  I have an Advansys
> Ultra SCSI card with 3 devices total hooked up to it.
> 
> Anyone have any ideas?  Anything I can do?

--
Karol Pietrzak
PGP KeyID: 3A1446A0

             reply	other threads:[~2002-01-05 18:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-05 19:01 Karol Pietrzak [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-05 20:03 slow CD ripping from moving from 2.4.4 to 2.4.17 Karol Pietrzak
2001-12-31 18:42 Karol Pietrzak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C370754.15459.B7184@localhost \
    --to=noodlez84@earthlink.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox