This is a discussion on Major speed problem with reads from JFS - OS2 ; After a long series of mail exchange with the author of DvdDAO, he was nice enough to listen to my crazy theories, and have put some debugging options into dvddao executables he sent to me. Turned out that my crazy ...
After a long series of mail exchange with the author of DvdDAO, he was
nice enough to listen to my crazy theories, and have put some
debugging options into dvddao executables he sent to me.
Turned out that my crazy theories were 100% matched by experiments.
What this boils down is:
a) There is no *inherent* problem with burning over an IDE channel
even if the same IDE channel is used to read the data to burn;
b) However, if one codes a burner application NAIVELY, then it will
keep the IDE channel locked 99.99% of the time; so the reader
application/thread will not be able to feed data quick enough IF
it uses the same channel.
Nickk is planning to put the required smarter logic into DvdDAO at
some time in the future. Meanwhile, with v1.3.5 I have, one needs to
set the --writesleep to an appropriate value[*]; then burns go without
[*] in my setup and the reported burn speed 2.3x, 8 is OK; the slower
the burn, the longer may be the wait. Yes, I know it is not
The wait should be long enough so that the reader has a chance to
read 63K of data. It is also nice if the writer burns a
significant portion of 63K of data during this time.
But obviously, it cannot be too long; the wait time PLUS the time
to transfer 63K through the bus should not exceed time to burn
63K of data.
This is contradictory with variable burn rate; for best results,
the application should vary the sleep amount wisely according on
the memory free in the burner's memory buffer.
Hope this helps,