Re: growisofs will not write at 8x with NEC 3540A
Matthias Andree <matthias.andree@gmx.de> wrote:
> > As cdrecord meters the max DMA speed before accepting a write speed,
> > it seems to be unlikely that there are many buffer underruns.
>
> cdrecord cannot predict the future system load, if the DMA check runs
Cdrecord runs at highest realtime priority. If you use an OS that does not
honor this setting, you should change your OS.
> while the computer is idle, and it gets under I/O load while writing,
> all bets are off. Plus, I/O load is much nastier than regular CPU load,
> as it causes processes to go into D state, deep, uninterruptible,
> in-kernel sleep. Real-Time scheduling on non-Real-Time OS doesn't help
> with that.
A Real Time OS of course helps.....
A decent OS limits single I/O chunks to a nonproblematic value (typical 126 kB).
As cdrecord needs 2 I/O operations per media transfer, a working scheduler
would not allow more than one additinal transfer from a lower priorized command
except when there is plenty of idle time.
Cdrecord requires the system to be able to perform 1.2x the DMA speed.
In the worst case and a correct HW setup, cdrecord would need to require
a factor of 1.33x as reserve.
You may change this behavior here in cdrecord.c:
if (tracks > 0 && (flags & F_WRITE) != 0 && dma_speed > 0) {
int max_dma = (flags & F_FORCE) != 0 ? dma_speed:(dma_speed+1)*4/5;
In case that the writer is at the same cable as the HDD where the data is read,
cdrecord would need a I/O bandwidth at the cable that is 3x the max. write
speed. But this is a setup that does now work at all unless you use
cdrecord -immed
> I've seen buffer underruns on a really fast machine (Athlon XP 2500+, 1
> GB RAM, DMA speed around 28 MB/s) when a couple of mail virus scanners
> descended on incoming messages and started reading their virus
> definition files.
>
> cdrecord was running as root, i. e. with RT priority, mlocked pages and
> everything. OK, it was Linux, not FreeBSD or Solaris...
So you found a new reason to switch to Solaris ;-)
> In this context: what's the difference between "10 predicted buffer
> underruns" and "burnproof was 1x used"?
A precited BU happens when the cdrecord FIFO fill ratio goes under 5%
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: