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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:29 EST