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 15:03:01 -0500 [thread overview]
Message-ID: <3C3715A5.13473.4360DD@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
next reply other threads:[~2002-01-05 21:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-05 20:03 Karol Pietrzak [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-01-05 19:01 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=3C3715A5.13473.4360DD@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.