On 4 Sep 2001, Bill Davidsen wrote:

> [EMAIL PROTECTED] wrote:
> 
> > >cdrecord, while burning, seems to suffer from the same "hard 
> > >drive slowness".  On certain times at certain tracks (not 
> > >consistent), the FIFO percent decreases until it sometimes 
> > >reaches ~5%, but the CD burning process continues without fail. 
> > >Both CDRWs are SCSI.
> > 
> > >Has anyone experienced this?
> > 
> > >SuSE 7.2 User
> > >System Specs
> > >233 Pentium MMX
> > >32MB of RAM
> > >Plextor 12/10/32S
> > >Yamaha 8424SZ
> > >Advansys Ultra SCSI card
> > 
> > WIth a SCSI system this must be caused by one or more devices that 
> > don't do disconnect/reconnect
> 
>   Well, certainly which are not functioning properly, as one possible
> solution. I have a few thoughs on avoiding this, however, or helping to
> identify the problem.
> 
>   First, by current standards the system memory is "modest," a polite
> way of saying "barely adequate." Depending on what else is running in
> the system there may be an issue there. I have run happily on 48MB,
> though, so that's just a thought. Increasing the FIFO might help, but
> Joerg didn't suggest that, so I just mention that since you can try
> without touching hardware.

Thank you for not being blunt. :)  I have considered getting 
more RAM, but it's not worth it.  Windows 95 (my primary OS), 
runs excellent on 32MB (on bootup, 22MB are free) once it is 
optimized.  Linux, w/o the GUI stuff of course, plays very 
nicely on just 32MB of RAM.  Please note that my Linux 
installation is also "optimized": not even atd runs.  My RAM 
used to go for $85 for 32MB of RAM.  As I plan on getting a 
completely new computer within the next few months, that's an 
outrageous price to pay, as I can now get 256MB of RAM for the 
same price.

UPDATE:
Using cdparanoia to rip the contents of the CD does _not_ produe 
the "slow hard drive" problem.  It runs perfectly in both 2.4.4 
and 2.4.9.  cdda2wav / cdrecord do _not_ suffer from the problem 
in 2.4.4, just 2.4.9.  It seems the culprit is either 2.4.9 or 
cdrtools, or both.  Although I'm no expert, it could be the way 
cdda2wav and cdrecord access data since cdparanoia is not 
affected.

UPDATE_2:
Once I disabled DMA (I removed chipset support from kernel 
config), the cdrecord "freeze" problem also has disappeared.  I 
will do much more extensive tests in the next few days.

>   If that controller has a 2nd bus, such as plain SCSI-2, you might move
> one device to that and see if it improves the situation. If you have
> another controller you can plug in that's not a bad idea to try.

Taking into account the new UPDATEs, should I still try this?

>   Finally, I assume that the kernel has extended error reporting on in
> the SCSI code, and that you did look at the logs carefully. Pretty grim
> to find out that you have a termination problem after you do a lot of
> other work. The slowness on certain tracks suggests either data
> dependency or inconsistent hardware. I assume you checked the cables,
> physical stuff is more likely to "work sometimes" than software or
> controllers.
>
>   Did you try a slower burning speed? Not as a solution but as an
> information point?

Yes, I used my Yamaha drive (8x max write) to burn an audio CD: 
it suffered the same "slow" fate.  I also used my Yamaha to 
_rip_ an audio CD on 2.4.9 using cdda2wav.  Just as in my 
Plextor, the hard drive was "slow".
--
noodlez:   Karol Pietrzak
PGP KeyID: 0x3A1446A0


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to