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

[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

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!

[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

[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

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!

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.

[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

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"?

[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

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.

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!

[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

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!

[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.

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!

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

[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

[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