Re: [Bug 15884] cd-burning reduces other simultaneous IO performance

[Stan Hoeppner <stan@hardwarefreak.com>]

bugzilla-daemon@bugzilla.kernel.org put forth on 4/30/2010 8:29 PM:

> Now, there may be a difference in what commands the burning software is using
> or the ordering that results in some of them taking longer than it does in
> Windows or something. (I don't know the MMC commands that well but I think some
> of them do have a mode where you can issue the command and poll periodically to
> see if it's done rather than blocking on the operation until it finishes.) That
> isn't anything the kernel can do anything about, though - if something issues a
> command to one drive on the channel that takes a long time, anything wanting to
> access the other drive just has to wait.

This has been known for over a decade.  When I was building white box
Windows systems in the mid-late 90s our SOP was to put burners on a
dedicated IDE port specifically due to what the OP reports over a decade
later as a bug.  As Robert points out above, this isn't a software bug, but
a hardware limitation of IDE.  Parallel SCSI, SAS, and SATA do not suffer
this limitation.  Apparently Windows engineers have developed a method over
the years to mitigate the ill effects of this.  I can tell you from
experience that Windows 9x/ME/NT4/W2K all suffered performance degradation
with HD+burner on the same channel problem.

-- 
Stan