Major speed problem with reads from JFS - OS2

This is a discussion on Major speed problem with reads from JFS - OS2 ; Di(nice -t -n -29 mkisofs2 -v -r -T -J . | cdrecord_and_checksum_stdin "dev=0,1,0" driveropts=burnfree -v -fs=64m -blank=fast) |& tee ..\burn-Marinad anybody see something like this, or knows a solution? I have a pipeline reader_from_disk | writer_to_dvd (details can vary, different ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Major speed problem with reads from JFS

  1. Major speed problem with reads from JFS

    Di(nice -t -n -29 mkisofs2 -v -r -T -J . |
    cdrecord_and_checksum_stdin "dev=0,1,0" driveropts=burnfree -v -fs=64m
    -blank=fast) |& tee ..\burn-Marinad anybody see something like this, or knows a solution?

    I have a pipeline

    reader_from_disk | writer_to_dvd

    (details can vary, different writers, slightly different readers).

    The reader runs at priority time_critical + 29, writer at priority
    time_critical + 31. Writer has a huge read buffer (e.g., 64M or some
    such). The whole pipeline runs at CPU load well below 100%.

    When I read from HPFS, everything is fine. When I read from JFS, the
    reader is not filling the writer's buffer at all, so I get thousands
    of buffer underruns. The simplest case is

    nice -t -n -29 mkisofs2 -v -r -T -J .
    | cdrecord2 dev=0,1,0 driveropts=burnfree -v -fs=64m -eject

    The same happens with mkisofs, cdrecord, dvddao. Same happens if I
    decrease write speed, so it is not the throughput problem. Hard disks
    are IDE, Dani drivers, with the correct (same!) diagnostics (see below).

    One difference between HPFS and JFS is the spindles: HPFS is on a
    different (but same make) spindle. The only major difference is that
    JFS hard disk shares the IDE cable with the DVD writer (I have 3 HD, and 2
    writers, so when the 3rd disk came, I needed to switch off one writer
    at all ;-).

    This cable is as this:

    Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz
    Unit:0 Status:OK SMS:16 LBA BusMaster UltraDMA4/PIO4 BPB
    Model:ST3200822A 3.01
    OS2:log phys BPB/BIOS IDE:log phys Total Sectors
    C 24321 65535 65535 16383 Avail 390721968
    H 255 16 255 16 16 OS2 390716865
    S 63 63 63 63 63 % Used 99.99
    Unit:1 Status:OK ATAPI BusMaster UltraDMA2/PIO4
    Model:_NEC DVD_RW ND-2500A 1.06


    Any idea?

    Thanks,
    Ilya

  2. Re: Major speed problem with reads from JFS

    Hi Ilya

    Ilya Zakharevich wrote:
    > Di(nice -t -n -29 mkisofs2 -v -r -T -J . |
    > cdrecord_and_checksum_stdin "dev=0,1,0" driveropts=burnfree -v -fs=64m
    > -blank=fast) |& tee ..\burn-Marinad anybody see something like this, or knows a solution?
    >
    > I have a pipeline
    >
    > reader_from_disk | writer_to_dvd
    >
    > (details can vary, different writers, slightly different readers).
    >
    > The reader runs at priority time_critical + 29, writer at priority
    > time_critical + 31. Writer has a huge read buffer (e.g., 64M or some
    > such). The whole pipeline runs at CPU load well below 100%.
    >
    > When I read from HPFS, everything is fine. When I read from JFS, the
    > reader is not filling the writer's buffer at all, so I get thousands
    > of buffer underruns. The simplest case is
    >
    > nice -t -n -29 mkisofs2 -v -r -T -J .
    > | cdrecord2 dev=0,1,0 driveropts=burnfree -v -fs=64m -eject
    >
    > The same happens with mkisofs, cdrecord, dvddao. Same happens if I
    > decrease write speed, so it is not the throughput problem. Hard disks
    > are IDE, Dani drivers, with the correct (same!) diagnostics (see below).
    >
    > One difference between HPFS and JFS is the spindles: HPFS is on a
    > different (but same make) spindle. The only major difference is that
    > JFS hard disk shares the IDE cable with the DVD writer



    And there may be your speed problem.

    I suspect that the disk can only perform to the max speed of the slowest
    drive on that cable - the DVD writer.

    I suspect you may have to rearrange your drives to test that.

    Regards

    Pete



    (I have 3 HD, and 2
    > writers, so when the 3rd disk came, I needed to switch off one writer
    > at all ;-).
    >
    > This cable is as this:
    >
    > Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    > VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz
    > Unit:0 Status:OK SMS:16 LBA BusMaster UltraDMA4/PIO4 BPB
    > Model:ST3200822A 3.01
    > OS2:log phys BPB/BIOS IDE:log phys Total Sectors
    > C 24321 65535 65535 16383 Avail 390721968
    > H 255 16 255 16 16 OS2 390716865
    > S 63 63 63 63 63 % Used 99.99
    > Unit:1 Status:OK ATAPI BusMaster UltraDMA2/PIO4
    > Model:_NEC DVD_RW ND-2500A 1.06
    >
    >
    > Any idea?
    >
    > Thanks,
    > Ilya


  3. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    Peter Brown
    ], who wrote in article <1fmgg.2748$uP.2457@newsfe2-gui.ntli.net>:
    > > One difference between HPFS and JFS is the spindles: HPFS is on a
    > > different (but same make) spindle. The only major difference is that
    > > JFS hard disk shares the IDE cable with the DVD writer


    > And there may be your speed problem.
    >
    > I suspect that the disk can only perform to the max speed of the slowest
    > drive on that cable - the DVD writer.


    The situation happens no matter what is the choosen writing speed of
    the DVD. Writing speed of JFS drive is 27M/sec, reading is 36M/sec
    (checked with 300M file). The problem persists even with 2.9M/sec DVD
    writing speed.

    Can the JFS read speed change during DVD write?

    Thanks,
    Ilya

  4. Re: Major speed problem with reads from JFS

    Sir:

    Ilya Zakharevich wrote:
    > Di(nice -t -n -29 mkisofs2 -v -r -T -J . |
    > cdrecord_and_checksum_stdin "dev=0,1,0" driveropts=burnfree -v -fs=64m
    > -blank=fast) |& tee ..\burn-Marinad anybody see something like this, or knows a solution?
    >
    > I have a pipeline
    >
    > reader_from_disk | writer_to_dvd
    >
    > (details can vary, different writers, slightly different readers).
    >
    > The reader runs at priority time_critical + 29, writer at priority
    > time_critical + 31. Writer has a huge read buffer (e.g., 64M or some
    > such). The whole pipeline runs at CPU load well below 100%.
    >
    > When I read from HPFS, everything is fine. When I read from JFS, the
    > reader is not filling the writer's buffer at all, so I get thousands
    > of buffer underruns. The simplest case is
    >
    > nice -t -n -29 mkisofs2 -v -r -T -J .
    > | cdrecord2 dev=0,1,0 driveropts=burnfree -v -fs=64m -eject
    >
    > The same happens with mkisofs, cdrecord, dvddao. Same happens if I
    > decrease write speed, so it is not the throughput problem. Hard disks
    > are IDE, Dani drivers, with the correct (same!) diagnostics (see below).
    >
    > One difference between HPFS and JFS is the spindles: HPFS is on a
    > different (but same make) spindle. The only major difference is that
    > JFS hard disk shares the IDE cable with the DVD writer (I have 3 HD, and 2
    > writers, so when the 3rd disk came, I needed to switch off one writer
    > at all ;-).
    >
    > This cable is as this:
    >
    > Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    > VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz
    > Unit:0 Status:OK SMS:16 LBA BusMaster UltraDMA4/PIO4 BPB
    > Model:ST3200822A 3.01
    > OS2:log phys BPB/BIOS IDE:log phys Total Sectors
    > C 24321 65535 65535 16383 Avail 390721968
    > H 255 16 255 16 16 OS2 390716865
    > S 63 63 63 63 63 % Used 99.99
    > Unit:1 Status:OK ATAPI BusMaster UltraDMA2/PIO4
    > Model:_NEC DVD_RW ND-2500A 1.06
    >
    >
    > Any idea?
    >


    Classical problem of bus contention between JFS spindle and DVD (you
    need to double check that you have a 80-wire cable and add that to Dani
    driver commands. You may be running at UDMA 1 rate, guess from the
    33MHz report). Put the DVD on a different cable than the one which has
    the buffers (hard drive) would help, if you only have 40-wire cables.
    It would speed up the buffers if both programs used the same drive
    letter for the buffers (don't forget the large JFS buffer affect!) or
    better still if they were on a ram disk. I'd suggest that the buffers
    each only be less than or equal to 4 MiB, to reduce overhead
    bookkeeping. You want them to be only as large as necessary to not have
    burn under runs (coasters).
    --
    Bill
    Thanks a Million!

  5. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    William L. Hartzell
    ], who wrote in article :
    > Classical problem of bus contention between JFS spindle and DVD (you
    > need to double check that you have a 80-wire cable and add that to Dani
    > driver commands.


    Both cables are the same, 80-wire. How to ask the driver whether the
    80-wire support is enabled? (VIA 571 is not listed as needing
    /80wire, AND I remember major improvement when switching to correct cabling.)

    > You may be running at UDMA 1 rate, guess from the 33MHz report).


    The rate is clearly marked as UltraDMA4.

    > It would speed up the buffers if both programs used the same drive
    > letter for the buffers (don't forget the large JFS buffer affect!) or
    > better still if they were on a ram disk.


    This does not parse. (And my JFS cache is small comparing to DVD writer
    application buffer.)

    > I'd suggest that the buffers each only be less than or equal to 4
    > MiB, to reduce overhead bookkeeping.


    DVD writing with buffers below 32M is insane. Especially on an OS
    without any kind of process priority (except for CPU).

    Thanks for a try,
    Ilya

  6. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Ilya Zakharevich
    ], who wrote in article :
    > > Classical problem of bus contention between JFS spindle and DVD (you
    > > need to double check that you have a 80-wire cable and add that to Dani
    > > driver commands.

    >
    > Both cables are the same, 80-wire. How to ask the driver whether the
    > 80-wire support is enabled? (VIA 571 is not listed as needing
    > /80wire, AND I remember major improvement when switching to correct cabling.)


    I was right, /80wire does not change anything in `cat IBMS506$'.

    Sigh,
    Ilya

  7. Re: Major speed problem with reads from JFS

    Sir:

    Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was NOT [per weedlist] sent to
    > Ilya Zakharevich
    > ], who wrote in article :
    >>> Classical problem of bus contention between JFS spindle and DVD (you
    >>> need to double check that you have a 80-wire cable and add that to Dani
    >>> driver commands.

    >> Both cables are the same, 80-wire. How to ask the driver whether the
    >> 80-wire support is enabled? (VIA 571 is not listed as needing
    >> /80wire, AND I remember major improvement when switching to correct cabling.)

    >
    > I was right, /80wire does not change anything in `cat IBMS506$'.
    >


    But you not addressed the over large buffer problem that you made.
    --
    Bill
    Thanks a Million!

  8. Re: Major speed problem with reads from JFS

    Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was NOT [per weedlist] sent to
    > Ilya Zakharevich
    > ], who wrote in article :
    >
    >>>Classical problem of bus contention between JFS spindle and DVD (you
    >>>need to double check that you have a 80-wire cable and add that to Dani
    >>>driver commands.

    >>
    >>Both cables are the same, 80-wire. How to ask the driver whether the
    >>80-wire support is enabled? (VIA 571 is not listed as needing
    >>/80wire, AND I remember major improvement when switching to correct cabling.)

    >
    >
    > I was right, /80wire does not change anything in `cat IBMS506$'.
    >
    > Sigh,
    > Ilya


    Ilya:

    FWIW, my experience on at least a half dozen machines (or more) has been that if
    anything else is going on on the IDE controller that your burner is on while you
    are burning a CD of DVD, you have just made a coaster. Admittedly, I have never
    forced burnfree to be on -- as I understand it, it is off by default.


  9. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    James J. Weinkam
    ], who wrote in article <3OOgg.11904$I61.9312@clgrps13>:

    > FWIW, my experience on at least a half dozen machines (or more) has
    > been that if anything else is going on on the IDE controller that
    > your burner is on while you are burning a CD of DVD, you have just
    > made a coaster. Admittedly, I have never forced burnfree to be on
    > -- as I understand it, it is off by default.


    Here (with burnfree) the coaster rate is not dependent on the number
    of underruns. Number of underruns depends on HPFS vs JFS factor, but
    the proportion of coasters is approximately the same.

    This year the coaster rate has been extremely high; but it may be due
    to a 100high pack of Tayo Yugen (!) DVD-Rs which I think might have
    been defective. Or maybe the writer is too old (my CD players/burners
    live very short - plextor, nec - does not matter).

    Thanks,
    Ilya

  10. Re: Major speed problem with reads from JFS

    Ilya Zakharevich writes:

    > Or maybe the writer is too old (my CD players/burners
    > live very short - plextor, nec - does not matter).


    How short is "very short"?


  11. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to

    ], who wrote in article :
    > Ilya Zakharevich writes:
    >
    > > Or maybe the writer is too old (my CD players/burners
    > > live very short - plextor, nec - does not matter).


    > How short is "very short"?


    Do not remember any model which would work "same as new" after about
    2-3 years. (Well, there is one exception: the SCSI 4x Plextor CDROM
    reader still works fine - at least with pressed CDs - after 12 years)

    Yours,
    Ilya

  12. Re: Major speed problem with reads from JFS

    Ilya Zakharevich writes:

    >>> Or maybe the writer is too old (my CD players/burners
    >>> live very short - plextor, nec - does not matter).


    >> How short is "very short"?


    > Do not remember any model which would work "same as new" after about
    > 2-3 years. (Well, there is one exception: the SCSI 4x Plextor CDROM
    > reader still works fine - at least with pressed CDs - after 12 years)


    My Yamaha CRW-F1 CD burner must be at least three years old now, and
    still going strong.


  13. Re: Major speed problem with reads from JFS

    Sir:

    William L. Hartzell wrote:
    > Sir:
    >
    > Ilya Zakharevich wrote:
    >> [A complimentary Cc of this posting was NOT [per weedlist] sent to
    >> Ilya Zakharevich ], who wrote in article
    >> :
    >>>> Classical problem of bus contention between JFS spindle and DVD (you
    >>>> need to double check that you have a 80-wire cable and add that to
    >>>> Dani driver commands.
    >>> Both cables are the same, 80-wire. How to ask the driver whether the
    >>> 80-wire support is enabled? (VIA 571 is not listed as needing
    >>> /80wire, AND I remember major improvement when switching to correct
    >>> cabling.)

    >>
    >> I was right, /80wire does not change anything in `cat IBMS506$'.
    >>

    >
    > But you not addressed the over large buffer problem that you made.


    And Dani documentation says you need the /80wire switch to tell the
    driver that you are using 80-wire cables.
    --
    Bill
    Thanks a Million!

  14. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    William L. Hartzell
    ], who wrote in article :
    > >> I was right, /80wire does not change anything in `cat IBMS506$'.


    > And Dani documentation says you need the /80wire switch to tell the
    > driver that you are using 80-wire cables.


    No it does not. (Only with a few - broken - chipsets.)

    Hope this helps,
    Ilya

  15. Re: Major speed problem with reads from JFS

    Sir:

    Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was sent to
    > William L. Hartzell
    > ], who wrote in article :
    >>>> I was right, /80wire does not change anything in `cat IBMS506$'.

    >
    >> And Dani documentation says you need the /80wire switch to tell the
    >> driver that you are using 80-wire cables.

    >
    > No it does not. (Only with a few - broken - chipsets.)
    >


    From Dani chip list file:
    0x1106 VIA
    0x1571 571 x x ? x x - - - - -
    0x0571 571
    0x0586
    < 0x20 586 x x ? x x - - - - x
    >=0x20 586A/B x x x x x x - - - x

    0x0596
    < 0x10 596/A x x x x x x - - - x
    >=0x10 596B x x x x x x x - - x

    0x0686
    < 0x10 686 x x x x x x - - - -
    < 0x40 686A x x x x x x x - - x
    >=0x40 686B x x x x x x x x - x

    0x8231 VT8231 x x x x x x x x - -
    0x3074 VT8233 x x x x x x x x - x
    0x3109 VT8233c x x x x x x x x - -
    0x3147 VT8233a x x x x x x x x x -
    0x3177 VT8235 x x x x x x x x x -
    0x3227 VT8237 x x x x x x x x x -
    0x3287 VT8251 x x x x x x x x x -
    0x3164 VT6410 x x x x x x x x x -

    known bugs:
    - all: no host side cable type detection.
    - all: the busmaster 'active' bit doesn't match the actual
    busmaster state.
    - 596B: don't touch the busmaster registers too early after interrupt
    don't touch taskfile registers before stopping the busmaster!
    - 686 rev 40/41 and VT8231 rev 10/11 have the PCI corruption bug!

    From your first post this thread:
    Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz

    You'll note that the Via 571 is the first chip mentioned by Dani and the
    note under known bugs: no host side cable type detection. This means
    you need the /80wire command switch to tell the driver that you have an
    80-wire cable.
    --
    Bill
    Thanks a Million!

  16. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    William L. Hartzell
    ], who wrote in article :
    > >> And Dani documentation says you need the /80wire switch to tell the
    > >> driver that you are using 80-wire cables.


    > > No it does not. (Only with a few - broken - chipsets.)


    > From Dani chip list file:
    > 0x1106 VIA
    > 0x1571 571 x x ? x x - - - - -
    > 0x0571 571
    > 0x0586
    > < 0x20 586 x x ? x x - - - - x
    > >=0x20 586A/B x x x x x x - - - x


    Very impressive list! I assume it is shipped with newer versions?
    Mine does not have it (1.6.10).

    > known bugs:


    > From your first post this thread:
    > Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    > VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz
    >
    > You'll note that the Via 571 is the first chip mentioned by Dani and the
    > note under known bugs: no host side cable type detection. This means
    > you need the /80wire command switch to tell the driver that you have an
    > 80-wire cable.


    This is a very nice theory you got there. Unfortunately, it has no
    relation to practice. Here are the experiments I did:

    a) When setting up the new HD, it was first erroneously installed
    with a 40-wire cable. I got a lot of problems (do not remember
    which exactly, though). Upgrading to 80-wire fixed them - without
    any change to the driver command line.

    b) The following entries:

    BASEDEV=danis506.add /vl /A:0 /IT:100 /A:1 /BM /IT:100
    BASEDEV=danis506.add /vl /A:0 /80WIRE /IT:100 /A:1 /80WIRE /BM

    provide identical results of `cat ibms506$'.

    The only diff I can see of "bugreport.cmd" is (- with /80wire, + without)

    @@ -84,7 +84,7 @@ B0: 00 00 00 00 00 00 00 00 00 00 00
    C0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0: 10 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
    BusMaster Registers:
    -00: 08 00 60 00 00 70 F1 00 08 00 64 00 00 78 F1 00
    +00: 08 00 60 00 00 70 F1 00 00 00 64 00 00 78 F1 00

    VendorID 1106, DeviceID 0571

    So the bit 68 is different; does it mean anything?

    Thanks anyway,
    Ilya

    P.S. I did not try to do any actual burn with /80wire. I will later.

  17. Re: Major speed problem with reads from JFS

    Sir:

    Ilya Zakharevich wrote:

    >
    > P.S. I did not try to do any actual burn with /80wire. I will later.


    I am of the opinion that the only real test is with some measure of
    throughput. Check with Trevor Hemsley's System Bench program. I saw a
    difference several Via-chip-set-using main boards ago (K6-2).
    --
    Bill
    Thanks a Million!

  18. Re: Major speed problem with reads from JFS

    On Thu, 8 Jun 2006 02:54:02 UTC, Ilya Zakharevich
    wrote:

    > Very impressive list! I assume it is shipped with newer versions?
    > Mine does not have it (1.6.10).


    Yes. But if one looks closer at the readme, one will find that
    for chips without a dedicated "80wire" pin the driver will check,
    how the BIOS (which may query this information from other sources
    than the IDE chip itself) has set up the controller. If a mode is
    found, that requires an 80wire cable, the driver assumes that such
    a cable is present. Thus for drivers newer than some 1.3.x verison
    the /80WIRE switch is not neccessary in almost any cases.


    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  19. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was sent to
    Ruediger Ihle
    ], who wrote in article :
    > > Very impressive list! I assume it is shipped with newer versions?
    > > Mine does not have it (1.6.10).


    > Yes. But if one looks closer at the readme, one will find that
    > for chips without a dedicated "80wire" pin the driver will check,
    > how the BIOS (which may query this information from other sources
    > than the IDE chip itself) has set up the controller. If a mode is
    > found, that requires an 80wire cable, the driver assumes that such
    > a cable is present. Thus for drivers newer than some 1.3.x verison
    > the /80WIRE switch is not neccessary in almost any cases.


    I upgraded to 1.7.5 - no change, and still no effect of /80wire, so
    this confirms your theory.

    However, one puzzle remains: the chip list claims that

    South bridge (1106/0686 rev 22) on 0:4.0

    supports ATA-66. However, I get:

    Controller:1 Port:0170 IRQ:0F Status:OK BusMaster Scatter/Gather
    VIA 571 PATA host (1106:0571 rev:10) on PCI 0:4.1 @33MHz
    Unit:0 Status:OK SMS:16 LBA BusMaster UltraDMA4/PIO4 BPB
    Model:ST3200822A 3.01
    OS2:log phys BPB/BIOS IDE:log phys Total Sectors
    C 24321 65535 65535 16383 Avail 390721968
    H 255 16 255 16 16 OS2 390716865
    S 63 63 63 63 63 % Used 99.99
    Unit:1 Status:OK ATAPI BusMaster UltraDMA2/PIO4
    Model:_NEC DVD_RW ND-2500A 1.06

    How comes it runs @33MHz? AFAIK, both devices support ATA-100...
    (Same for the other controller, but it contains a 6 years old disk;
    maybe it does not support ATA-66)... Any idea?

    Puzzled,
    Ilya

  20. Re: Major speed problem with reads from JFS

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Ilya Zakharevich
    ], who wrote in article :
    > P.S. I did not try to do any actual burn with /80wire. I will later.


    As I said in another message, no change.

    However, since I got some free space on the new disk, I managed to
    reformat one of the FS on the other cable's hard disks as JFS. There
    is no problem whatsoever with cable-to-a-different-cable burn.

    So it IS a problem with HD and burner sharing the same cable. This
    means that I need a new controller; I hope one Bill provided is still
    available when I'm back from a trip... A lot of help to everybody for
    your suggestions...

    ================================================== =====

    For curious, some data about same-cable burning (when burning a CDRW,
    thus at slow speed, thus it is easier to detect what happens).
    Average speed is 1.43MB/sec. Pipe is from mkisofs2 to cdrecord2.

    = Write starts with average speed (as reported) 1.294x.

    = Buffered data size steadily goes down.

    = After it is goes down to 0, the CPU meter starts fluctuating in
    limits of several % (with average load about 10%).

    = The burn continues without underruns; so apparently the slowdown due
    to sharing the controller is not important for 1.3x write.

    = This happens with average speed (as reported) 1.295x. So the
    slowdown does not even slows down the burner (which explains why no
    underruns are seen).

    What puzzles me is what CHANGES on the controller during the
    transition of two regimes? Since the burn happens at the same rate,
    it looks like two cases should proceed similarly. However, in the
    first half of the write the mkisofs2 has no chance to read data
    from HD quick enough; in the second half it feeds the needed data with
    the needed speed.

    So something MUST have been changed... Maybe cdrecord2 switches to
    different chunk size of written data when input buffer is empty? I
    vaguely remember some performance options being available...

    Yours,
    Ilya

+ Reply to Thread
Page 1 of 2 1 2 LastLast