Brennan B2 and Raspberry Pi
On Mon, 19 Feb 2018 10:08:25 +0000, Chris Bartram wrote:
====snip====
Digital audio ripping is very variable according to disk quality and
drive ability, and i've found that reading one dodgy disk can then slow
down subsequent rips until after a reboot.
That sounds like a Microsoft Windows experience. The cause was due to
the driver code detecting a high error rate, causing it to drop back to a
lower UDMA performance mode, one stage at a time in the hope of easing
the stress on the interface to eliminate the high rate of errors until
finally resorting to the least stressful[1] of all modes, PIO mode, which
once selected, could not be reverted back to UDMA mode automatically.
If the driver had dropped from UDMA mode 3 down to 2 then 1 before
eliminating the high rate of errors, it could automatically revert back
to the faster UDMA modes provided it hadn't resorted to PIO mode. The
idea behind this behaviour was to automatically select the fastest
reliable UDMA setting with hard disk drives since not all drives fully or
reliably met their claimed UDMA specification.
It was a way to save the user the need to test and and adjust to find
the optimum performance setting between the drive and the ATA interface
itself which was apt to demonstrate 'compatibility issues' at the maximum
theoretical UDMA settings with various models of drive and brands of
interface chips used on the main board and plug in adapters.
This rarely resulted in resorting to PIO mode in the case of hard disk
drives, unless they were actually 'going bad', but it was a bit of a
disaster with optical media since defective media could trigger this drop
back to PIO mode, leaving the optical drive locked in this mode just for
the sake of one troublesome data CD or DVD leaving the put upon user to
google for the solution (either a registry edit or else uninstall/re-
install the optical device to trigger a reset back to UDMA mode[2]).
[1] Least stressful for the drive but horribly stressful for the CPU
which now had to do *all* the grunt work of shifting the data instead of
offloading it to the DMA controller.
[2] Microsoft must have addressed this issue in the more recent versions
of Windows if you've only had to reboot the machine to restore full
performance to your optical drive.
--
Johnny B Good
|