# cdrecord buffer underrun.. ack! [solved]

## Jerri

I have been having some difficulty burning cd-r's with cdrecorder (cdrtools 2.01alpha14/19).  Everytime I try to pipe mkisofs to cdrecord, the buffer runs empty and fails.

Output: (mkisofs -quiet file | cdrecord -v -dummy -data  dev=0,0,0 speed=12  gracetime=3 -)

```

write track data: error after 108945408 bytes

cdrecord: The current problem looks like a buffer underrun.

cdrecord: Try to use 'driveropts=burnfree'.

cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.

Writing  time:   64.966s

Min drive buffer fill was 8%

Fixating...

WARNING: Some drives don't like fixation in dummy mode.

Fixating time:    0.006s

Track 01:  269 MB written (fifo   3%) [buf  11%]   7.6x.cdrecord: Input/output error. write_g1: scsi sendcmd: no error

CDB:  2A 00 00 02 1A FD 00 00 1F 00

status: 0x2 (CHECK CONDITION)

Sense Bytes: F0 00 03 00 02 1A FD 12 00 00 00 00 0C 09 00 00

Sense Key: 0x3 Medium Error, Segment 0

Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0

Sense flags: Blk 137981 (valid)

cmd finished after 0.004s timeout 40s

```

This happens even if run as root.  K3b also fails with same error.  I'm under the impression it has everything to do with mkisofs.  If i creat an image of the file I want to burn.. then burn it, cdrecord works like a champion (~3% cpu).  What I have noticed, when I run mkisofs, cpu utilization remains at 1-3%, but the system feels like it slow down dramatically.  It also takes a hella long time to finish (not too mention, it lags during the middle and estimate finish goes up by 5 mins). 

I have found a bunch of post that address this issue..  one dude pointed out that there are two instances of cdrecord, which is the case for me too.

```

jer       3360  0.3  1.1  5808 5808 pty/s0   SL   00:38   0:00 cdrecord -v -eject -dummy dev=0,0,0 speed=12 gr

jer       3361  0.0  1.1  5808 5808 pty/s0   S    00:38   0:00 cdrecord -v -eject -dummy dev=0,0,0 speed=12 gr

```

Jorg mentioned that what is causing the problem is another program trying to access the device.. could it be the second instance of cdrecord?  I tried killing the second one, and the first eventually fails.  Every other option mentioned in the posts has had no effect.

relevent posts:

https://forums.gentoo.org/viewtopic.php?t=50748

https://forums.gentoo.org/viewtopic.php?t=94548

Any help would be rad.

JerLast edited by Jerri on Wed Dec 31, 2003 10:49 pm; edited 3 times in total

----------

## Jerri

My original observations led me to beleive it was mkisofs at fault.  Now I can no longer burn anything successfully.  

I have tried with scsi emulation and ATAPI.

Here is the output:

```

[jer][~/files/movies]: cdrecord -v -data -dummy dev=0,1,0 speed=12 gracetime=3 image.iso

Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling

TOC Type: 1 = CD-ROM

scsidev: '0,1,0'

scsibus: 0 target: 1 lun: 0

Linux sg driver version: 3.1.25

Using libscg version 'schily-0.7'

SCSI buffer size: 64512

atapi: 1

Device type    : Removable CD-ROM

Version        : 0

Response Format: 1

Vendor_info    : 'SONY    '

Identifikation : 'CD-RW  CRX160E  '

Revision       : '1.0e'

Device seems to be: Generic mmc CD-RW.

Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).

Driver flags   : MMC-2 SWABAUDIO

Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R

Drive buf size : 4183552 = 4085 KB

FIFO size      : 4194304 = 4096 KB

Track 01: data   693 MB       

Total size:      796 MB (78:55.98) = 355199 sectors

Lout start:      797 MB (78:57/74) = 355199 sectors

Current Secsize: 2048

ATIP info from disk:

  Indicated writing power: 4

  Is not unrestricted

  Is not erasable

  Disk sub type: Medium Type A, low Beta category (A-) (2)

  ATIP start of lead in:  -12508 (97:15/17)

  ATIP start of lead out: 359845 (79:59/70)

Disk type:    Short strategy type (Phthalocyanine or similar)

Manuf. index: 22

Manufacturer: Ritek Co.

Blocks total: 359845 Blocks current: 359845 Blocks remaining: 4646

cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler

cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().

cdrecord: WARNING: This causes a high risk for buffer underruns.

Starting to write CD/DVD at speed 12 in dummy TAO mode for single session.

Last chance to quit, starting dummy write    0 seconds. Operation starts.

Waiting for reader process to fill input buffer ... input buffer ready.

Starting new track at sector: 0

Track 01:  153 of  693 MB written (fifo   1%) [buf  32%]   6.3x.cdrecord: Input/output error. write_g1: scsi s

endcmd: no error

CDB:  2A 00 00 01 33 D2 00 00 1F 00

status: 0x2 (CHECK CONDITION)

Sense Bytes: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00

Sense Key: 0x3 Medium Error, Segment 0

Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0

Sense flags: Blk 0 (not valid)

cmd finished after 0.008s timeout 40s

write track data: error after 161386496 bytes

cdrecord: The current problem looks like a buffer underrun.

cdrecord: Try to use 'driveropts=burnfree'.

cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.

Writing  time:   93.401s

Average write speed  50.7x.

Min drive buffer fill was 32%

Fixating...

WARNING: Some drives don't like fixation in dummy mode.

Fixating time:    0.007s

cdrecord: fifo had 2606 puts and 2543 gets.

cdrecord: fifo was 52 times empty and 2115 times full, min fill was 0%.

```

Why it ways 50.7x avg transfer speed.. no Idea.

----------

## Jerri

Ok...  To add to the confusion, I can burn a cd that consists of many small files (i.e mp3's) without a problem (so far).  k3b finishes without incident, buffer / fifo remain at consistent 95-100%.  I have real trouble with trying to burn a single large file (i.e divx movie).   

Here is a page I found regarding the same difficulty I'm having, answerd by the man himself:

http://www.mail-archive.com/cdwrite@other.debian.org/msg03924.html

 *Quote:*   

> 
> 
> Kill the unfriendly application that tries to access the drive while cdrecord
> 
> is working.
> ...

 

How? What program? blah!

One more thing, how can I get rid of this:

 *Quote:*   

> 
> 
> cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
> 
> cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
> ...

 

I have tried chmod u+s cdrecord, but that didn't do anything.  Ideas?

----------

## Jerri

Ok, just to give an example of what happens, cdrecord chugs along, until it hits a bump and fifo drops, then the buffer goes then its buffer run all the way! 

debug info from k3b:

```

Track 01:   77 of  693 MB written (fifo  95%) [buf  99%]  13.5x.

Track 01:   78 of  693 MB written (fifo  95%) [buf  99%]  11.9x.

Track 01:   79 of  693 MB written (fifo  98%) [buf  97%]  11.6x.

Track 01:   80 of  693 MB written (fifo 100%) [buf  95%]  11.5x.

Track 01:   81 of  693 MB written (fifo  96%) [buf  97%]  13.6x.

Track 01:   82 of  693 MB written (fifo  98%) [buf  97%]  11.9x.

Track 01:   83 of  693 MB written (fifo 100%) [buf  95%]  11.5x.

Track 01:   84 of  693 MB written (fifo  96%) [buf  98%]  13.7x.

Track 01:   85 of  693 MB written (fifo  95%) [buf  95%]  11.2x.

Track 01:   86 of  693 MB written (fifo  82%) [buf  95%]  11.8x.

Track 01:   87 of  693 MB written (fifo  65%) [buf  97%]  13.9x.

Track 01:   88 of  693 MB written (fifo  54%) [buf  96%]  11.6x.

Track 01:   89 of  693 MB written (fifo  39%) [buf  97%]  13.1x.

Track 01:   90 of  693 MB written (fifo  26%) [buf  97%]  11.8x.

Track 01:   91 of  693 MB written (fifo  12%) [buf  95%]  11.5x.

Track 01:   92 of  693 MB written (fifo   3%) [buf  92%]  10.6x.

Track 01:   93 of  693 MB written (fifo   1%) [buf  72%]   6.8x.

Track 01:   94 of  693 MB written (fifo   3%) [buf  50%]   6.5x.

Track 01:   95 of  693 MB written (fifo   1%) [buf  44%]  10.0x.

Track 01:   96 of  693 MB written (fifo   3%) [buf  24%]   7.0x.

Track 01:   97 of  693 MB written (fifo   1%) [buf  22%]  11.2x.

Track 01:   98 of  693 MB written (fifo   1%) [buf  18%]  11.1x.

Track 01:   99 of  693 MB written (fifo   4%) [buf  12%]  10.0x.

Track 01:  100 of  693 MB written (fifo   4%) [buf  16%]  14.6x.

Track 01:  101 of  693 MB written (fifo   3%) [buf  13%]  11.2x.

Track 01:  102 of  693 MB written (fifo   1%) [buf  14%]  12.8x.

Track 01:  103 of  693 MB written (fifo   1%) [buf   8%]  10.0x.

/usr/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error

CDB:  2A 00 00 00 CF CC 00 00 1F 00

status: 0x2 (CHECK CONDITION)

Sense Bytes: F1 00 03 00 00 CF CF 12 00 00 00 00 0C 09 00 00

Sense Key: 0x3 Medium Error, deferred error, Segment 0

Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0

Sense flags: Blk 53199 (valid) 

cmd finished after 0.003s timeout 200s

/usr/bin/cdrecord: The current problem looks like a buffer underrun.

/usr/bin/cdrecord: Try to use 'driveropts=burnfree'.

/usr/bin/cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.

write track data: error after 108945408 bytes

Writing  time:   81.059s

Average write speed  58.7x.

Min drive buffer fill was 8%

```

----------

## Jerri

I have tried compiling my kernel without scsci support, hoping there might be change.  Unfortunately the exact same thing happens.  I am now compiling without ide-cd support, as I have heard some users claim this was the answer to their problems. I remain skeptical however, as the line: options ide-cd ignore='hdd' (in /etc/modules.d/cdr) should do the same thing.. hmm.

I'm running out of Ideas.   There has to be something I'm missing here.  no way I should be getting buffer underruns..  12x cdwriter on an athlon 2500 w/ 512 Mbytes pc3200 ram.  I know the drive works, as it can burn 100 cd's flawlessly in windows.   grrr!

----------

## Jerri

much to my surprise, removing ide-cd support had no effect, still suffering from same error.

wtf!  :\

----------

## bernieb

 *Quote:*   

> 
> 
> cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
> 
> cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
> ...

 

This occurs when you don't run cdrecord as root.

Try burning as root and see if the problem stops.  It will atleast get rid of

the RR-scheduler error.  I was able to get rid of this at one point by

changing permissions of some files, but I do not recall exactly which files

were required to change to do this.

-Brian

----------

## Jerri

Thanks for the reply, was beginning to worry I was all alone. :\  I realise I have to run cdrecord as root, inorder to prevent the error messages.  I was hoping to be able to run it as a normal user (chmod +s doesn't do the trick).  Running the program as root, however, doesn't have an impact on its performance.  It still runs into the same error.. as seen above.

----------

## mickwd

I may be wrong, but I think what's happening is as follows. The "mkisofs" command is creating the ISO file faster than the "cdrecord" command can write it to the CD. As a result, the output from mkisofs is being buffered by the kernel until cdrecord reads it from the pipe.

As time progresses, this buffering is using up more and more of your RAM, until it's all used up, and the system needs to start paging (i.e. using disk instead of RAM). This is when the system slows down dramatically, and the cdrecord buffer starts to empty.

This would explain why cdrecord seems to work fine if you mkisofs to a file first, then have cdrecord read from the file.

When you mkisofs with many small files, mkisofs has to do a lot of separate reads and seeks on the source drive. This might slow it down enough to prevent all your RAM being chewed up by mkisofs before cdrecord has written much of that data to the CD.

To test whether I'm right, try running the command that fails again, but run "vmstat 1" in another terminal window at the same time. This will show how your memory is being used up, and when the system starts paging / swapping (see "man vmstat" for more details).

----------

## Jerri

Ok, I tried running vmstat 1 while burning, and it appears the amount of free ram during the burn remains consistent..  You can see I started cdrecord about 9 lines down (4 meg buffer).  What I have noticed, if you look at the pattern of blocks in (io -> bi), there is a pretty consistent 7 zero's followed by 128.. then towards the end there is a significant jump. (As it happens, this is the moment when fifo drops like a rock, then buffer runs out).  Also, the number of system interrupts (system -> in) goes from ~2400 to ~2700 at the same time.  What all this means.. no idea  :Sad: 

```

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 2  0  21148   8904  19904 415580    0    0    81    91  103    83  7  4 88  0

 1  0  21148   8884  19904 415588    0    0     0     0 2423   581  0  1 99  0

 1  0  21148   8848  19940 415588    0    0     0    88 2412   581  0  3 97  0

 1  0  21148   8848  19940 415588    0    0     0     0 2381   565  0  2 98  0

 1  0  21148   8848  19940 415588    0    0     0     0 2447   574  0  2 98  0

 1  0  21148   8848  19940 415588    0    0     0     0 2446   770  0  1 99  0

 1  0  21148   8716  19940 415716    0    0   128     0 2420   568  0  2 98  0

 1  0  21148   8692  19964 415716    0    0     0    48 2458   619  0  1 99  0

 1  0  21148   8688  19964 415716    0    0     0     0 2402   575  0  1 99  0

 1  0  21148   4432  19964 419432    0    0     0     0 2582   817  2  4 94  0

 1  0  21148   4432  19964 419432    0    0     0     0 2412   581  0  2 98  0

 1  0  21148   4456  19964 419304    0    0     0     0 2492  2743  0  2 98  0

 1  0  21148   4432  19988 419304    0    0     0    44 2423   626  0  2 98  0

 1  0  21148   4432  19988 419304    0    0     0     0 2393   604  0  3 97  0

 1  0  21148   4412  19988 419312    0    0   128     0 2530  2856  0  4 96  0

 2  0  21148   4412  19988 419312    0    0     0     0 2432  1346  0  2 98  0

 1  0  21148   4408  19988 419316    0    0     0     0 2433  1603  0  4 96  0

 1  0  21148   4368  20024 419316    0    0     0    68 2444  1594  0  0 100  0

 2  0  21148   4364  20024 419320    0    0     0     0 2451  1579  1  3 96  0

 1  0  21148   4360  20024 419324    0    0     0     0 2440  1604  0  3 97  0

 1  0  21148   4348  20024 419336    0    0     0     0 2438  1591  1  1 98  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 3  0  21148   4344  20024 419340    0    0     0     0 2441  1571  0  1 99  0

 1  0  21148   4428  20060 419220    0    0   128    68 2436  1601  0  2 98  0

 1  0  21148   4424  20060 419224    0    0     0     0 2438  1606  0  4 96  0

 2  0  21148   4412  20060 419232    0    0     0     0 2456  1585  0  3 97  0

 1  0  21148   4408  20060 419236    0    0     0     0 2404  1571  0  3 97  0

 1  0  21148   4404  20060 419240    0    0     0     0 2463  1605  0  0 100  0

 2  0  21148   4368  20096 419240    0    0     0    64 2429  1595  0  3 97  0

 1  0  21148   4368  20096 419240    0    0     0     0 2490  1571  0  3 97  0

 1  0  21148   4368  20096 419240    0    0     0     0 2401  1595  0  3 97  0

 1  0  21148   4364  20096 419240    0    0     0     0 2482  1577  0  1 99  0

 1  0  21148   4348  20096 419252    0    0   128     0 2442  1567  0  5 95  0

 1  0  21148   4440  20132 419124    0    0     0   196 2487  1616  0  1 99  0

 1  0  21148   4428  20132 419132    0    0     0     0 2399  1578  0  3 97  0

 1  0  21148   4428  20132 419132    0    0     0     0 2454  1574  0  2 98  0

 1  0  21148   4428  20132 419132    0    0     0     0 2433  1590  0  2 98  0

 2  0  21148   4424  20132 419136    0    0     0     0 2487  1551  0  2 98  0

 1  0  21148   4388  20168 419136    0    0     0    68 2419  1620  0  4 96  0

 1  0  21148   4380  20168 419144    0    0     0     0 2473  1610  0  3 97  0

 2  0  21148   4380  20168 419144    0    0   128     0 2445  1532  0  4 96  0

 1  0  21148   4376  20168 419148    0    0     0     0 2464  1615  0  5 95  0

 1  0  21148   4376  20168 419148    0    0     0     0 2395  1605  0  3 97  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 3  0  21148   4464  20204 419024    0    0     0    68 2492  1564  0  1 99  0

 1  0  21148   4456  20204 419028    0    0     0     0 2418  1605  0  3 97  0

 1  0  21148   4456  20204 419028    0    0     0     0 2435  1572  0  2 98  0

 2  0  21148   4456  20204 419028    0    0     0     0 2404  1560  1  5 94  0

 1  0  21148   4452  20204 419032    0    0     0     0 2494  1603  0  3 97  0

 1  0  21148   4408  20240 419040    0    0   128    84 2459  1593  0  1 99  0

 2  0  21148   4404  20240 419044    0    0     0     0 2443  1563  0  3 97  0

 1  0  21148   4404  20240 419044    0    0     0     0 2426  1603  0  2 98  0

 1  0  21148   4396  20240 419048    0    0     0     0 2460  1580  0  4 96  0

 2  0  21148   4360  20276 419048    0    0     0    68 2460  1590  0  0 100  0

 1  0  21148   4356  20276 419052    0    0     0     0 2472  1601  0  3 97  0

 1  0  21148   4356  20276 419052    0    0     0     0 2417  1576  0  3 97  0

 2  0  21148   4352  20276 419056    0    0     0     0 2485  1580  0  5 95  0

 1  0  21148   4352  20276 419056    0    0   128     0 2421  1591  0  1 99  0

 1  0  21148   4444  20312 418928    0    0     0    64 2447  1588  0  5 95  0

 2  0  21148   4444  20312 418928    0    0     0     0 2437  1563  0  1 99  0

 1  0  21148   4444  20312 418928    0    0     0     0 2490  1581  0  3 97  0

 1  0  21148   4432  20312 418936    0    0     0     0 2434  1601  0  3 97  0

 2  0  21148   4432  20312 418936    0    0     0     0 2455  1572  0  2 98  0

 1  0  21148   4396  20348 418936    0    0     0    68 2430  1584  0  1 99  0

 1  0  21148   4396  20348 418936    0    0     0     0 2461  1597  0  4 96  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 3  0  21148   4396  20348 418936    0    0   128     0 2433  1570  0  1 99  0

 1  0  21148   4396  20348 418936    0    0     0     0 2424  1576  0  4 96  0

 1  0  21148   4396  20348 418936    0    0     0     0 2427  1603  0  3 97  0

 1  0  21148   4372  20372 418936    0    0     0   128 2486  1578  0  4 96  0

 1  0  21148   4368  20372 418936    0    0     0     0 2448  1569  0  2 98  0

 1  0  21148   4368  20372 418936    0    0     0     0 2444  1605  1  3 96  0

 1  0  21148   4368  20372 418936    0    0     0     0 2456  1564  0  1 99  0

 1  0  21148   4368  20372 418936    0    0     0     0 2473  1567  0  3 97  0

 1  0  21148   4360  20380 418936    0    0   128    16 2446  1615  0  2 98  0

 2  0  21148   4360  20380 418936    0    0     0     0 2456  1540  0  2 98  0

 1  0  21148   4360  20380 418936    0    0     0     0 2460  1597  0  3 97  0

 1  0  21148   4360  20380 418936    0    0     0     0 2452  1598  0  3 97  0

 2  0  21148   4360  20380 418936    0    0     0     0 2460  1534  0  2 98  0

 1  0  21148   4348  20388 418936    0    0     0    16 2421  1610  0  2 98  0

 1  0  21148   4348  20388 418936    0    0     0     0 2446  1598  0  3 97  0

 2  0  21148   4348  20388 418936    0    0     0     0 2434  1542  0  3 97  0

 1  0  21148   4356  20388 418940    0    0   128     0 2465  1594  0  2 98  0

 2  0  21148   4356  20388 418940    0    0     0     0 2457  1568  0  3 97  0

 2  0  21148   4448  20424 418812    0    0     0    76 2459  1596  0  2 98  0

 1  0  21148   4444  20424 418816    0    0     0     0 2467  1608  0  2 98  0

 1  0  21148   4444  20424 418816    0    0     0     0 2455  1565  0  4 96  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 3  0  21148   4440  20424 418820    0    0     0     0 2397  1579  0  5 95  0

 1  0  21148   4436  20424 418820    0    0     0     0 2447  1597  0  3 97  0

 1  0  21148   4396  20460 418824    0    0     0    64 2441  1599  0  2 98  0

 2  0  21148   4396  20460 418824    0    0   128     0 2456  1564  0  3 97  0

 1  0  21148   4396  20460 418824    0    0     0     0 2467  1596  0  2 98  0

 1  0  21148   4392  20460 418828    0    0     0     0 2513  1578  0  3 97  0

 2  0  21148   4392  20460 418828    0    0     0     0 2459  1578  0  3 97  0

 1  0  21148   4352  20496 418832    0    0     0    68 2497  1618  0  1 99  0

 1  0  21148   4348  20496 418836    0    0     0     0 2394  1563  0  2 98  0

 2  0  21148   4344  20496 418836    0    0     0     0 2502  1571  0  4 96  0

 1  0  21148   4464  20496 418712    0    0     0     0 2404  1571  0  2 98  0

 1  0  21148   4464  20496 418712    0    0   128     0 2521  1596  0  3 97  0

 2  0  21148   4420  20532 418716    0    0     0    88 2440  1601  0  3 97  0

 1  0  21148   4420  20532 418716    0    0     0     0 2490  1560  0  2 98  0

 1  0  21148   4420  20532 418716    0    0     0     0 2416  1606  0  3 97  0

 2  0  21148   4420  20532 418716    0    0     0     0 2516  1566  0  2 98  0

 1  0  21148   4420  20532 418716    0    0     0     0 2390  1575  0  2 98  0

 1  0  21148   4412  20540 418716    0    0     0    64 2565  1605  0  2 98  0

 2  0  21148   4400  20540 418724    0    0     0     0 2380  1584  0  3 97  0

 1  0  21148   4400  20540 418724    0    0     0     0 2528  1556  0  2 98  0

 1  0  21148   4396  20540 418728    0    0   128     0 2383  1603  1  3 96  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 2  0  21148   4396  20540 418728    0    0     0     0 2506  1570  0  2 98  0

 1  0  21148   4360  20576 418728    0    0     0    72 2400  1601  0  3 97  0

 1  0  21148   4360  20576 418728    0    0     0     0 2532  1601  0  2 98  0

 2  0  21148   4360  20576 418728    0    0     0     0 2421  1534  0  4 96  0

 1  0  21148   4356  20576 418728    0    0     0     0 2529  1601  0  2 98  0

 1  0  21148   4356  20576 418728    0    0     0     0 2387  1599  0  4 96  0

 2  0  21148   4460  20600 418600    0    0     0    40 2530  1560  0  2 98  0

 1  0  21148   4456  20564 418640    0    0   128     0 2391  1614  0  3 97  0

 1  0  21148   4456  20564 418640    0    0     0     0 2556  1597  0  0 100  0

 2  0  21148   4452  20564 418644    0    0     0     0 2379  1546  0  4 96  0

 2  0  21148   4464  20564 418632    0    0   244     0 2616  1642  0  5 95  0

 1  3  21148   4456  20600 418632    0    0  1408    72 2709  1923  0  6 94  0

 2  0  21148   4432  20612 418636    0    0  1284    16 2795  1671  0  3 97  0

 1  1  21148   4436  20612 418636    0    0  1280     0 2734  2002  0  2 98  0

 1  1  21148   4428  20612 418640    0    0   896     0 2745  1526  0  0 100  0

 1  1  21148   4424  20616 418652    0    0  1540     0 2758  1949  0  6 94  0

 1  1  21148   4420  20616 418668    0    0  1280     0 2862  1863  0  4 96  0

 1  1  21148   4384  20616 418764    0    0  1408    64 2744  1912  0  4 96  0

 1  1  21148   4416  20620 418764    0    0   856     0 2760  1563  0  4 96  0

 2  0  21148   4372  20620 418852    0    0  1196     0 2673  1757  0  2 98  0

 1  1  21148   4364  20620 418864    0  112  1280   112 2834  1846  0  3 97  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 2  1  21148   4364  20620 418864    0    0  1152     0 2650  1767  0  2 98  0

 1  1  21148   4432  20660 418744    0    0  1156    68 2821  1743  0  4 96  0

 1  1  21148   4428  20660 418744    0    0  1408     0 2695  1828  0  3 97  0

 2  1  21148   4420  20660 418752    0    0  1408     0 2781  1770  0  4 96  0

 1  1  21148   4412  20628 418792    0    0  1284     0 2703  1756  0  4 96  0

 1  0  21148   4404  20628 418800    0    0  1152     0 2757  1570  0  4 96  0

 1  0  21148   4368  20664 418800    0    0     0   152 2448   718  0  2 98  0

```

----------

## mickwd

Right, well your problem does seem to be all the disk activity which slows things down - that's when the numbers in the "io" -> "bi" column turn high (don't worry about the occasional 128 there).

SOMETHING is causing that disk activity. I THINK it's because of what I mentioned (the fact that the system is using up RAM to store the ISO image being piped), but I'm not sure. I'm very puzzled why your RAM settings aren't changing (although the "free" memory drops from 8.9MB to 4.4MB early on).

I don't really know what the best solution is. You could write the ISO to a file first, if you have the space. You could try using a different kernel - maybe a low-latency kernel would work better, or try 2.6 if you're not using it already (but search / read up about the ide-scsi CD-writing issues). Alternatively, buy some more RAM (enough to buffer the ISO in memory, and run the system simultaneously).

----------

## Jerri

Alrighty.. as i mentioned, the ram drops from 8.9 to 4.4 early on because thats when I run cdrecord.  Secondly, I can't beleive that i need more ram.. 512 MBytes pc3200 cas2 should be enough.  My old comp (k6-2 500 Mhz w/ 54 megs ram!) could burn cd's no prob (even pipe mkisofs to cdrecord).

I tried creating iso file then burning.. to my surprise, it was succesfull, however, that is a very long burn (20 mins / cd).  I recorded the output of vmstat, and found some interesting results:  (this is cdrecord burning an iso image.. no mkisofs pipe)

```

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 1  0      0 327144   7684 119180    0    0   193     5 3207   509  7 14 79  0

 0  0      0 326976   7684 119328    0    0   144     0 3405  1029  0 13 87  0

 1  0      0 326976   7684 119328    0    0     0     0 3265   909  0 10 90  0

=======cdrecord starts here========

 1  0      0 322536   7692 123428    0    0     0    40 3508  1118  1 11 88  0

 0  0      0 322464   7692 123428    0    0     0     0 3363  1050  0 14 86  0

 1  0      0 322452   7692 123428    0    0     0     0 3356   979  0 12 88  0

 2  0      0 322320   7692 123556    0    0   128     0 3275   969  0 12 88  0

 1  0      0 322320   7692 123556    0    0     0     0 3370   957  1 10 89  0

 0  0      0 322300   7700 123556    0    0     0    16 3420  1193  0 11 89  0

 0  0      0 322300   7700 123556    0    0     0     0 3343  1019  0 13 87  0

 2  0      0 322300   7700 123556    0    0     0     0 3337  1006  1 13 86  0

 1  0      0 322300   7700 123556    0    0     0     0 3333  1034  0 12 88  0

 1  0      0 322168   7700 123684    0    0   128     0 3347  1032  0 10 90  0

 1  0      0 322160   7708 123684    0    0     0    16 3330  1008  0 11 89  0

 2  0      0 322160   7708 123684    0    0     0     0 3326  1027  1 13 86  0

 2  0      0 322160   7708 123684    0    0     0     0 3343  1012  0 14 86  0

 2  0      0 322160   7708 123684    0    0     0     0 3323  1010  0 12 88  0

 1  0      0 322028   7708 123812    0    0   128     0 3293  1033  0 10 90  0

 0  0      0 322016   7716 123812    0    0     0    16 3309  1021  0 11 89  0

 1  0      0 322016   7716 123812    0    0     0     0 3293  1018  0 12 88  0

 1  0      0 322016   7716 123812    0    0     0     0 3302  1013  1 12 87  0

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 3  0      0 322016   7716 123812    0    0     0     0 3308  1038  0 12 88  0

 1  0      0 322016   7716 123812    0    0     0     0 3293  1028  0 11 89  0

 0  0      0 321876   7724 123940    0    0   128    16 3305  1056  0 11 89  0

 1  0      0 321876   7724 123940    0    0     0     0 3298  1039  1 13 86  0

 0  0      0 321872   7724 123940    0    0     0     0 3276  1016  0 13 87  0

 1  0      0 321872   7724 123940    0    0     0     0 3283  1017  0 12 88  0

 2  0      0 321872   7724 123940    0    0     0     0 3307  1056  0 11 89  0

 2  0      0 321732   7732 124068    0    0   128    16 3282  1046  0  9 91  0

 1  0      0 320464   7736 125292    0    0  1228     0 3357  1069  1 13 86  0

 1  0      0 318612   7736 127084    0    0  1792     0 3366  1031  0 13 87  0

 2  0      0 316756   7740 128876    0    0  1796     0 3411  1082  0 13 87  0

 1  0      0 314904   7740 130668    0    0  1792     0 3384  1062  1 11 88  0

 2  0      0 312912   7748 132588    0    0  1920    40 3404  1058  0 11 89  0

 2  0      0 311052   7752 134380    0    0  1796     0 3392  1058  0 13 87  0

 2  0      0 309068   7752 136300    0    0  1920     0 3392  1070  0 13 87  0

 0  0      0 307344   7756 137964    0    0  1668     0 3396  1067  0 12 88  0

 1  0      0 305360   7756 139884    0    0  1920     0 3429  1047  1 14 85  0

 0  0      0 303496   7768 141676    0    0  1796    16 3400  1067  0 10 90  0

 0  0      0 301512   7768 143596    0    0  1920     0 3411  1094  0 13 87  0

 2  0      0 299656   7772 145388    0    0  1796     0 3349  1030  1 12 87  0

 0  0      0 297804   7772 147180    0    0  1792     0 3335  1076  0 12 88  0

=== Ram continues to fall (~1Mbyte/sec) Blocks in remains consistent at ~1700 - 2000===

=== few minutes go by ===

 3  0      0  14168   8280 421076    0    0  1792     0 3358  1021  0 13 87  0

 2  0      0  12316   8280 422868    0    0  1792     0 3336  1046  1 12 87  0

 1  0      0  10320   8292 424788    0    0  1924    32 3350  1087  0 11 89  0

 2  0      0   8468   8292 426580    0    0  1792     0 3359  1031  0 13 87  0

 1  0      0   6608   8296 428372    0    0  1796     0 3351  1044  0 12 88  0

 1  0      0   4756   8296 430164    0    0  1792     0 3355  1019  0 13 87  0

 1  0      0   5244   7856 430268    0    0  1796     0 3373  1033  1 11 88  0

 2  0      0   4340   7820 431264    0    0  2048    16 3342  1058  0 11 89  0

 2  0      0   4840   7760 430924    0    0  1796     0 3374  1024  0 12 88  0

 2  0      0   5344   7568 430656    0    0  1792     0 3315  1076  1 13 86  0

 1  0      0   4696   7488 431392    0    0  1792     0 3362  1053  0 13 87  0

 0  0      0   5188   7432 430972    0    0  1796     0 3342  1044  0 12 88  0

 1  0      0   4532   7436 431628    0    0  1792    16 3373  1059  0 11 89  0

 0  0      0   4896   7432 431276    0    0  1924     0 3359  1027  1 11 88  0

 1  0      0   5376   7432 430788    0    0  1792     0 3383  1045  0 14 86  0

 1  0      0   4724   7436 431456    0    0  1796     0 3314  1035  1 12 87  0

 0  0      0   5208   7436 430964    0    0  1792     0 3370  1040  0 12 88  0

 1  0      0   4412   7448 431740    0    0  1924    28 3315  1068  0 11 89  0

 1  0      0   4652   7448 431500    0    0  1920     0 3396  1014  1 12 87  0

=== here we see free ram fall from 322 MB to level off at~4MB ===

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 2  0      0   4444   7196 431524    0    0  1796     0 3363  1185  1 12 87  0

 0  0      0   4924   7196 431036    0    0  1792     0 3372  1381  0 13 87  0

 0  0      0   5380   7196 430560    0    0  1792     0 3401  1487  1 10 89  0

 0  0      0   5284   7208 430728    0    0  1300    16 3320  1098  1 11 88  0

 2  0      0   5156   7208 430856    0    0   128     0 3343  1071  0 14 86  0

 0  0      0   5156   7208 430856    0    0     0     0 3290   948  1 13 86  0

 0  0      0   5156   7208 430856    0    0     0     0 3273   902  0 11 89  0

 1  0      0   5156   7208 430856    0    0     0     0 3289   932  0 11 89  0

 1  0      0   9564   7216 426756    0    0     0    16 3326  1058  0 10 90  0

 2  0      0   9432   7216 426884    0    0   128     0 3276   887  1 12 87  0

=== cdrecord finishes here ===

```

What I don't understand is Blocks recieved remains at a consitent ~1700-1900 through the whole burn (with start being the exception).  If we refer to vmstats taken while trying to burn with mkisofs piping to cdrecord (2 posts up) blocks recieved remains at 0 until the end where there is a buffer underrun. Whats goning on here?  Also, whats the deal with free ram falling from 322MB to 4MB?  The files are located on a reiserfs partition, could this be an issue?  I'm also running linux 2.4.22-ck2 (recent upgrade from vanilla 2.4.22).

----------

## Jerri

hmm, I forgot take cache into account.  I suppose thats whats happening to all my free ram. cache starts at 119180 and finishes at 418800.  But i'm still confused about blocks recieved.

----------

## Jerri

Ok, I don't get it.   I tried a burn with k3b, and it burned succesfully. with 'on the fly option' enabled.  

Track 01: Total bytes read/written: 736061440/736061440 (359405 sectors).

Writing  time:  414.079s

Average write speed  11.6x.

Min drive buffer fill was 94%

Fixating...

WARNING: Some drives don't like fixation in dummy mode.

Fixating time:   18.827s

/usr/bin/cdrecord: fifo had 11594 puts and 11594 gets.

/usr/bin/cdrecord: fifo was 0 times empty and 4370 times full, min fill was 89%.

WTF! i didn't change anything!   why can k3b burn successfully and cdrecord not?  doesn't k3b use cdrecord? errr!  I'm going to try some real burns (no dummy mode) if I intermitently burn coasters, forget this nonsens, windows here i come! (blah)

----------

## Jerri

Well, 2 out of 3 burns were successfull.. but that just aint good enough.

----------

## Jerri

Ok, i take it back!  I can't stand using windows (/me pukes).

I thought I had it for a while, 5 successful burns, min fill was ~85%,  *but* same thing started to happen, all over again  :Sad: 

Things I changed:

- switched to vanilla sources (2.4.23) from ck-sources

- included AMD Viper ata-66 override (running abit NF7-S w/ nforce2)

I'm totally stumped..  ideas, anything!?!  It's like a sliver, in the crack of your butt check..  uncomfortable regardless of what position your in.. :\

----------

## isnogood

Probably wont help you any but here it goes:

Did have trouble burning videos and stuff.Burning slowed down from 32x to 2x - no coasters though.The problem was that the files themselves where fragmented all over the place and the drive couldn't keep up.Try to copy the file you want to burn to a different partition and see what that does.

----------

## Jerri

Right on, I'll give that a try.   I wonder if that is a windows fix..  I was under the impression that linux doesn't fragment files as badly as windows does.  Could be mistaken.  Even if fragmented, I think my throughput is capable of handling it (I actually have nothing to base this statment on.. perhaps i'm simply trying to justify purchasing this drive :\).. here is output of hdparm -tT  /dev/hda:

```

/dev/hda:

 Timing buffer-cache reads:   128 MB in  0.33 seconds =387.88 MB/sec

 Timing buffered disk reads:  64 MB in  1.34 seconds = 47.76 MB/sec

```

Interesting note.. I tried running the above command while burning a cd and got:

```

/dev/hda:

 Timing buffer-cache reads:   128 MB in  0.34 seconds =376.47 MB/sec

 Timing buffered disk reads:  64 MB in 28.91 seconds =  2.21 MB/sec

```

I wonder if this has any bearing on my drives capabilities..

Anyways, lately I have been considering the idea of bad media.  The disks I got, (purchased 100 at 35 cents a piece.. canadian!) I have no troubles burning with nero, but i noticed, every now and then, a burn will run at ~8x (whereas its set to run at 12x)  I guess i will have to save these for junk music cd's and go out and buy some better quality disks.. see how that runs.  I also tried running with fs=8m which had no effect.

----------

## a3ulafia

Here's a problem that's similar, but very weird. When I first got this computer I installed Mandrake 9.1. Then I found out about Gentoo and I burned a Gentoo 1.4 ISO with k3b and the CD recorder. No problem. I was all happy about Gentoo until I tried to burn a CD again.

Every CD recording program I use ignores the speed I set. It tries to burn as fast as it can, which usually spikes to 30X until the buffer overflows and everything stops. When burning some ogg files it got as high as 100X.

It won't burn anything in on-the-fly mode either from another CD or from files on disk. I know the system is fast enough to do an on-the-fly copy between two cd's at 4X. Tried with a vanilla kernel, same problem.

-lee

----------

## Jerri

It appears that my hard disk is busted, or at least responsible for the buffer underruns.   The reason for jumping to this conclusion is, I tried burning  files stored on a different hard drive, and have had excellent results.  I find this most unusual, as performance results from hdparm -t prove to be reasonable: ~47 MB/sec, however, when copying large files to and from the hard drive in question, copying time is significantly slower compared to transfers between other drives (this is not an isolated incident, it happens every time).  I also picked up a new burner (plextor premium)  and the same thing would happen, successful burns with new hard disk, buffer underrun with old (this is running at speed=48).

I tried using maxtor's powermax diagnostic utility, which proved to be useless. So without any conclusive evidence suggesting any other explanation, i'm only able to speculate that my maxtor hard disk was responsible.

One more note, for those using the plextor premium cd-rw, only use media recommended by plextor.  I made the mistake of buying some cheap cd-r's (turned out to be rytek) which produce some really crappy burns. to verify, use the Q-check feature, provided by PlexTools (one more unfortunate reason for running windows).

I guess the moral of this story, never touch Maxtor or Rytek again..

----------

